Chrome 153.0.8010.36: 4 CVEs, 2 Exploited — V8, WebView and Extensions

Four Chromium vulnerabilities deserve attention in early September 2026. They form a textbook case on something many teams get wrong: the CVSS score is not a reliable priority signal, and this batch demonstrates it as sharply as possible.

Read that table twice. The two CVEs actually being exploited carry no score. The two showing 9.8 are rated Medium and Low by Google.

A team prioritising by sorting its backlog on descending CVSS would therefore handle the two least urgent flaws first, and leave aside the two actively used against users.

Fixed version for the two scored CVEs: 153.0.8010.36.

Why the Scores Diverge

This isn't an error, it's a difference of model.

Google scores impact within its own security model. Chromium rests on a sandbox: the renderer process is treated as hostile by design. A flaw that doesn't escape it is, from their perspective, severe but contained — hence "Medium" or "Low".

NVD scores against the generic CVSS rubric, which knows nothing of Chromium's sandbox. A remote access-restriction bypass with no authentication mechanically ticks AV:N/AC:L/PR:N/UI:N with high impact everywhere — that's 9.8.

Both scores are defensible within their own frame. The problem appears when you mix them, or trust only one.

The operational lesson: for browsers, the right priority signal is neither the NVD score nor the vendor severity, it's presence in the CISA KEV catalog — that is, observed exploitation.

The Two Exploited CVEs — V8

NVD has published no score, vector or detail for these two. I'm relying solely on the CISA descriptions.

CVE-2026-87491 — out of bounds write

Google Chromium V8 contains an out of bounds write vulnerability that allows a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page.

KEV added: 2026-09-09. Deadline: 2026-09-23.

CVE-2026-85046 — type confusion

Google Chromium V8 contains a type confusion vulnerability that allows a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page.

KEV added: 2026-09-04. Deadline: 2026-09-18.

What "inside the sandbox" actually means

The phrasing reassures too readily. It means the attacker executes code in the renderer process, which is isolated — they don't yet own the machine.

But that process contains everything to do with open pages:

• rendered content, including data typed into forms
• cookies and session tokens accessible to that origin
• local storage for visited sites

And above all, it's the standard first half of a browser exploitation chain: memory primitive in the renderer, then sandbox escape. It's the same pattern described in our analysis of the four Firefox use-after-free flaws — the engines change, the attack model doesn't.

V8, the JavaScript engine, is the prime target for this kind of research: it compiles attacker-supplied code on the fly with aggressive optimisations. Type confusion is the most productive bug class there.

The Two 9.8-Scored CVEs

CVE-2026-87534 — WebView on Android

Missing authorization in WebView in Google Chrome on Android prior to 153.0.8010.36 allowed a remote attacker leveraging social engineering to bypass system access restrictions via crafted network traffic.

The "leveraging social engineering" is why Google classes it Medium: the victim has to do something. The NVD vector, however, says UI:N. Both cannot be true at once; in practice, trust the textual description, which is more precise than the vector.

WebView nonetheless deserves attention for a structural reason: it isn't just the browser. It's the component rendering web content inside Android applications — login screens, terms of service, embedded content. A WebView flaw therefore has a far wider surface than Chrome itself.

CVE-2026-87544 — Extensions

Incorrect authorization in Extensions in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to bypass system access restrictions into a privileged page via a crafted HTML page.

"Privileged page" means the browser's internal pages (chrome://), which hold permissions web content doesn't. Reaching that context from an ordinary web page is a break of the browser's security boundary.

Google classes it Low, presumably because of restrictive exploitation conditions the advisory doesn't detail.

Versions and Scope

⚠️ For the two KEV CVEs, NVD publishes no fixed version. They are fixed in the Chrome releases published in early September 2026 — check the corresponding Chrome Releases advisory rather than trusting a number I don't have.

Scope goes beyond Chrome. CISA states it explicitly:

This vulnerability could affect multiple web browsers that utilize Chromium, including, but not limited to, Google Chrome, Microsoft Edge, and Opera.

So your inventory has to include: Edge, Opera, Brave, Vivaldi, Arc, the browsers embedded in Electron-based desktop applications, and WebView on Android.

This is what update campaigns most often miss: updating Chrome fixes neither Edge nor the Electron applications that ship their own Chromium.

Check the version:

chrome://version
edge://version

# Windows — fleet inventory
Get-Item "C:\Program Files\Google\Chrome\Application\chrome.exe" |
  Select-Object @{N='Version';E={$_.VersionInfo.ProductVersion}}
Get-Item "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" |
  Select-Object @{N='Version';E={$_.VersionInfo.ProductVersion}}

Detection

As with any browser memory corruption, there's no usable client-side signature. The useful signals are post-exploitation:

• Outbound traffic from the browser process to destinations unrelated to browsing
• Valid sessions reused from an unusual IP or agent — visible on the application server side, not the endpoint
• Extensions appearing without user action: chrome://extensions
• Child processes of the browser that aren't Chromium processes

The control that actually matters remains version inventory.

Mitigation

1. Update — and force the restart

Chrome updates in the background, but the fix only takes effect when the browser restarts. That's the classic enterprise leak: endpoints sit on a vulnerable version for weeks because nobody ever closes their browser.

On a managed fleet, don't rely on goodwill:

# Chrome GPO
Computer Configuration → Administrative Templates → Google Chrome
  → "Notify a user that a browser relaunch is recommended or required"
  → RelaunchNotificationPeriod

2. Don't forget the other Chromiums

Edge, Opera, Brave, and above all the Electron applications in your estate. Those ship a pinned Chromium updated at the application vendor's pace — frequently months behind.

3. On Android, check WebView separately

Settings → Apps → Android System WebView

WebView updates through the Play Store, independently of Chrome and of the system patch.

4. Prioritise on KEV, not on score

That's this article's operational conclusion. For browsers, build your queue on presence in the CISA KEV catalog. The CVSS score would have you handle the two unexploited flaws first.

Why Continuous Monitoring of Browsers Matters

Chrome ships several security fixes per month, some of them for flaws already being exploited. The problem isn't being informed — Google communicates well — it's knowing which versions actually run across your estate, including Edge, secondary browsers and the Electron applications nobody inventories.

With cveo.tech, inventory your browsers and Chromium components with exact versions, and get automatic alerts whenever a critical CVE — particularly a KEV-listed one — targets any of them.