CVE-2026-11279 · Out of bounds read in DevTools in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to execute arbitrary code inside a sandbox

01 · The Real Story

This is a burglar getting into the apartment lobby, not the penthouse

CVE-2026-11279 is an out-of-bounds read in Chrome DevTools that affects Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. The vendor description says a remote attacker can use a crafted HTML page to achieve arbitrary code execution, but the code execution is inside Chrome's sandbox, not on the host OS.

The vendor's HIGH/8.8 baseline is technically defensible if you score raw browser exploitability, but it overstates enterprise urgency when judged as a standalone bug. The biggest real-world friction is that this is sandboxed code execution with user interaction required; without a second vulnerability for sandbox escape, credential theft, or same-user abuse, the blast radius is materially narrower than a full browser-to-host compromise.

"Remote code exec that stays inside Chrome’s sandbox is patch-worthy, not all-hands emergency"

02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a one-click exploit page

The attacker hosts a crafted HTML page and lures the target into opening it in Chrome. The practical weaponized tool here is just an exploit page delivered through phishing, malvertising, or a compromised site; no public Metasploit-style module or named PoC was found.

Conditions required:

Victim uses affected Chrome version prior to 149.0.7827.53
Victim visits attacker-controlled or attacker-influenced content
DevTools-relevant code path is reachable during page handling

Where this breaks in practice:

Requires user interaction (UI:R), so this is not wormable
Enterprise web filtering, Safe Browsing, mail filtering, and browser isolation reduce click-through success
No public exploit kit or mature public PoC located

Detection/coverage: Detection is mostly indirect: web proxy logs, phishing telemetry, and browser crash spikes. Vulnerability scanners will usually detect this only by Chrome version, not exploit attempts.

STEP 02

Trigger the DevTools memory bug

When the crafted page hits the vulnerable DevTools path, the out-of-bounds read can be turned into code execution in the browser security context. In practice, this is memory-corruption exploitation, so reliability depends on build, allocator state, and exploit engineering quality.

Conditions required:

Precise trigger exists for the target build/channel
Attacker can shape memory layout enough to make the bug useful

Where this breaks in practice:

Memory-corruption exploits are brittle across versions and mitigations
Chrome hardening features raise exploit-development cost
Bug details may remain restricted until patch adoption is broad

Detection/coverage: EDR rarely sees the initial bug directly; browser crash telemetry and abnormal renderer behavior are better indicators than signatures.

STEP 03

Land code inside the Chrome sandbox

Successful exploitation yields arbitrary code execution, but only inside Chrome's sandboxed process boundary. That matters: the attacker has code running in the browser, not free reign on the endpoint.

Conditions required:

Exploit succeeds against the target browser build
Sandbox is intact but still permits attacker objectives such as in-browser actions

Where this breaks in practice:

Sandbox containment sharply limits host impact from the standalone CVE
A separate sandbox escape or high-value in-browser objective is needed for major enterprise damage

Detection/coverage: EDR may miss this if nothing leaves the sandbox. Browser isolation products and behavior-based telemetry can sometimes catch follow-on abuse.

STEP 04

Chain for meaningful endpoint impact

To turn this into an endpoint compromise, the attacker usually needs a second bug or a same-user objective such as session abuse, browser-stored data theft, or extension interaction. That is where real campaigns become dangerous, but that risk comes from the chain, not this CVE by itself.

Conditions required:

Second vulnerability, weak browser posture, or valuable browser-resident data
Attacker has a post-exploitation objective worth sandboxed foothold effort

Where this breaks in practice:

No evidence in the supplied intel that this CVE is being chained in the wild
No KEV listing and very low EPSS reduce urgency versus true browser escape chains

Detection/coverage: Look for chained signals: suspicious child processes, token theft behavior, extension abuse, and anomalous outbound sessions after browser crashes.

03 · Intelligence Metadata

The supporting signals.

In-the-wild status	No public evidence of active exploitation found in the supplied intel, and not listed in CISA KEV.
Proof-of-concept availability	No named public PoC repo, exploit module, or public researcher write-up was located during review.
EPSS	`0.0008` from the supplied intel, which implies very low short-term exploitation probability relative to the wider CVE corpus.
KEV status	Not KEV-listed as of review; no CISA due date applies.
CVSS vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H` — remote and easy to trigger once a user visits content, but `UI:R` and sandbox-only impact are the key real-world brakes.
Affected versions	Google Chrome before `149.0.7827.53` on Linux and before `149.0.7827.53/54` on Windows and macOS, per Chrome release/advisory material.
Fixed versions	Patch floor is `149.0.7827.53` for Linux and `149.0.7827.53/54` for Windows/macOS. Chromium-based downstreams may pick this up on their own cadence.
Exposure reality	This is a client-side browser bug, so Shodan/Censys/FOFA-style internet scanning is largely irrelevant. Exposure lives in endpoint inventory, unmanaged browsers, and lagging auto-update cohorts.
Disclosure date	`2026-06-05` from the supplied intel; Chrome 149 early stable rollout appeared at the end of May 2026, with broader desktop release references on June 2-3, 2026.
Researcher / reporting	Specific reporter attribution for `CVE-2026-11279` was not confirmed from an authoritative bug entry during review; Chrome often withholds details until patch uptake improves.

04 · The Call

noisgate verdict.

Final Verdict

↓ DOWNGRADED to MEDIUM (6.5/10)

The decisive factor is sandbox containment: the bug yields code execution in Chrome, but not a demonstrated host-level compromise by itself. That keeps this below true emergency browser flaws unless you have separate evidence of active chaining or targeted exploitation.

HIGH Affected version range and fixed version floor

MEDIUM Real-world exploitability as a standalone enterprise risk

Why this verdict

Baseline starts at vendor 8.8, then drops for sandbox-only impact: arbitrary code execution is serious, but the described impact stops inside Chrome's sandbox rather than delivering direct OS compromise.
UI:R is real friction: this needs the user to reach attacker-controlled content, which implies phishing, malvertising, or a compromised site rather than unauthenticated server-side reachability.
No exploit heat: no KEV listing, no active exploitation evidence in the supplied intel, and a very low EPSS (0.0008) all push this down from emergency status.

Why not higher?

If this were a sandbox escape, a fully unsandboxed browser RCE, or already showing up in KEV or active campaigns, it would jump to HIGH or CRITICAL fast. As written, the attack still needs user interaction and additional chaining to produce the kind of endpoint impact that justifies top-tier urgency.

Why not lower?

It is still a remotely triggerable browser memory-corruption bug in one of the most widely deployed enterprise applications. Even sandboxed browser code execution can enable session theft, in-browser actions, or serve as the first half of a real exploit chain, so this is not backlog trivia.

05 · Compensating Control

What to do — in priority order.

Enforce Chrome auto-update health — Validate that enterprise policy, updater service, and egress controls are not blocking browser updates. For a MEDIUM verdict there is no mitigation SLA, but you should verify update drift now and complete version correction inside the <=365 days remediation window.
Push high-risk users through browser isolation or stronger web filtering — Security teams should prioritize admins, finance, execs, and exposed users whose threat model includes targeted phishing and drive-by content. There is no noisgate mitigation SLA for MEDIUM, so use this as risk reduction where patch lag exists rather than as a formal emergency control.
Block unmanaged Chromium builds — The real fleet risk is not managed Chrome that auto-updates; it is stale side-loaded or unmanaged Chromium-family browsers that miss the vendor patch cadence. Inventory and remove those during the normal remediation cycle and definitely before the <=365 days remediation deadline.

What doesn't work

Perimeter vulnerability scanning does not help much because this is a client-side browser bug, not an exposed server daemon.
MFA does not stop the exploit path; it may reduce downstream account abuse, but it does nothing to prevent the browser memory corruption itself.
Traditional network IDS signatures are weak here because exploitation is likely embedded in normal-looking web content rather than a stable server-side request pattern.

06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint through your normal remote-exec tooling, or locally from an auditor workstation session on the host. Invoke it with python3 check_cve_2026_11279.py; no admin rights are usually needed, though some system install paths on Windows may be easier to inspect with standard user read access.

noisgate-verify.py

PYTHONREAD-ONLYSAFE

#!/usr/bin/env python3\n# check_cve_2026_11279.py\n# Exit codes:\n#   0 = PATCHED\n#   1 = VULNERABLE\n#   2 = UNKNOWN\n\nimport os\nimport platform\nimport re\nimport subprocess\nimport sys\nfrom pathlib import Path\n\nTHRESHOLD = (149, 0, 7827, 53)\n\ndef parse_version(text):\n    m = re.search(r'(\\d+)\\.(\\d+)\\.(\\d+)\\.(\\d+)', text)\n    if not m:\n        return None\n    return tuple(int(x) for x in m.groups())\n\ndef cmp_ver(a, b):\n    return (a > b) - (a < b)\n\ndef try_cmd(cmd):\n    try:\n        p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)\n        out = (p.stdout or '') + ' ' + (p.stderr or '')\n        return parse_version(out), out.strip()\n    except Exception:\n        return None, ''\n\ndef windows_candidates():\n    paths = []\n    for base in filter(None, [os.environ.get('ProgramFiles'), os.environ.get('ProgramFiles(x86)'), os.environ.get('LOCALAPPDATA')]):\n        paths.extend([\n            Path(base) / 'Google/Chrome/Application/chrome.exe',\n            Path(base) / 'Chromium/Application/chrome.exe',\n        ])\n    return [p for p in paths if p.exists()]\n\ndef mac_candidates():\n    return [p for p in [\n        Path('/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),\n        Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome',\n        Path('/Applications/Chromium.app/Contents/MacOS/Chromium'),\n    ] if p.exists()]\n\ndef linux_candidates():\n    bins = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']\n    found = []\n    for b in bins:\n        v, _ = try_cmd([b, '--version'])\n        if v:\n            found.append(b)\n    return found\n\ndef main():\n    system = platform.system().lower()\n    version = None\n    source = None\n\n    if 'windows' in system:\n        for exe in windows_candidates():\n            v, out = try_cmd([str(exe), '--version'])\n            if v:\n                version = v\n                source = str(exe)\n                break\n    elif 'darwin' in system:\n        for exe in mac_candidates():\n            v, out = try_cmd([str(exe), '--version'])\n            if v:\n                version = v\n                source = str(exe)\n                break\n    else:\n        for cmd in linux_candidates():\n            v, out = try_cmd([cmd, '--version'])\n            if v:\n                version = v\n                source = cmd\n                break\n\n    if not version:\n        print('UNKNOWN: Chrome/Chromium binary not found or version unreadable')\n        sys.exit(2)\n\n    print(f'DETECTED_VERSION: {".".join(map(str, version))}')\n    print(f'SOURCE: {source}')\n\n    if cmp_ver(version, THRESHOLD) < 0:\n        print('VULNERABLE')\n        sys.exit(1)\n    else:\n        print('PATCHED')\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 a routine-but-real browser patch: pull endpoint inventory for Chrome and Chromium-derived browsers, verify auto-update health, and find any stragglers below 149.0.7827.53/149.0.7827.54. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window — but because this is a browser RCE primitive, you should still validate update drift this week and clean up unmanaged or stale installs well before the noisgate remediation SLA of <=365 days.

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.