← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11076 · CWE-843 · Disclosed 2026-06-04

Type Confusion in CSS in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is getting a crowbar into the lobby, not the server room

CVE-2026-11076 is a type confusion in Chrome's CSS handling that affects Google Chrome versions before 149.0.7827.53 on desktop. The bug can be triggered by a crafted HTML page, meaning the initial reachability is classic browser-bug territory: get a user onto malicious content, corrupt memory in the renderer, and execute attacker code inside the sandbox.

The vendor-style 8.8/HIGH score overstates what defenders should prioritize here because the decisive phrase is "inside a sandbox". In real enterprise operations, that means this is usually one half of a chain, not a full workstation compromise by itself; Chrome's own CNA text in NVD even calls the Chromium security severity Medium, which matches operational reality better than the generic CVSS impact math.

"Drive-by reachable, yes; endpoint-owning, no. This is sandboxed renderer code exec, not a one-bug fleet takeover."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker-controlled web content

The attacker needs a user to render a malicious page, typically through phishing, malvertising, compromised ad inventory, or a site the attacker controls. The weaponized content is just HTML/CSS/JS delivered through normal browser traffic; no auth and no local foothold are required at this stage.
Conditions required:
  • Unauthenticated remote reachability to a browser user
  • User interaction: victim must open or be redirected to the page
  • Target must be running Chrome older than 149.0.7827.53
Where this breaks in practice:
  • This is UI:R, so it is not wormable and not a blind internet-service exploit
  • Email/web filtering, Safe Browsing, DNS filtering, and user behavior all reduce hit rate
  • Managed Chrome fleets often auto-update quickly, shrinking exposure windows
Detection/coverage: Exposure scanners can identify outdated Chrome versions on managed endpoints, but they cannot see exploit delivery on the public internet the way they can for server CVEs. Detection is mostly via proxy logs, phishing telemetry, browser crash spikes, and EDR child-process or memory-anomaly analytics.
STEP 02

Trigger CSS type confusion in the renderer

A custom exploit abuses the CSS engine to create type confusion and memory corruption in the renderer process. Practical weaponization likely uses heap grooming and reliability work similar to other modern browser memory-corruption chains, but no public PoC was found in the reviewed sources.
Conditions required:
  • Precise exploit targeting for the victim's Chrome build and platform
  • Renderer reachable through browser parsing of attacker content
Where this breaks in practice:
  • Browser exploit reliability is hard work; many crash, few land clean code execution
  • Chrome hardening, allocator behavior, and site isolation raise exploit engineering cost
  • Lack of public bug details and private Chromium issue access slows broad criminal adoption
Detection/coverage: Most vulnerability scanners will only flag version exposure. Runtime detection is weak unless you have browser crash telemetry, exploit-prevention hooks, or EDR heuristics for renderer abuse.
STEP 03

Gain code execution inside Chrome's sandbox

If the exploit succeeds, the attacker gets code execution in a sandboxed renderer context, not arbitrary native execution across the host. That can still be useful for session theft within the rendered context, same-origin data access, follow-on exploit staging, or chaining to a second bug.
Conditions required:
  • Successful memory corruption exploitation
  • No mitigation stopped the renderer compromise
Where this breaks in practice:
  • The sandbox is the main downward pressure on severity
  • Renderer code exec does not equal immediate OS-level control
  • Data access is constrained compared with a full endpoint compromise
Detection/coverage: EDR visibility varies because activity remains inside the browser process. Look for renderer crashes, anomalous browser child-process launches, unusual token access, or follow-on exploit primitives.
STEP 04

Escalate beyond the sandbox if the attacker wants real host impact

To turn this into a true workstation-compromise event, the attacker usually needs a second vulnerability such as a sandbox escape, broker flaw, kernel LPE, or another logic bug that widens access. Without that second stage, the blast radius is materially smaller than the CVSS confidentiality/integrity/availability triplet implies.
Conditions required:
  • Attacker has or buys a working post-renderer chain
  • Target environment lacks controls that detect or block second-stage payloads
Where this breaks in practice:
  • A second exploit is a compounding prerequisite, not a given
  • Modern EDR, ASR rules, and browser isolation can break post-exploitation steps
  • No public evidence in reviewed sources that CVE-2026-11076 is being used as part of an active chain
Detection/coverage: This is where defenders have the best shot: EDR, kernel telemetry, child-process monitoring, and lateral-movement detection are more likely to catch the follow-on than the renderer bug itself.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed exploitation found in reviewed sources, and not KEV-listed.
PoC availabilityNo public PoC located in reviewed sources as of 2026-06-05; the Chromium issue referenced by NVD is access-restricted.
EPSS0.00081 from supplied intel; percentile was not provided.
KEV statusAbsent from CISA's Known Exploited Vulnerabilities Catalog as reviewed.
CVSS meaningAV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H says *remote, easy to trigger, no privileges, but user interaction required*; the math inflates impact because it does not price in the practical value of Chrome's sandbox.
Affected versionsGoogle Chrome prior to 149.0.7827.53 on desktop; NVD CPE entry ties it to Chrome on Windows, Linux, and macOS.
Fixed version149.0.7827.53 or later; Google rolled 149.0.7827.53/.54 to Windows/Mac early stable and 149.0.7827.53 to Linux beta/stable channels around the same release window.
Packaging / distro signalUbuntu package tracking shows google-chrome-stable 149.0.7827.53-1 published on 2026-06-02 UTC, which is useful for Linux fleet validation.
Scanning / exposure realityNot internet-enumerable in any useful way: this is a client-side browser bug, so Shodan/Censys/FOFA exposure counts are largely irrelevant. You need endpoint inventory, not external ASM, to measure risk.
Disclosure / sourceCVE published 2026-06-04 in NVD. Notably, NVD carries Chrome CNA text saying "Chromium security severity: Medium" even while CISA-ADP shows 8.8/HIGH.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.5/10)

The single biggest reason this lands in MEDIUM is that successful exploitation yields renderer code execution inside Chrome's sandbox, not immediate host takeover. That one friction point turns this from a one-bug enterprise emergency into a bug that usually needs a second-stage escape or LPE to become a real endpoint-compromise event.

HIGH Affected-version boundary and fixed version
HIGH No KEV listing / no public exploitation evidence in reviewed sources
MEDIUM Exploitability assessment without public technical bug details

Why this verdict

  • Sandboxed outcome cuts the score down: the advertised impact is *code execution inside a sandbox*, which is materially weaker than native endpoint RCE.
  • User interaction is mandatory: this requires a victim to render attacker content, so it is phishing/malvertising class exposure, not unauthenticated service-side reachability.
  • No exploitation signal: not KEV-listed, no public exploitation evidence found, and the supplied EPSS 0.00081 is consistent with low near-term mass exploitation pressure.
  • Exposure is broad but shallow: Chrome is everywhere, which keeps this from being LOW, but each successful hit is usually constrained to browser context unless the attacker has a second bug.
  • Bug details are still mostly closed: the referenced Chromium issue is restricted, which slows commodity weaponization and broad copycat exploitation.

Why not higher?

This is not a higher-severity call because the exploit result stops at the Chrome sandbox. To matter like a true emergency for enterprise patch queues, you'd want active exploitation, a public reliable chain, or evidence of a bundled sandbox escape; none of that is present in the reviewed sources.

Why not lower?

This is not lower because the bug is still remote and user-reachable through normal web content on a massively deployed application. A crafted page is enough to hit the vulnerable parser path, and browser bugs can move fast once exploit dev catches up, even when early public signal is quiet.

05 · Compensating Control

What to do — in priority order.

  1. Force browser updates — Push Chrome 149.0.7827.53 or later through enterprise browser management and verify relaunch compliance. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice this is low-friction hygiene and should be folded into the next normal browser rollout.
  2. Reduce risky web ingress — Tighten email-link detonation, web filtering, Safe Browsing enforcement, DNS filtering, and ad/tracker blocking where policy allows. These controls do not fix the bug, but they cut the odds of users ever rendering the malicious page while you work through normal remediation.
  3. Watch for browser exploit symptoms — Hunt for spikes in chrome crashes, repeated renderer terminations, suspicious child processes from Chrome, and EDR exploit-prevention alerts. Use this as a compensating detection layer during the same normal remediation window.
  4. Prefer isolation for high-risk users — If you operate browser isolation or hardened VDI for admins, finance, or high-target executives, route untrusted browsing there first. This is worthwhile where available because the flaw is web-content reachable, even if it is not a stop-the-world patch item.
What doesn't work
  • A WAF does not help; the vulnerable surface is the client browser renderer, not your web server.
  • Internet attack-surface scanners do not meaningfully measure exposure here; you need endpoint inventory because browsers are not server banners.
  • MFA is good security but irrelevant to exploit prevention for this bug; it doesn't stop malicious HTML from hitting the renderer.
  • Relying on "Chrome auto-updates eventually" is not a control if your fleet tolerates long-running browser sessions without relaunch.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your endpoint management tooling to validate the installed Google Chrome version locally. Invoke it with python3 check_cve_2026_11076.py; standard user rights are usually enough because it only reads local executable/version information, though some locked-down endpoints may need elevated access to certain install paths.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_11076.py
# Verifies whether installed Google Chrome is vulnerable to CVE-2026-11076.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys
from typing import Optional, Tuple

FIXED_VERSION = (149, 0, 7827, 53)


def parse_version(text: str) -> Optional[Tuple[int, int, int, int]]:
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def run_and_parse(cmd):
    try:
        proc = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        combined = (proc.stdout or '') + '\n' + (proc.stderr or '')
        return parse_version(combined)
    except Exception:
        return None


def windows_version() -> Optional[Tuple[int, int, int, int]]:
    candidates = [
        os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('LocalAppData', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
    ]

    for path in candidates:
        if path and os.path.exists(path):
            v = run_and_parse([path, '--version'])
            if v:
                return v

    # Fallback to WMIC/PowerShell-friendly file metadata via Python only is messy; stick to executable check.
    return None


def macos_version() -> Optional[Tuple[int, int, int, int]]:
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]
    for path in candidates:
        if os.path.exists(path):
            v = run_and_parse([path, '--version'])
            if v:
                return v
    return None


def linux_version() -> Optional[Tuple[int, int, int, int]]:
    commands = ['google-chrome', 'google-chrome-stable', 'chrome']
    for cmd in commands:
        full = shutil.which(cmd)
        if full:
            v = run_and_parse([full, '--version'])
            if v:
                return v

    # Package fallback for Debian/Ubuntu family
    if shutil.which('dpkg-query'):
        try:
            proc = subprocess.run(['dpkg-query', '-W', '-f=${Version}', 'google-chrome-stable'], stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
            v = parse_version(proc.stdout or '')
            if v:
                return v
        except Exception:
            pass

    # Package fallback for RPM family
    if shutil.which('rpm'):
        try:
            proc = subprocess.run(['rpm', '-q', '--qf', '%{VERSION}', 'google-chrome-stable'], stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
            v = parse_version(proc.stdout or '')
            if v:
                return v
        except Exception:
            pass

    return None


def compare_versions(found: Tuple[int, int, int, int], fixed: Tuple[int, int, int, int]) -> int:
    if found < fixed:
        return -1
    if found > fixed:
        return 1
    return 0


def main():
    system = platform.system().lower()
    version = None

    if 'windows' in system:
        version = windows_version()
    elif 'darwin' in system:
        version = macos_version()
    elif 'linux' in system:
        version = linux_version()
    else:
        print('UNKNOWN: unsupported platform {}'.format(platform.system()))
        sys.exit(2)

    if not version:
        print('UNKNOWN: Google Chrome version not found')
        sys.exit(2)

    cmp_result = compare_versions(version, FIXED_VERSION)
    version_str = '.'.join(str(x) for x in version)
    fixed_str = '.'.join(str(x) for x in FIXED_VERSION)

    if cmp_result < 0:
        print(f'VULNERABLE: installed Google Chrome {version_str} is older than fixed {fixed_str}')
        sys.exit(1)
    else:
        print(f'PATCHED: installed Google Chrome {version_str} is at or newer than fixed {fixed_str}')
        sys.exit(0)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as browser patch hygiene with real reachability but constrained impact: use endpoint inventory to find Chrome versions below 149.0.7827.53, validate relaunch compliance, and roll the update through your standard browser channel. Because the reassessed bucket is MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window under the noisgate remediation SLA, but most enterprises should still close this far sooner because browser updates are operationally cheap and web-content reachability is constant.

Sources

  1. NVD entry for CVE-2026-11076
  2. Chrome early stable desktop update to 149.0.7827.53/.54
  3. Chrome beta desktop update to 149.0.7827.53
  4. GovCERT.HK advisory for Chrome vulnerabilities
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS API documentation
  7. Ubuntu package tracking for google-chrome-stable
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.