A parser that misreads one CSS object as another and coughs up bytes it shouldn't
CVE-2026-14148 is a type confusion (CWE-843) in Chrome's CSS engine — likely in Blink's style resolution or computed-style paths. When the renderer treats a CSS-derived object as the wrong class, reads land on adjacent memory the attacker did not allocate, and the contents can be reflected back through side channels (paint timing, computed-style readback, canvas taint boundaries, or SVG filter feedback). All Chromium builds prior to 150.0.7871.47 are affected — Chrome stable, Chrome Beta on the same trunk, Edge (pending Microsoft's re-spin), Brave, Opera, Vivaldi, and Electron 33/34-line runtimes.
Google's MEDIUM (6.5) rating is defensible and slightly generous. The CVSS vector explicitly rules out integrity and availability — this is C:H/I:N/A:N, a pure confidentiality read — and requires user interaction (visiting a hostile page). It is *not* a renderer RCE, it is *not* a sandbox escape, and it does not chain to code execution on its own. Treat it as an info-leak primitive that raises the value of any future RCE that needs an ASLR bypass, not as a standalone crisis.
4 steps from start to impact.
Lure user to attacker-controlled page
- User running Chrome/Edge/Brave/Electron < 150.0.7871.47
- Ability to render attacker HTML/CSS (JS not strictly required for CSS-only triggers)
- Enterprise DNS/URL filtering (Umbrella, Zscaler, Netskope) blocks known-bad staging
- Ad-blockers and enterprise content filters kill most malvertising paths
- SmartScreen / Safe Browsing shows an interstitial on flagged domains
Trigger the CSS type confusion
@property registrations, or a specific selector/computed-style interaction) that forces Blink's style engine to reinterpret one object as another type. Public triggers will appear on Chromium bug tracker once the restriction lifts (typically 14 weeks post-fix) and in Project Zero or Sergei Glazunov style writeups.- Renderer executes the CSS parse/apply cycle
- No site isolation exception for the origin
- v8/Blink hardening (
--enable-features=MemorySaverand site-per-process) constrains what can be read - Renderer sandbox contains the leak to the renderer process address space only
chrome://crashes and enterprise Crash Reporter telemetry.Exfiltrate leaked bytes via side channel
getComputedStyle, CanvasRenderingContext2D pixel readback if colors are influenced, PerformanceObserver timing, or SVG filter feedback loops. Bytes are POSTed to the C2. Typical toolchain: bespoke JS in the payload, no off-the-shelf framework needed.- JavaScript execution in the same origin (or an iframe that can observe the leaked state)
- Leaked bytes must land in an observable structure
- Cross-Origin-Opener-Policy / Cross-Origin-Embedder-Policy on sensitive targets prevents cross-origin observation
- Site isolation ensures leaked bytes belong to the attacker's own renderer — not to
mail.google.comrunning in a different process
Chain into a full RCE (theoretical, out of scope for this CVE alone)
- A separately-weaponized renderer RCE
- A separately-weaponized sandbox escape
- Requires two more zero-days at similar quality
- Chromium's V8 sandbox and Windows Renderer AppContainer add friction
deb_packages/apps table) for Electron-based apps and check each vendor's release notes for the 150-line uplift. Electron patches lag Chrome by weeks — this is the long tail.SafeBrowsingProtectionLevel=2 in Chrome enterprise policy. Blocks the majority of malvertising and phishing staging domains before the page renders. Zero performance cost, one policy toggle.- EDR / AV signatures — the exploit runs entirely inside the browser renderer sandbox. No process creation, no LOLBIN, nothing for EDR heuristics to grab.
- Network IDS/IPS signatures on the payload — the trigger is CSS, trivially obfuscated and served over TLS. Signature-based inspection is theater here.
- Disabling JavaScript site-wide — breaks the modern web and does not actually stop CSS-only trigger variants. Users will re-enable it or route around your proxy.
- MFA — this is a memory-read bug in the renderer, not a credential attack. MFA is irrelevant to the exploit path.
The supporting signals.
| In-the-wild status | No confirmed exploitation as of 2026-07-01. Not tagged as exploited in Google's release note — contrast with the exists in the wild wording Chrome uses when TAG sees active abuse. |
|---|---|
| Proof-of-concept | None public. Chromium bug entry is still restricted; historical pattern is disclosure ~14 weeks after stable ships. |
| EPSS | New CVE — EPSS not yet scored. Comparable Chrome CSS type-confusion bugs historically land in the 0.1–1% range in the first 30 days. |
| KEV status | Not listed on CISA KEV as of 2026-07-01. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — network attack, low complexity, user interaction required, unchanged scope, confidentiality-only impact. No integrity or availability loss. |
| Affected versions | Chromium < 150.0.7871.47. Downstream: Edge, Brave, Opera, Vivaldi, Electron on the 150-branch, Chrome Android, ChromeOS LTS pending backport. |
| Fixed versions | Chrome Stable 150.0.7871.47 (Win/Mac/Linux). Edge, Brave, Opera to follow within 3–10 days per historical cadence. |
| Exposure / scanning data | Not scanner-relevant — client-side bug. Enterprise footprint = essentially 100% of endpoints running Chromium-family browsers. |
| Disclosure date | 2026-06-30 — coordinated release with Chrome Stable channel update. |
| Reporter | Attribution not yet published in the release note. Historically these come from Google Project Zero, Man Yue Mo (GitHub Security Lab), or external researchers via Chrome VRP. |
Sources.
- Chrome Releases blog (stable channel updates)
- Chromium security release notes
- NVD entry (CVE-2026-14148)
- CWE-843: Access of Resource Using Incompatible Type
- CISA KEV catalog
- FIRST EPSS
- Chrome Enterprise policy reference (SafeBrowsingProtectionLevel, ExtensionInstallForcelist)
- Chromium site isolation documentation
Why this verdict
- Confidentiality-only, no code execution: the vector locks out integrity and availability. Without a paired RCE, the attacker gets bytes, not a shell.
- User interaction required (UI:R): a human has to visit the page. Drive-by via malvertising is possible but attritional — every URL filter, ad-blocker, and Safe Browsing hit is compounding downward pressure.
- Site isolation contains the leak: post–Spectre Chromium runs each site in its own renderer process, so the attacker leaks memory from *their own* renderer, not from
okta.comin the next tab. - Role multiplier — endpoint browser on user workstations: chain succeeds → attacker gets an ASLR-bypass primitive scoped to their own renderer. Blast radius = one browser tab's process memory. No fleet, identity, or supply-chain amplification.
- Role multiplier — Electron apps embedding Chromium (Slack, Teams, VS Code, 1Password, Discord): more concerning because Electron apps often defer patching and sometimes run with elevated node integration. Still confidentiality-only, but the *value* of leakable memory (session tokens, secrets in memory) is higher. Bumps this out of LOW territory.
- No KEV listing, no public PoC, no in-the-wild reports as of 2026-07-01 — no basis for emergency handling.
Why not higher?
Escalating to HIGH would require either evidence of active exploitation (there is none) or a documented chain to renderer RCE / sandbox escape (this CVE is a leak primitive only). The C:H/I:N/A:N vector is the ceiling; you cannot get to HIGH on confidentiality alone for a client-side bug that requires the user to visit the page.
Why not lower?
Downgrading to LOW would ignore that Chromium runs on essentially every enterprise endpoint and that infoleaks are the standard ASLR-defeat building block in modern browser exploit chains. Any threat actor holding a renderer RCE zero-day is a customer for this bug the moment a PoC lands. That is enough to keep it in the 30-day mitigation window rather than the backlog.
Crowdsourced verification payload.
Run on the target Windows host (or push via RMM/Intune script) as the logged-in user or SYSTEM. Reads the installed Chrome version from the registry and file metadata. Invoke: powershell -ExecutionPolicy Bypass -File Check-CVE-2026-14148.ps1. No elevated privileges required for the per-user Chrome install; use SYSTEM for machine-wide installs.
#!/usr/bin/env pwsh
# Check-CVE-2026-14148.ps1
# Verifies Chrome build against the fixed version 150.0.7871.47
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
$FixedVersion = [Version]'150.0.7871.47'
$Paths = @(
"$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
"$env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
"$env:LocalAppData\Google\Chrome\Application\chrome.exe"
)
$Found = $false
$Worst = $null
foreach ($p in $Paths) {
if (Test-Path $p) {
$Found = $true
try {
$v = [Version](Get-Item $p).VersionInfo.ProductVersion
Write-Host "Found Chrome at $p -> $v"
if (-not $Worst -or $v -lt $Worst) { $Worst = $v }
} catch {
Write-Host "Could not read version from $p"
}
}
}
if (-not $Found) {
Write-Host 'UNKNOWN: Chrome not installed at standard paths'
exit 2
}
if ($Worst -lt $FixedVersion) {
Write-Host "VULNERABLE: installed $Worst < fixed $FixedVersion"
exit 1
} else {
Write-Host "PATCHED: installed $Worst >= fixed $FixedVersion"
exit 0
}