Chromium V8 CVE-2026-11645 Is in KEV. The Browser Is an Endpoint Data Surface.

Google confirmed in June 2026 that CVE-2026-11645, an out-of-bounds read and write flaw in the Chromium V8 JavaScript engine, was under active exploitation. The flaw arises from an incorrect bounds-check elimination during just-in-time compilation in the TurboFan optimizer, and a crafted HTML page triggers it.

An attacker who lands the exploit gains read and write access inside the sandboxed renderer process, and it carries a CVSS score of 8.8. The Cybersecurity and Infrastructure Security Agency added it to the Known Exploited Vulnerabilities catalog on June 9, 2026 and set a Federal Civilian Executive Branch remediation deadline of June 23, 2026 under Binding Operational Directive 22-01.

The flaw affects every browser built on the Chromium framework, including Google Chrome, Microsoft Edge, Opera, and the embedded Chromium runtimes that ship inside desktop applications. Google fixed it in Chrome 149.0.7827.103, and every prior version is affected. The patch closes the specific vector. It does not change where enterprise data now lives during a working day.

The browser is where the data is read

The exploit operates inside the renderer sandbox, and full control of the host requires chaining it with a separate sandbox escape. That confinement matters less than it once did, because of what the renderer now holds. The renderer process is where the page is decrypted and drawn: the session cookies, the OAuth bearer tokens, and the cleartext of every record rendered in the tab. An attacker with read and write access inside the renderer reaches all of it without ever leaving the sandbox.

Enterprise data moved into the browser over the last decade. Customer records, financial data, and regulated information are read through software-as-a-service consoles and internal web applications rather than thick clients. The browser is the most widely deployed data-access surface in the organization, and a memory-safety flaw in its scripting engine is a flaw in the place that data is handled in the clear.

When the renderer holds the cleartext

Most web data protection assumes a trusted browser. Transport Layer Security protects the data in transit, the application authorizes the session, and the renderer displays cleartext to the user. Confidentiality of what appears on screen depends on the integrity of the renderer process for the duration of the session. A renderer compromise reaches the cleartext and the active session at the same time.

Data-centric zero trust moves the trust boundary off the browser and onto the data object. Lattix Technologies binds policy to the object through attribute-based access control (ABAC) at the policy enforcement point (PEP), wraps the object under post-quantum key encapsulation with ML-KEM-768 and ML-KEM-1024, and records every release decision as Merkle-tree lineage in content-addressed storage (CAS-X). The key-release decision happens at a policy decision point (PDP) that does not run in the browser. A compromised renderer sits in the transport path of a request, not in the policy decision that releases the keys.

What changes when the renderer fails

Two failure modes separate under this architecture. A compromised renderer can read what the current user already opened in that session, and a data-centric posture does not claim otherwise. What the posture removes is the broader reach. Each object release is a fresh decision at the PEP, evaluating an attribute claim that the browser does not hold and cannot forge. A stolen session does not become the keys for objects the user never opened, because those objects release only against a policy decision made off the host.

The request that cannot satisfy policy fails closed. An attacker who controls the renderer controls a transport node and a single live session, not the authority that decides which objects release and to whom.

Distinct from the kernel flaw, the network controller, and the security tool

This is the fourth instance in 2026 of one architectural pattern reaching a different layer. The Linux Copy Fail flaw, CVE-2026-31431, reached root through the kernel. The Cisco Catalyst SD-WAN flaw, CVE-2026-20182, reached administrative control through the network control plane. The Microsoft Defender flaw, CVE-2026-41091, reached SYSTEM through the endpoint security tooling. CVE-2026-11645 reaches the cleartext through the client browser.

The common thread is not the vendor or the layer. Each control under attack assumes a trusted component, whether a kernel, a control plane, a security agent, or a renderer, and each compromise removes exactly that assumption. Data-centric zero trust binds enforcement to the object rather than to the integrity of the software the object passes through. The object enforces its own policy whether the renderer is trustworthy or not.

The evidence question for browser-accessed data

After a browser compromise, the response team has to determine which records were exposed in the affected sessions. Logs collected in the browser or on the endpoint are evidence of uncertain integrity once the renderer is under attacker control.

Merkle-tree lineage answers the question from outside the browser. The chain records every release decision the PEP made and anchors it in content-addressed storage the endpoint cannot rewrite. The response team queries the chain for releases tied to the compromised sessions during the incident window. Objects that were released surface as entries. Objects the attacker did not obtain a release for surface as the absence of an entry. The materiality determination and the breach-notification scope rest on that record rather than on telemetry the attacker could reach.

How the architecture maps to standards

NIST SP 800-207 places the policy decision point outside the systems it governs, which is the property that keeps a renderer compromise out of the policy decision. The CISA Zero Trust Maturity Model 2.0 scores the data pillar separately from the device pillar, so a patched browser on a hardened endpoint does not raise the data-pillar score. CISA Binding Operational Directive 22-01 makes KEV remediation binding on federal civilian agencies and sets the June 23 deadline. For protected health information under the HIPAA Security Rule and for cardholder data under PCI DSS 4.0.1, both of which are routinely read through the browser, the governing control is protection of the data object, not the hardening of the browser alone.

What teams should do before the deadline

The first action is the patch. Chrome 149.0.7827.103 and the matching Edge, Opera, and embedded-runtime updates close CVE-2026-11645, and the June 23 deadline binds federal civilian agencies. Browser patch latency across a managed fleet is the operational risk, so the update has to reach every Chromium-based client, including the runtimes embedded inside desktop applications.

The second action is the architecture question the patch does not answer. Inventory the regulated data that users read through the browser, and identify where that data exists in the clear inside the renderer. Every point where the renderer holds plaintext is a point where the next memory-safety flaw becomes a data exposure. Object-level cryptographic enforcement, with the keys and the policy decision held off the browser, converts the next renderer compromise into a session-scoped transport problem rather than a breach of the data.

References

• CISA Adds Three Known Exploited Vulnerabilities to Catalog (June 9, 2026)
• CISA Known Exploited Vulnerabilities Catalog
• Google Chrome Releases, Stable Channel Update for Desktop
• CISA Binding Operational Directive 22-01
• NIST SP 800-207, Zero Trust Architecture
• CISA Zero Trust Maturity Model 2.0
• PCI DSS 4.0.1