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

Out of bounds write in Codecs in Google Chrome prior to 149

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

This is a cracked window in the browser engine, not proof the burglar already got through the vault door

The public Chrome release material shows CVE-2026-11037 as an out-of-bounds write in Codecs fixed in Chrome 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and Mac, released on 2026-06-02. A malicious site or media payload could plausibly trigger memory corruption in the browser's content-processing path, but the public advisory does not describe this as host-level remote code execution or a proven sandbox escape.

The severity in your intel block does not match Google's public record. Google publicly classed this issue as Medium in the Chrome 149 stable release notes, and I could not verify a CVE.org or NVD record carrying the Critical 9.6 claim as of 2026-06-05. For a fleet defender, that mismatch matters: the realistic story is 'client-side memory corruption, likely chainable, but not shown to break out on its own' rather than 'single-click host compromise.'

"This looks like browser-memory-corruption debt, not a drop-everything Chrome sandbox escape."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on attacker-controlled content

The attacker needs a user to open a malicious page or otherwise process attacker-supplied media in Chrome. The obvious delivery vehicle is a crafted HTML page or embedded media object that exercises the vulnerable codec path. Weaponized tooling here is standard exploit-delivery web content rather than a special server-side exploit framework.
Conditions required:
  • Target runs Chrome below 149.0.7827.53/.54
  • User interaction is available
  • Attacker can serve or influence media content viewed in Chrome
Where this breaks in practice:
  • This is UI:R; no clickless network daemon exposure
  • Enterprise filtering, Safe Browsing, mail/web gateways, and user isolation reduce reach
  • Attackers must hit the right codec path on the right build
Detection/coverage: Version scanners can identify vulnerable builds. Network signatures are weak because the trigger is likely content-specific and bug details remain restricted.
STEP 02

Trigger the out-of-bounds write in Codecs

The malicious content must corrupt memory inside Chrome's codec-handling logic. An out-of-bounds write is technically dangerous because it can crash the process or, with enough grooming and reliability work, enable code execution in the compromised browser process. Likely weaponization would be custom HTML/JS plus malformed media data rather than a commodity off-the-shelf kit.
Conditions required:
  • Precise bug trigger for the restricted Chromium issue
  • Target architecture and allocator behavior align with exploit assumptions
Where this breaks in practice:
  • No public PoC was found
  • Bug details are still restricted, which slows reliable weaponization
  • Modern browser hardening makes stable memory-corruption exploitation non-trivial
Detection/coverage: Browser crash telemetry, EDR child-process anomalies, and unusual renderer crashes are your best signals. Commodity scanners will not prove exploitability.
STEP 03

Convert corruption into useful execution

Even if the codec bug is exploitable, the first realistic win is execution within a constrained browser context, not automatic host takeover. In Chrome, memory-corruption bugs commonly need exploit engineering for renderer-level execution and then a second bug for meaningful sandbox escape or privilege elevation. Public material for this CVE does not show that second stage.
Conditions required:
  • Attacker can turn the memory bug into reliable code execution
  • Browser mitigations such as sandboxing and process isolation are still bypassed or sidestepped
Where this breaks in practice:
  • No public evidence this CVE alone escapes the sandbox
  • The prompt's sandbox-escape wording is not corroborated by Google's release note
  • Separate chain components are typically required
Detection/coverage: EDR can catch unusual browser process behavior better than perimeter tools. Pure vulnerability scanners cannot validate this stage.
STEP 04

Reach host impact through a follow-on chain

To get from a browser content bug to enterprise-impacting host compromise, the attacker usually needs a sandbox escape, local privilege escalation, or credential/session theft opportunity. That is where most real-world severity inflation happens: people score the *end-state* of a full exploit chain onto a single client-side bug. For this CVE, the public evidence supports 'chain component' more than 'full chain.'
Conditions required:
  • A second vulnerability or design bypass exists
  • Target protections do not stop post-browser activity
Where this breaks in practice:
  • Requires prior success in earlier stages
  • EDR, application control, and browser sandboxing compound the failure points
  • Blast radius is per-user workstation, not instant internet-wide server compromise
Detection/coverage: Look for browser-to-system process pivots, abnormal downloads, and credential access behavior. Exposure search engines like Shodan/Censys are not useful because this is a client-side browser flaw.
03 · Intelligence Metadata

The supporting signals.

Official public severityGoogle's 2026-06-02 Chrome 149 stable release publicly lists CVE-2026-11037 as Medium, not Critical.
Public record mismatchAs of 2026-06-05, I could not verify a matching CVE.org or NVD record for this CVE carrying the prompt's 9.6 / CRITICAL metadata.
In-the-wild statusNo public statement from Google indicating active exploitation was found for this CVE.
KEV statusNot listed in CISA's Known Exploited Vulnerabilities catalog.
EPSSUser-provided EPSS 0.00035 (~0.035% modeled 30-day exploitation probability). I did not verify the percentile from a public CVE record.
PoC availabilityNo public proof-of-concept exploit repo or researcher write-up was found in open sources.
Affected versionsPublic Chrome release notes indicate fixes in 149.0.7827.53 (Linux) and 149.0.7827.53/.54 (Windows/Mac), implying earlier builds are affected.
Fixed versionsPatch to Chrome 149.0.7827.53+; for Windows/Mac use 149.0.7827.54 where that build is deployed.
CVSS interpretationThe prompt's vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H describes a user-interaction client-side bug scored like full chain impact. That is precisely what I do not buy from the public evidence.
Scanning / exposure dataThis is a client-side browser issue, so Shodan/Censys/FOFA internet exposure counts are not operationally meaningful. Your exposure question is fleet version coverage, not open ports.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.2/10)

The decisive factor is that the public Google record supports a client-side memory-corruption bug but does not support the prompt's stronger claim of a standalone sandbox escape. That turns this from a supposed internet-scale workstation compromise into a more ordinary 'user must be reached, bug must be made reliable, and host impact likely needs a second stage' browser issue.

HIGH Google publicly classed this CVE as Medium in Chrome 149 release material
MEDIUM Downgrade from Critical to Medium based on attack-chain friction
LOW Exact exploitability details of the restricted Chromium bug

Why this verdict

  • Baseline correction: Google's public Chrome 149 release note lists CVE-2026-11037 as Medium, so the starting point is already lower than the prompt's Critical 9.6 claim.
  • Client-side prerequisite: The bug needs user interaction and attacker-controlled content delivery. That immediately narrows reachable population versus unauthenticated server-side exposure.
  • Chain inflation penalty: Public evidence supports 'out-of-bounds write in Codecs,' not a proven sandbox escape. If host compromise needs a second bug, scoring this CVE like the full chain overstates reality.
  • Exploit maturity is weak: I found no KEV entry, no public exploitation note, and no public PoC. That is real downward pressure for a patch queue managing thousands of endpoints.
  • Enterprise defenses matter here: Browser sandboxing, Safe Browsing, EDR, and content filtering all sit directly in the path. These controls do not make the bug harmless, but they do reduce the chance that one malformed page becomes a fleet-wide incident.

Why not higher?

I do not have public evidence that this CVE alone gives reliable code execution on the host or escapes Chrome's sandbox. The strongest public source available says Medium, and there is no corroborated active-exploitation signal forcing an emergency override.

Why not lower?

It is still an out-of-bounds write in a massively deployed browser, reachable through normal user browsing. Memory-corruption bugs in browsers are valuable chain components, so dismissing it as mere backlog noise would be too casual.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update — Make sure Chrome update services, enterprise policies, and relaunch prompts are actually functioning across managed endpoints. Because this lands in MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window; this control is mainly to collapse long-tail stragglers before they turn into permanent exposure.
  2. Force relaunch on stale versions — Users sitting on patched binaries without restarting are common in large fleets. Use your browser management platform to warn, then force-close long-running stale sessions so patched versions are actually activated during the 365-day remediation window.
  3. Isolate high-risk browsing — For admins, finance, help desk, and researchers who routinely touch untrusted content, route browsing through VDI, remote browser isolation, or separate low-privilege workstations. There is no mitigation SLA for a MEDIUM finding, but this is worthwhile defense-in-depth until patch coverage is complete.
  4. Watch crash and EDR telemetry — Track unusual Chrome renderer crashes, repeat codec-related faults, and browser-to-system process pivots. Use this during the 365-day remediation window to catch the small chance that a supposedly low-signal bug starts getting weaponized.
What doesn't work
  • A WAF does not meaningfully protect a client browser from malicious public web content viewed by users.
  • Perimeter port scanning tells you nothing useful here; this is not an internet-facing daemon exposure problem.
  • MFA is still important, but it does not prevent exploitation of a browser memory-corruption flaw once a user opens the content.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your software-distribution/EDR script runner. Invoke it with python3 check_chrome_cve_2026_11037.py on macOS/Linux or py check_chrome_cve_2026_11037.py on Windows; it needs only normal user rights because it reads local app paths and common registry locations.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11037.py
# Determine whether local Google Chrome installation is below fixed versions
# for CVE-2026-11037.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import os
import platform
import re
import subprocess
import sys

FIXED = (149, 0, 7827, 53)
WINDOWS_FIXED_MAC_PATCH = 54  # Windows/Mac may be .53 or .54 depending on channel rollout; .53 is fixed per release note, .54 also fixed.


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


def version_lt(a, b):
    return a < b


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


def windows_candidates():
    cands = []
    env_paths = [
        os.path.join(os.environ.get('ProgramFiles', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('ProgramFiles(x86)', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('LocalAppData', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
    ]
    for p in env_paths:
        if p and os.path.exists(p):
            cands.append(p)
    return list(dict.fromkeys(cands))


def get_windows_version(path):
    ps = [
        'powershell', '-NoProfile', '-Command',
        f"(Get-Item '{path}').VersionInfo.ProductVersion"
    ]
    return parse_version(run_cmd(ps))


def mac_candidates():
    cands = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]
    return [p for p in cands if os.path.exists(p)]


def linux_candidates():
    names = [
        'google-chrome', 'google-chrome-stable', 'chrome',
        '/opt/google/chrome/chrome', '/usr/bin/google-chrome', '/usr/bin/google-chrome-stable'
    ]
    cands = []
    for n in names:
        if n.startswith('/'):
            if os.path.exists(n):
                cands.append(n)
        else:
            out = run_cmd(['sh', '-c', f'command -v {n}'])
            if out:
                cands.append(out.splitlines()[0].strip())
    return list(dict.fromkeys(cands))


def get_unix_version(path):
    out = run_cmd([path, '--version'])
    return parse_version(out)


def status_for_version(ver, system_name):
    if ver is None:
        return 'UNKNOWN'
    # Public release note says Linux fixed at .53 and Windows/Mac at .53/.54.
    # Treat 149.0.7827.53+ as patched across platforms for this check.
    if version_lt(ver, FIXED):
        return 'VULNERABLE'
    return 'PATCHED'


def main():
    system_name = platform.system()
    findings = []

    if system_name == 'Windows':
        for path in windows_candidates():
            ver = get_windows_version(path)
            findings.append((path, ver, status_for_version(ver, system_name)))
    elif system_name == 'Darwin':
        for path in mac_candidates():
            ver = get_unix_version(path)
            findings.append((path, ver, status_for_version(ver, system_name)))
    else:
        for path in linux_candidates():
            ver = get_unix_version(path)
            findings.append((path, ver, status_for_version(ver, system_name)))

    if not findings:
        print('UNKNOWN - Google Chrome not found in standard locations')
        sys.exit(2)

    vulnerable = [f for f in findings if f[2] == 'VULNERABLE']
    patched = [f for f in findings if f[2] == 'PATCHED']

    for path, ver, state in findings:
        vtxt = '.'.join(str(x) for x in ver) if ver else 'unreadable'
        print(f'{state} - {path} - version {vtxt}')

    if vulnerable:
        print('VULNERABLE')
        sys.exit(1)
    elif patched:
        print('PATCHED')
        sys.exit(0)
    else:
        print('UNKNOWN')
        sys.exit(2)


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

If you remember one thing.

TL;DR
Monday morning: treat this as a browser-version hygiene issue, not a full-blown incident-response fire drill. Validate which endpoints are still below 149.0.7827.53/.54, make sure auto-update and forced relaunch are working, and clean up stragglers in the next routine browser wave. Because the reassessed verdict is MEDIUM and I found no KEV listing or active exploitation evidence, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; your noisgate remediation SLA is to get the actual vendor patch deployed within 365 days.

Sources

  1. Chrome Stable Channel Update for Desktop (Chrome 149, June 2 2026)
  2. Chrome Releases 2026 archive (contains CVE-2026-11037 entry listed as Medium)
  3. Chrome Early Stable Update for Desktop (149.0.7827.53/.54)
  4. Chrome Beta for Desktop Update (149.0.7827.53)
  5. Chromium security page
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS overview
  8. FIRST EPSS API documentation
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.