Quick Look: CVE-2026-119266, a Use After Free in Google Chrome's Quota Component

Introduction

Chrome accounted for 68.79% of worldwide browser usage in October 2026, according to Statcounter, so any memory-safety flaw reachable from an ordinary web page touches a very large share of the web's clients. Usage share is not a count of vulnerable installations, though. It says nothing about which builds people run.

CVE-2026-119266, a use after free in Chrome's Quota component fixed in the 156.0.8078.79 release, is one of those flaws. A crafted HTML page may lead to arbitrary code execution inside the browser sandbox once a user loads it.

This is a brief summary built from public advisories, trackers, and scanner metadata. The Chromium bug behind the CVE is still restricted, so the exact root cause is not public. We focus on what is documented: the weakness class, the attack prerequisites, the fixed builds, and how to confirm your fleet is actually running them.

Technical information

Root cause

The Chrome CNA describes CVE-2026-119266 as a use after free in Quota, classified as CWE-416. MITRE defines this weakness as reusing or referencing memory after it has been freed. If the freed memory is later allocated for another purpose, the original pointer no longer refers to a valid object belonging to its original owner, and whatever now occupies that memory gets interpreted as the old object.

As general background, and not confirmed for this specific bug: Chromium's Quota subsystem tracks how much storage each origin uses and how much it is allowed, for features such as IndexedDB and Cache Storage. A use after free in that area usually means some code kept a pointer or callback to a quota object after that object was freed. A page could then trigger the stale reference, and an attacker might control the contents of the freed memory.

The public record does not say which object is freed early, which operation triggers the stale access, what allocation pattern would be needed to reclaim the memory, or how reliably the bug can be exploited. NVD tags Chromium issue 575202553 as Permissions Required, and the issue denies public access.

Severity and prerequisites

CISA ADP assigned a CVSS 3.1 score of 8.8 High. NVD has not supplied its own assessment. Chromium's own severity label is also High.

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

• AV:N: network reachable
• AC:L: low attack complexity
• PR:N: no privileges required
• UI:R: user interaction required (the victim must load the page)
• S:U: scope unchanged
• C:H / I:H / A:H: high confidentiality, integrity, and availability impact

These values describe assessed severity, not observed exploitation. Some downstream ratings differ. HKCERT rates its broader multiple-vulnerability bulletin as Medium Risk, and Snyk shows a Low default assessment pending relevant scores. Neither is a technical rebuttal of the CVE-specific 8.8 score.

Attack flow, as documented

Based only on what the disclosure states:

1. A remote attacker prepares a crafted HTML page designed to reach the vulnerable Quota functionality.
2. A user running Chrome older than 156.0.8078.79 loads the page (the UI:R prerequisite).
3. The page triggers access to a quota-related object after it has been freed.
4. If the attacker can influence what occupies the freed memory, this may lead to arbitrary code execution inside the sandbox.

The description does not claim a sandbox escape, operating system privilege gain, or full host compromise from this CVE alone. Reaching beyond the sandbox would require a separate flaw, and nothing in the record shows one chained with this bug.

Exploitation status

• OpenCVE displays an SSVC assessment of "exploitation: none" and "automatable: no".
• The complete CISA KEV JSON catalog, version 2026.10.30 (released October 30, 2026), contains no entry for this CVE. That is a dated observation, not a guarantee of safety.
• Tenable rates exploit ease as "No known exploits are available."
• No verified public proof of concept, threat actor, campaign, or victim has been identified.
• Snyk shows an EPSS probability of 0.24% at the 16th percentile. The page carries no assessment date, and EPSS is predictive model output rather than evidence of attacks.

Patch information

Google fixed the bug in the Stable Channel desktop update that brings Chrome to 156.0.8078.79/.80 on Windows and macOS and 156.0.8078.79 on Linux. NVD lists that release post as the vendor advisory and solution and marks every Chrome version before 156.0.8078.79 as affected. The CVE record was published on October 29 or October 30, 2026, depending on time zone. NVD's publication timestamp is October 30, 2026.

Why there is no diff here

The source-level change cannot be inspected yet. The linked Chromium issue is restricted, which is standard practice. Google keeps memory-safety bug reports and their associated commits restricted until most users have the fix, so the patch cannot be reverse-engineered into an n-day exploit while many browsers remain unpatched. Chromium's security FAQ says the project aims to open such issues after fixes ship broadly, generally within about 30 days of the fix landing, subject to stated exceptions. We also could not retrieve the release post during our research, so we cannot confirm what it says about this fix. For these reasons we show no code, commit hash, or changed file names.

As general background only: Chromium typically fixes this class of bug by tying a callback's lifetime to its owner (for example with a WeakPtr that is invalidated when the owner is destroyed), by changing ownership so the object cannot be freed while an operation is still running, or by reordering cleanup. Which approach Google used here will stay unknown until the bug opens.

Applying the update

Google documents that updates apply when the browser restarts. On desktop:

1. Open Chrome.
2. Select More > Help > About Google Chrome.
3. Select Relaunch when offered.

If a user chooses Not now, the update applies at the next restart. Tabs and windows normally reopen, but Incognito windows do not. Downloading an update and applying it are separate events, and a host with a pending relaunch is still running the vulnerable code.

Managed fleets

For managed Chrome on Windows, Mac, and Linux, the RelaunchNotification policy controls how users are prompted:

• Relaunch recommended: the user can dismiss the prompt and keep running the old version.
• Relaunch required: Chrome repeatedly tells the user to relaunch within a set period, controlled by RelaunchNotificationPeriod.

Administrators can open chrome://policy, reload policies, and confirm the relaunch policies show Status: OK with the intended values.

Distribution packages

Debian shipped the upstream release as DSA-6605-1, which covers this CVE along with other Chromium CVEs from the same release. The tracker marks 156.0.8078.79-1~deb13u1 (trixie security) and 156.0.8078.79-1 (sid) as fixed. Bookworm users should follow Debian's announcements rather than assume coverage (details below).

The fix ships only as a full browser update. Google publishes no separate hotfix or backport outside the Chrome release channels, and no CVE-specific workaround, configuration change, or blocking rule is documented.

Detection methods

There is no public exploit-level detection for CVE-2026-119266. No CVE-specific IoCs exist, and there are no Sigma, YARA, Snort, or Suricata rules or published log patterns. The trigger details needed for a network or endpoint signature are not public. Detection here means exposure detection: finding every Chrome or Chromium build older than the fixed version and confirming the fix actually landed.

Version checks

NVD's affected configuration is cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:* up to, but not including, 156.0.8078.79. When writing the check:

• Compare the full four-part build number. Debian's tracker lists forky's 156.0.8078.47-1 as vulnerable. A rule checking only for major version 156 would wrongly pass that host.
• Account for the macOS split build. CERT-FR (CERTFR-2026-AVI-1422) lists Linux and Windows as affected below 156.0.8078.79 and Mac below 156.0.8078.80. Google describes the update as 156.0.8078.79/.80 for Windows and Mac. If Macs report .79, verify which build your channel shipped before marking them fixed.
• Inventory more than one source. Chrome comes from Google's installer on Windows and macOS, but on Linux and BSD it often comes from the distribution as chromium.

Tenable coverage

Tenable lists six plugins covering this CVE:

• Windows, plugin 373883 (google_chrome_156_0_8078_79.nasl) and macOS, plugin 373884 (macosx_google_chrome_156_0_8078_79.nasl). Both are local checks requiring the installed_sw/Google Chrome KB item, so they need credentialed scans or an agent. They rely on Chrome's self-reported version and do not test for the flaw. They are bundle plugins for the whole October 29 advisory covering 21 CVEs, so a finding means the host runs an unfixed build, not that this bug was triggered.
• FreeBSD, plugin 374952 checks chromium and the ungoogled chromium package against the FreeBSD advisory. It needs local checks and Host/FreeBSD/pkg_info.
• Debian-family Linux, plugin 374240 (unpatched_CVE_2026_119266.nasl) flags Debian 12, 13, and 14 hosts with the chromium package where the vendor has not shipped a fix. It requires the global_settings/vendor_unpatched KB item, which suggests it only reports when vendor-unpatched findings are enabled in the scan policy. If you expect results and see none, check that setting.
• Cloud and containers, plugin 478234 ("Echo: chromium: security update to 156.0.8078.79") applies to Tenable Cloud Security and Tenable Self Hosted Container Security. Headless Chromium is frequently bundled into container images for PDF rendering, scraping, or testing, and those images rarely appear in desktop inventories.

Rapid7

Rapid7's database marks CVE-2026-119266 as covered for Google Chrome, added October 30, 2026, with a solution of upgrading Chrome. InsightVM and Nexpose users should see it under the standard Chrome version checks.

Debian tracker

Without a commercial scanner, the Debian security tracker is authoritative for Debian hosts. At the time of writing:

• Fixed: trixie (security) 156.0.8078.79-1~deb13u1, shipped in DSA-6605-1; sid/unstable 156.0.8078.79-1.
• Vulnerable: bookworm 150.0.7871.100-1~deb12u1, trixie (main) 150.0.7871.181-1~deb13u1, forky 156.0.8078.47-1. Bookworm (security) 156.0.8078.79-1~deb12u1 is also still marked vulnerable.

That bookworm entry shows a host can carry the right upstream version string while the distribution tracker still marks it vulnerable, so use tracker status rather than a string match. A trixie host pulling only from the main archive, not the security archive, also stays on the vulnerable 150.x build.

What cannot be detected yet

With no public trigger details and no reported in-the-wild use, there is no reliable crafted HTML signature for proxies, IDS, or EDR. In general, sandbox-contained renderer exploitation tends to surface as unusual renderer crashes or as a follow-up sandbox escape, not as anything unique to one CVE. Generic browser exploitation telemetry may help, but no source offers CVE-specific guidance. Until the Chromium issue opens or a vendor publishes a signature, treat version and package checks as the detection control and watch the bug and vendor feeds.

Affected systems and versions

• Google Chrome desktop: all versions before 156.0.8078.79 (NVD CPE cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:*).
• Fixed targets: Linux 156.0.8078.79 or later; Windows and macOS 156.0.8078.79/.80 or later. CERT-FR lists Mac as affected below 156.0.8078.80.
• Debian chromium, vulnerable: bookworm 150.0.7871.100-1~deb12u1, bookworm security 156.0.8078.79-1~deb12u1 (still marked vulnerable), trixie main 150.0.7871.181-1~deb13u1, forky 156.0.8078.47-1.
• Debian chromium, fixed: trixie security 156.0.8078.79-1~deb13u1, sid 156.0.8078.79-1.
• FreeBSD: chromium and ungoogled chromium packages, per the FreeBSD advisory referenced by Tenable plugin 374952.
• Containers: images bundling Chromium older than 156.0.8078.79.

These are desktop and distribution remediation targets. The sources do not establish that other Chromium-based products or mobile releases share the same version numbering.

Vendor security history

Google describes Chrome as a sandboxed, multiple-process browser. Its strategy combines runtime hardening of legacy C++ code with migration toward memory-safe languages. Documented defenses include MiraclePtr and MiracleObject, both intended to mitigate use-after-free bugs. Google identifies Rust as a longer-term answer and acknowledges that runtime mitigations reduce memory-lifetime defects rather than eliminate them.

Google reports that Chrome 149 and 150 fixed 1,072 security bugs, more than the combined total of the preceding 23 milestones, and points to external researcher participation through the Chrome Vulnerability Reward Program. These are vendor statements, not an independent comparison.

Despite those defenses, a use after free in Quota still yields potential code execution inside the sandbox, which shows the limit of architecture alone. The record does not show whether the affected Quota object was covered by MiraclePtr, so describing this as a MiraclePtr bypass would be unsupported.

References

• NVD: CVE-2026-119266
• CVE Record: CVE-2026-119266
• CVE Services API record
• Chrome Releases: Stable Channel Update for Desktop
• Chromium issue 575202553 (restricted)
• HKCERT: Google Chrome Multiple Vulnerabilities
• CERT FR advisory CERTFR 2026 AVI 1422
• Debian security tracker: CVE-2026-119266
• Debian DSA 6605 1
• OpenCVE: CVE-2026-119266
• CIRCL Vulnerability Lookup: CVE-2026-119266
• Snyk: Use After Free in chromium
• Tenable plugins for CVE-2026-119266
• Tenable Nessus plugin 373883 (Windows)
• Tenable Nessus plugin 373884 (macOS)
• Tenable Nessus plugin 374240 (Linux distros unpatched)
• Tenable Nessus plugin 374952 (FreeBSD)
• Rapid7 vulnerability database: CVE-2026-119266
• MITRE CWE 416: Use After Free
• CISA Known Exploited Vulnerabilities Catalog
• CISA KEV JSON feed
• CISA KEV data mirror on GitHub
• Google Chrome Help: Update Google Chrome
• How to Update Chrome to the Latest Version
• Chrome Enterprise: Notify users to restart to apply pending updates
• Google: Stronger with every update
• Google Online Security Blog: Use after freedom, MiraclePtr
• Chromium Docs: Chrome Security FAQ
• Chromium Secure Architecture
• Statcounter: Browser Market Share Worldwide