messageGetMatchingElements built the evaluated expression by directly string-interpolating the page-derived selector into a JavaScript source string: document.querySelectorAll('${message.cssSelectors}'). That whole string is then handed to commands.scriptCommand.execute(...) and evaluated as JavaScript in the target. Because message.cssSelectors is attacker-influenced and is placed inside a single-quoted JS string literal with no escaping, a crafted selector containing a single quote (and arbitrary following text) breaks out of the string literal and injects attacker-chosen JavaScript into the evaluated expression. The violated invariant is that untrusted data embedded into an evaluated code string must be escaped/encoded for that context; it was not.

The patch wraps the value: document.querySelectorAll('${CSS.escape(message.cssSelectors)}'). CSS.escape encodes the selector so embedded quotes/backslashes can no longer terminate the string literal, preventing the breakout and confining the value to a harmless selector argument. (The advisory’s generic “Other issue in the Console component” understates this: the diff substantiates a code-injection/input-validation flaw in an evaluated expression.)

This is a DevTools client-side injection: untrusted console-message data is evaluated as JavaScript via scriptCommand.execute. Exploitation requires the victim to open the Web Console and use the matching-elements action on an attacker-influenced message (user interaction gating). The injected code runs in the inspected target’s execution context; because that context is the page the attacker already influences, the direct gain is bounded, but evaluating attacker-chosen expressions through the DevTools evaluation path can broaden beyond what the page’s own script could do and is the reason it is tracked as a security fix. The fix is a straightforward escaping of untrusted input; no memory-safety sink is involved.