CVE-2026-11211 · Integer overflow in V8 in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to execute arbitrary code inside a sandbox via a cr

01 · The Real Story

This is a burglar getting into the lobby, not the vault

CVE-2026-11211 is an integer overflow in Chrome's V8 JavaScript engine. A victim has to load attacker-controlled HTML, and the result described by Google is arbitrary code execution *inside the browser sandbox*, not native code execution on the host. Affected builds are Google Chrome prior to 149.0.7827.53; Google's desktop release notes say the fixed builds are 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS.

The supplied vendor baseline of HIGH 8.8 overshoots how defenders should queue this in practice. The decisive downgrade factors are: it is a client-side bug, it requires user interaction, Google itself labels the Chromium security severity as Medium, and the stated impact stops at renderer-sandbox code execution unless the attacker also has a second bug for sandbox escape or privilege elevation.

"Real bug, but it lands inside Chrome's sandbox and needs a user to browse into it."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver crafted HTML/JS

The attacker hosts or injects a malicious page and waits for a target to render it in a vulnerable Chrome build. The practical weapon here is just custom HTML and JavaScript; no public exploit kit or PoC repository was found in the sources reviewed.

Conditions required:

Target is running Chrome earlier than 149.0.7827.53
Target browses to attacker-controlled or attacker-influenced content
JavaScript execution is permitted

Where this breaks in practice:

This is *user-driven* exposure, not an externally reachable daemon
Enterprise URL filtering, Safe Browsing, mail-link rewriting, and ad blocking cut volume
Many fleets auto-update Chrome quickly, shrinking the vulnerable window

Detection/coverage: Version scanners and EDR software inventory catch the vulnerable build reliably; network detection for the exploit itself is weak without a public PoC.

STEP 02

Trigger the V8 integer overflow

A crafted script path reaches the vulnerable V8 code and causes memory corruption through integer overflow conditions. In the absence of public exploit details, assume the attacker needs careful heap shaping and engine-specific reliability work rather than a copy-paste trigger.

Conditions required:

Reachable vulnerable V8 code path
Exploit reliability against the victim's platform and build

Where this breaks in practice:

No public technical write-up or exploit chain was found
Modern browser hardening, crash telemetry, and per-release variability make reliability harder
Google kept the issue tracker restricted pending patch uptake

Detection/coverage: Behavioral EDR may see browser crashes or anomalous child-process behavior, but commodity scanners cannot validate exploitability beyond version presence.

STEP 03

Achieve renderer-process code execution

If exploitation succeeds, the attacker gets code execution in the Chrome renderer context. That is bad, but it is still boxed inside Chrome's sandbox according to the CVE description and release note language.

Conditions required:

Successful memory-corruption exploitation
Renderer compromise without immediate crash

Where this breaks in practice:

Renderer compromise alone does not equal host compromise
Site Isolation, sandboxing, and browser process boundaries reduce blast radius
The attacker still lacks durable endpoint control

Detection/coverage: Look for abnormal Chrome renderer crashes, exploit-guard hits, or EDR detections tied to browser memory exploitation.

STEP 04

Chain a sandbox escape for real endpoint impact

To turn this into workstation compromise, the attacker normally needs a second vulnerability: a sandbox escape, local privilege escalation, or another trusted execution bridge. That second-stage dependency is the biggest downward pressure on severity for enterprise patch queues.

Conditions required:

Additional exploit beyond CVE-2026-11211
A path from renderer sandbox to host or sensitive enterprise data

Where this breaks in practice:

No chained exploitation evidence was found
A second bug sharply narrows attacker success rate and campaign economics
Modern EDR, OS exploit mitigations, and least-privilege controls often break the follow-on stage

Detection/coverage: Detection gets better here: child-process spawn anomalies, LOLBin abuse, token theft, or post-browser persistence attempts are visible to EDR.

03 · Intelligence Metadata

The supporting signals.

In-the-wild status	No public evidence of active exploitation was found. Not in CISA KEV as of `2026-06-06`, and Google's release post does not flag it as exploited.
Public PoC availability	No public exploit repo, Metasploit module, or technical PoC write-up was found in the sources reviewed. The Chromium issue remains restricted, which usually means exploit details are intentionally withheld during patch adoption.
EPSS	`0.00038` (~`0.038%` 30-day exploitation probability). That is effectively near the floor; very low exploit-likelihood pressure compared with browser zero-days that actually move patch queues.
KEV status	Not KEV-listed. Disclosure reached NVD on `2026-06-04`; there is no CISA KEV add date because it is absent from the catalog.
Severity discrepancy	Your supplied baseline is HIGH 8.8 with `AV:N/AC:L/PR:N/UI:R/...`, but both the NVD record and Google's release notes state Chromium security severity: Medium. For defenders, the sandbox-limited impact is the reason.
CVSS vector reality check	`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H` assumes full endpoint impact after a user visit. In practice, this CVE's published effect is code execution inside the sandbox, so the vector overstates enterprise blast radius unless paired with a second bug.
Affected versions	Google Chrome before `149.0.7827.53`. The Canadian Centre for Cyber Security summarizes desktop exposure as versions prior to `149.0.7827.53/54` on Windows/macOS and prior to `149.0.7827.53` on Linux.
Fixed versions	Fixed in Chrome `149.0.7827.53` on Linux and `149.0.7827.53/.54` on Windows/macOS. Chromium-based downstream browsers will pick up the fix on their own schedules; don't assume forked browsers are covered just because Chrome is.
Scanning and exposure data	This is client software, so Shodan/Censys/FOFA-style internet census is the wrong instrument. Exposure tracks how many managed endpoints browse untrusted content and how quickly Chrome auto-update lands, not how many hosts expose a listening service.
Disclosure and reporter	Published to NVD on `2026-06-04`. Google's stable desktop release shipped on `2026-06-02`, and the release notes say the bug was reported by Google on 2026-04-26.

04 · The Call

noisgate verdict.

Final Verdict

↓ DOWNGRADED to MEDIUM (6.4/10)

The single most important limiter is that the publicly stated impact stops at renderer-sandbox code execution. Without evidence of a working sandbox-escape chain or active exploitation, this is a real browser bug but not a drop-everything enterprise emergency.

HIGH Affected version range and fixed builds

MEDIUM Exploitability and practical enterprise impact

MEDIUM Absence of public PoC and in-the-wild exploitation evidence

Why this verdict

Downgrade for sandbox-only impact: the CVE description explicitly says arbitrary code execution occurs *inside the sandbox*, which is a materially smaller blast radius than host-level RCE.
Downgrade for attacker path: the exploit path starts with a user visiting malicious content, which implies phishing, malvertising, or watering-hole delivery rather than direct unauthenticated remote reachability to a service.
Downgrade for chain dependency: meaningful workstation compromise usually requires a second vulnerability for sandbox escape or privilege escalation, and that dependency compounds friction.
Downgrade for threat intel: no KEV listing, no public exploitation evidence, and an EPSS of 0.00038 do not support treating this like an actively weaponized browser zero-day.
Baseline correction: Google's own release notes and the NVD entry classify the Chromium security severity as Medium, which aligns better with the stated impact than the supplied 8.8 baseline.

Why not higher?

If this had evidence of active exploitation, a public reliable exploit, or host-level code execution outside the sandbox, it would move up fast. But as published, the path requires user interaction and stops at a sandboxed renderer unless the attacker also brings a second bug.

Why not lower?

It is still memory corruption in V8, exposed through ordinary web content, on a massively deployed browser. Even sandboxed renderer compromise can matter for session theft, in-browser actions, and as a first stage in a chained attack, so this is not backlog fluff.

05 · Compensating Control

What to do — in priority order.

Force browser auto-update health — Verify Chrome update services, MDM/GPO policies, and ring deployment are actually moving endpoints to 149.0.7827.53+. For a MEDIUM verdict there is no mitigation SLA, so use this as routine control hardening and go straight toward patch completion within the 365-day remediation window.
Reduce untrusted web exposure on high-risk users — Apply stricter web filtering, browser isolation, or hardened browsing profiles for admins, finance, executives, and users exposed to phishing or research traffic. There is no mitigation SLA for MEDIUM, so do this where the control already exists rather than launching a disruptive emergency project.
Alert on stale Chrome versions — Use EDR, software inventory, or Chrome Browser Cloud Management to flag endpoints below 149.0.7827.53. This is the most reliable control because exploit detection is weak while version-state detection is straightforward; for MEDIUM, work it through normal operations into the remediation window.
Harden browser child-process policy — Keep EDR browser exploit protections, attack surface reduction, and suspicious child-process alerts enabled. These will not prevent the V8 bug itself, but they can catch the follow-on behavior that matters if an attacker tries to turn renderer access into host impact.

What doesn't work

A perimeter vulnerability scan will not tell you much here, because Chrome is endpoint client software rather than a remotely exposed service.
Relying on CVSS alone does not help, because the whole overstatement here is treating sandboxed renderer execution like full endpoint compromise.
MFA does not materially reduce exploitability of a malicious webpage delivered to a logged-in user.

06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint itself, or through your EDR/remote-exec tooling, because it inspects the locally installed Chrome binary version. Invoke it with python3 check_chrome_cve_2026_11211.py or pass a version explicitly with python3 check_chrome_cve_2026_11211.py --version 149.0.7827.54; no administrator rights are normally required.

noisgate-verify.py

PYTHONREAD-ONLYSAFE

#!/usr/bin/env python3\n# Check Google Chrome version for CVE-2026-11211\n# Outputs: VULNERABLE / PATCHED / UNKNOWN\n# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN\n\nimport os\nimport platform\nimport re\nimport shutil\nimport subprocess\nimport sys\n\nTHRESHOLD = (149, 0, 7827, 53)\n\ndef parse_version(text):\n    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text or '')\n    if not m:\n        return None\n    return tuple(int(x) for x in m.groups())\n\ndef fmt(v):\n    return '.'.join(str(x) for x in v) if v else 'unknown'\n\ndef run_version(cmd):\n    try:\n        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, text=True, timeout=10)\n        out = (p.stdout or '').strip()\n        return parse_version(out), out\n    except Exception:\n        return None, ''\n\ndef candidate_commands():\n    cmds = []\n    system = platform.system().lower()\n\n    if system == 'windows':\n        local = os.environ.get('LOCALAPPDATA', '')\n        pf = os.environ.get('PROGRAMFILES', '')\n        pfx86 = os.environ.get('PROGRAMFILES(X86)', '')\n        paths = [\n            os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),\n            os.path.join(pf, 'Google', 'Chrome', 'Application', 'chrome.exe'),\n            os.path.join(pfx86, 'Google', 'Chrome', 'Application', 'chrome.exe'),\n        ]\n        for p in paths:\n            if p and os.path.exists(p):\n                cmds.append(([p, '--version'], p))\n    elif system == 'darwin':\n        mac_paths = [\n            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',\n            os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),\n        ]\n        for p in mac_paths:\n            if os.path.exists(p):\n                cmds.append(([p, '--version'], p))\n        for name in ['google-chrome', 'chrome', 'chromium', 'chromium-browser']:\n            exe = shutil.which(name)\n            if exe:\n                cmds.append(([exe, '--version'], exe))\n    else:\n        for name in ['google-chrome-stable', 'google-chrome', 'chrome', 'chromium', 'chromium-browser']:\n            exe = shutil.which(name)\n            if exe:\n                cmds.append(([exe, '--version'], exe))\n        extra = [\n            '/opt/google/chrome/chrome',\n            '/usr/bin/google-chrome',\n            '/usr/bin/google-chrome-stable',\n        ]\n        for p in extra:\n            if os.path.exists(p):\n                cmds.append(([p, '--version'], p))\n\n    seen = set()\n    unique = []\n    for cmd, label in cmds:\n        key = tuple(cmd)\n        if key not in seen:\n            seen.add(key)\n            unique.append((cmd, label))\n    return unique\n\ndef main():\n    if '--version' in sys.argv:\n        try:\n            idx = sys.argv.index('--version')\n            user_ver = parse_version(sys.argv[idx + 1])\n        except Exception:\n            print('UNKNOWN: invalid --version argument')\n            sys.exit(2)\n        if not user_ver:\n            print('UNKNOWN: could not parse supplied version')\n            sys.exit(2)\n        if user_ver < THRESHOLD:\n            print(f'VULNERABLE: supplied version {fmt(user_ver)} is earlier than {fmt(THRESHOLD)}')\n            sys.exit(1)\n        print(f'PATCHED: supplied version {fmt(user_ver)} is at or above {fmt(THRESHOLD)}')\n        sys.exit(0)\n\n    findings = []\n    for cmd, label in candidate_commands():\n        ver, raw = run_version(cmd)\n        if ver:\n            findings.append((label, ver, raw))\n\n    if not findings:\n        print('UNKNOWN: Google Chrome executable not found or version could not be determined')\n        sys.exit(2)\n\n    vulnerable = [(label, ver) for (label, ver, raw) in findings if ver < THRESHOLD]\n    patched = [(label, ver) for (label, ver, raw) in findings if ver >= THRESHOLD]\n\n    if vulnerable:\n        details = '; '.join([f'{label}={fmt(ver)}' for label, ver in vulnerable])\n        print(f'VULNERABLE: {details}; fixed threshold is {fmt(THRESHOLD)}')\n        sys.exit(1)\n\n    details = '; '.join([f'{label}={fmt(ver)}' for label, ver in patched])\n    print(f'PATCHED: {details}; threshold is {fmt(THRESHOLD)}')\n    sys.exit(0)\n\nif __name__ == '__main__':\n    main()\n

07 · Bottom Line

If you remember one thing.

TL;DR

Monday morning, treat this as routine browser patching, not a fire drill: inventory endpoints still below 149.0.7827.53, verify Chrome auto-update is healthy, and clean up stragglers through your normal browser deployment ring. For a MEDIUM verdict there is noisgate mitigation SLA — go straight to the 365-day remediation window under the noisgate remediation SLA — but in a 10,000-host fleet you should still fold it into the next regular browser maintenance cycle rather than letting stale versions accumulate indefinitely.

Sources

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.