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

Use after free in Codecs in Google Chrome prior to 149

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

This is a peephole in a crowded office, not a master key to the building

CVE-2026-11208 is a use-after-free in Chrome's Codecs component that affects Google Chrome before 149.0.7827.53; Google's stable desktop release notes show the fix shipping as 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows and Mac. The published impact is information disclosure from process memory after a victim renders a crafted HTML page that exercises media/codec handling.

Google rated it Medium 6.5, and in real enterprise conditions that feels slightly generous but still in the right bucket. The web reach is broad because Chrome is everywhere, but the chain still needs user interaction, the disclosed effect is memory disclosure rather than code execution, and Chrome's sandbox and site isolation materially reduce the blast radius compared with classic browser RCEs.

"Wide exposure, low weaponization: this is a browse-to memory leak, not a browser takeover"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker-controlled content

The weaponized tool here is a crafted HTML page with attacker-controlled media logic; no public PoC repo was found in retrieved sources, so assume a private/custom exploit. Delivery is the usual browser path: phishing link, malvertising, compromised site, or embedded content in a trusted page.
Conditions required:
  • Victim runs Chrome older than 149.0.7827.53
  • Victim must browse to attacker-controlled or attacker-influenced content
  • Attacker needs internet reach to the user, not to the endpoint directly
Where this breaks in practice:
  • Requires UI:R; this is not a wormable or scan-and-own condition
  • Email filtering, DNS filtering, SWG, and ad blocking all cut delivery volume
  • Enterprise users do not uniformly browse arbitrary media-heavy sites
Detection/coverage: Exposure scanners will not see this reliably because it is a client-side browser flaw. Detection is mostly indirect: browser version inventory, proxy logs to suspicious lure domains, and endpoint/browser telemetry.
STEP 02

Trigger the codec lifetime bug

Once the page loads, the attacker uses JavaScript + media content orchestration to drive the Codecs path into a use-after-free condition. In practice that means shaping object lifetime and timing so freed memory is referenced again during media processing.
Conditions required:
  • The vulnerable codec path must be reachable from the victim's platform/build
  • The page must successfully trigger the specific buggy state machine
Where this breaks in practice:
  • Memory corruption reliability is notoriously brittle across OS, architecture, and build differences
  • Restricted bug details mean opportunistic actors have less implementation guidance today
  • Crash-only behavior is common before a leak becomes stable and useful
Detection/coverage: EDR usually will not label this by CVE at trigger time. Chrome crash telemetry, renderer crashes, and unusual browser process instability are the best weak signals.
STEP 03

Harvest process memory

The exploit goal described in the advisory is reading potentially sensitive data from process memory, not arbitrary code execution. The practical tool is a custom in-browser memory disclosure primitive that attempts to recover fragments such as page data, tokens, or cross-origin material that happened to share the affected process boundary.
Conditions required:
  • The memory disclosure must return useful bytes, not just crash noise
  • Sensitive material must be present in or reachable from the affected process
Where this breaks in practice:
  • Chrome's site isolation and multi-process model sharply limit what sits in one compromised renderer/process context
  • The published impact is confidentiality-only; no write primitive or sandbox escape is claimed
  • Useful secrets may simply not be present in the leaked region at exploit time
Detection/coverage: There is no dependable network signature for the read itself. Focus on browser hardening posture, managed policies, and version compliance rather than exploit-pattern IDS.
STEP 04

Convert leaked data into real damage

The attacker still has to monetize the leak: session theft, internal page reconnaissance, follow-on phishing, or chaining into a second browser/OS flaw. This is where many medium browser disclosures die in the lab because a memory read is not the same thing as durable enterprise compromise.
Conditions required:
  • Leaked data must be sensitive and reusable
  • Attacker needs a path to operationalize the disclosed data quickly
Where this breaks in practice:
  • No evidence of active exploitation or public chaining was found
  • Short-lived tokens, conditional access, and device-bound auth reduce replay value
  • Modern EDR, identity controls, and MFA blunt post-leak monetization
Detection/coverage: Downstream detection is more likely than exploit-stage detection: stolen-session anomalies, impossible travel, unusual SaaS token reuse, and suspicious web app access.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo current evidence of exploitation found in retrieved sources, and not listed in CISA KEV as of 2026-06-05
Public PoC availabilityNo public GitHub/Exploit-DB PoC located in retrieved sources; Chromium bug details remain restricted, which slows commodity weaponization
EPSS0.00028 from the provided intel; retrieved FIRST sources confirm EPSS semantics and API, but a percentile for this CVE was not validated from retrieved data
KEV statusNot KEV-listed; no CISA due date applies
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N = remote, no auth, user interaction required, confidentiality-only impact
Affected versionsGoogle Chrome prior to 149.0.7827.53 on desktop platforms covered by the advisory/NVD enrichment
Fixed versionsGoogle stable desktop shipped the fix in 149.0.7827.53 (Linux) and 149.0.7827.53/.54 (Windows/Mac); downstream Chromium/Electron backports were not established in retrieved sources
Exposure realityThis is a client-side browser bug, so Shodan/Censys-style internet scanning is not a useful exposure measure. The practical amplifier is install base: StatCounter shows Chrome at 73.26% desktop share worldwide in February 2026
Disclosure timelineCVE published 2026-06-04; Chrome stable desktop release posted 2026-06-02; Chromium issue listed as reported 2026-04-25
ReporterReported by Google according to the Chrome stable release notes; Chromium issue reference: 506387278
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.3/10)

The decisive factor is that the published impact is information disclosure only inside a browser process, not code execution or sandbox escape. Broad deployment keeps this from falling to LOW, but the combination of user-interaction requirement, no exploitation evidence, and Chrome isolation controls keeps it out of HIGH.

HIGH Metadata and affected/fixed version mapping
MEDIUM Real-world exploitability assessment

Why this verdict

  • Downgrade for attacker position and user interaction: the attacker is remote and unauthenticated, but they still need a user to render malicious web content; that is a real delivery dependency, not a paperwork footnote.
  • Downgrade for impact realism: the advisory describes process-memory disclosure only. That is materially weaker than the browser RCEs that actually force emergency patching across a 10,000-host fleet.
  • Downgrade for process isolation: Chrome's sandbox and site isolation mean the leak usually lands in a narrower process boundary than the raw C:H label suggests, so the practical blast radius is often limited.
  • Keep at MEDIUM for population size: Chrome is massively deployed, so even a middling browse-to flaw can touch a lot of endpoints if delivery succeeds.
  • Keep below HIGH for threat intel: no KEV listing, no public exploitation, and a very low EPSS are strong signals that this is not currently attracting broad attacker attention.

Why not higher?

To justify HIGH here, I would want either active exploitation, a public reliable PoC, or stronger impact such as code execution, sandbox escape, or credential theft demonstrated at scale. We do not have that. This looks like a bug that may be useful in a chain, but on its own it does not clear the bar for accelerated enterprise-wide disruption.

Why not lower?

It should not be LOW because the attack surface is still the web browser, the victim requirement is only visiting content, and Chrome's footprint in enterprise fleets is enormous. Confidentiality-only browser leaks are still useful to attackers when they can scrape session material or page data from high-value users.

05 · Compensating Control

What to do — in priority order.

  1. Enforce managed auto-update — Make sure Chrome update policies are functioning and that deferred rings are not pinning users below the fixed build. For a MEDIUM verdict there is no mitigation SLA, so treat this as browser hygiene while the patch rolls through the normal channel.
  2. Lock site isolation on — Use Chrome Enterprise policy to keep Site Isolation enforced for managed browsers so sensitive sites and origins stay split across processes. This does not fix the bug, but it reduces what a renderer/process memory disclosure can realistically expose; no mitigation SLA applies for MEDIUM.
  3. Reduce lure exposure — Tighten secure web gateway, DNS filtering, ad blocking, and phishing controls for unmanaged browsing paths and high-risk user groups. This directly attacks the UI:R prerequisite; for MEDIUM there is no mitigation SLA, so deploy through normal control-change cadence.
  4. Watch browser version drift — Query endpoint inventory for Chrome versions below 149.0.7827.53 and isolate rings or business units with update failures. The value here is operational: find the stale population that turns a medium browser CVE into a chronic exposure; no mitigation SLA applies for MEDIUM.
What doesn't work
  • A WAF does not help; the exploit runs in the client browser, not against your server-side application.
  • Network perimeter blocking of inbound traffic is largely irrelevant; the delivery path is outbound web browsing to malicious content.
  • MFA does not prevent the vulnerability trigger itself; it only helps if attackers later try to monetize leaked session material.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your endpoint management tool. Invoke it as python3 check_chrome_cve_2026_11208.py --min-version 149.0.7827.53; it needs no admin rights for standard checks and prints VULNERABLE, PATCHED, or UNKNOWN with exit codes 1, 0, and 2 respectively.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11208.py
# Determine whether Google Chrome is below the fixed version for CVE-2026-11208.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import argparse
import os
import platform
import re
import subprocess
import sys

DEFAULT_MIN = '149.0.7827.53'


def parse_version(v):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', v or '')
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def cmp_versions(a, b):
    return (a > b) - (a < b)


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        return p.returncode, (p.stdout or '').strip(), (p.stderr or '').strip()
    except Exception:
        return 1, '', ''


def get_windows_version():
    candidates = [
        [r'reg', 'query', r'HKLM\Software\Google\Chrome\BLBeacon', '/v', 'version'],
        [r'reg', 'query', r'HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon', '/v', 'version'],
        [r'reg', 'query', r'HKCU\Software\Google\Chrome\BLBeacon', '/v', 'version'],
    ]
    for cmd in candidates:
        rc, out, _ = run_cmd(cmd)
        if rc == 0:
            m = re.search(r'version\s+REG_\w+\s+([^\s]+)', out, re.IGNORECASE)
            if m:
                return m.group(1)
    exe_paths = [
        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 exe in exe_paths:
        if exe and os.path.exists(exe):
            rc, out, _ = run_cmd([exe, '--version'])
            if rc == 0 and out:
                return out
    return None


def get_macos_version():
    exe = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
    if os.path.exists(exe):
        rc, out, _ = run_cmd([exe, '--version'])
        if rc == 0 and out:
            return out
    plist = '/Applications/Google Chrome.app/Contents/Info.plist'
    if os.path.exists(plist):
        rc, out, _ = run_cmd(['/usr/bin/defaults', 'read', plist, 'KSVersion'])
        if rc == 0 and out:
            return out
        rc, out, _ = run_cmd(['/usr/bin/defaults', 'read', plist, 'CFBundleShortVersionString'])
        if rc == 0 and out:
            return out
    return None


def get_linux_version():
    commands = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['chromium-browser', '--version'],
        ['chromium', '--version'],
    ]
    for cmd in commands:
        rc, out, _ = run_cmd(cmd)
        if rc == 0 and out:
            return out
    known_paths = [
        '/opt/google/chrome/google-chrome',
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        '/snap/bin/chromium',
        '/usr/bin/chromium-browser',
        '/usr/bin/chromium',
    ]
    for path in known_paths:
        if os.path.exists(path):
            rc, out, _ = run_cmd([path, '--version'])
            if rc == 0 and out:
                return out
    return None


def main():
    ap = argparse.ArgumentParser(description='Check Google Chrome version against CVE-2026-11208 fixed version')
    ap.add_argument('--min-version', default=DEFAULT_MIN, help='Fixed minimum version (default: %(default)s)')
    args = ap.parse_args()

    min_v = parse_version(args.min_version)
    if not min_v:
        print('UNKNOWN - invalid --min-version')
        sys.exit(2)

    system = platform.system().lower()
    raw_version = None

    if 'windows' in system:
        raw_version = get_windows_version()
    elif 'darwin' in system:
        raw_version = get_macos_version()
    elif 'linux' in system:
        raw_version = get_linux_version()
    else:
        print(f'UNKNOWN - unsupported platform: {platform.system()}')
        sys.exit(2)

    if not raw_version:
        print('UNKNOWN - Chrome not found or version unreadable')
        sys.exit(2)

    found_v = parse_version(raw_version)
    if not found_v:
        print(f'UNKNOWN - could not parse version from: {raw_version}')
        sys.exit(2)

    if cmp_versions(found_v, min_v) < 0:
        print(f'VULNERABLE - found {raw_version}, requires >= {args.min_version}')
        sys.exit(1)
    else:
        print(f'PATCHED - found {raw_version}, meets >= {args.min_version}')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, pull a version inventory for Chrome and identify endpoints still below 149.0.7827.53; this is a MEDIUM reassessment, so there is no noisgate mitigation SLA — go straight to the 365-day remediation window. In practice, because this is a browser and auto-update exists, validate that managed update policy is actually moving the fleet now, document any exception rings, and complete the vendor patch rollout within the noisgate remediation SLA of 365 days; unlike KEV or actively exploited browser bugs, this one does not justify an hours-level fire drill.

Sources

  1. NVD entry for CVE-2026-11208
  2. Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  3. Chromium issue 506387278
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS API documentation
  6. Chromium Site Isolation documentation
  7. Chromium Chrome sandbox diagnostics for Windows
  8. StatCounter desktop browser market share worldwide
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.