01 · The Real Story
This is a burglar getting into the building lobby, not the vault
CVE-2026-11118 is a use-after-free bug in Chrome's WebRTC code path that affects Google Chrome versions prior to 149.0.7827.53. A victim has to browse to attacker-controlled content, which then triggers memory corruption through crafted HTML and reaches arbitrary code execution in the browser's sandboxed process rather than directly on the host OS.
The raw CVSS math pushes this toward HIGH because it is remote, low-complexity, and can end in code execution. In real enterprise terms, that overstates the outcome: the attacker still needs user interaction and only gets execution inside Chrome's renderer sandbox unless they also chain a sandbox escape or another privilege boundary break, which is the real missing piece here.
"Drive-by renderer RCE is real, but this bug lands inside Chrome's sandbox and stops short of full host compromise."
02 · The Attack Path
4 steps from start to impact.
STEP 01
Land the victim on attacker-controlled content
The attacker needs a user running a vulnerable Chrome build to open a crafted page that exercises the vulnerable WebRTC path. This is classic browser exploitation delivery: phishing, malvertising, compromised sites, or watering-hole content.
Conditions required:
- Target is running Chrome older than 149.0.7827.53
- Target can reach attacker-controlled web content
- User opens the page or embedded content
Where this breaks in practice:
- Requires user interaction; this is not a wormable network service
- Enterprise web filtering, Safe Browsing, email security, and URL isolation reduce reach
- Many Chrome fleets auto-update quickly, shrinking the exposed population
Detection/coverage: ASM scanners are a poor fit because this is client-side. Coverage comes from browser version inventory, EDR browser-child telemetry, URL filtering logs, and secure web gateway events.
STEP 02
Trigger the WebRTC use-after-free
Once the page loads, attacker JavaScript and media primitives attempt to drive WebRTC into the freed-object state and reuse memory in a controlled way. The weaponized tool is the browser engine itself; no separate malware dropper is required at this stage.
Conditions required:
- WebRTC functionality reachable in the victim browser session
- Exploit reliably shapes memory on the target platform/build
Where this breaks in practice:
- Browser memory corruption exploits are notoriously brittle across OS, patch level, architecture, and mitigations
- Restricted bug details and no public PoC materially slow commoditization
- Exploit reliability may vary by platform because the fixed release spans Linux 149.0.7827.53 and Windows/Mac 149.0.7827.53/54
Detection/coverage: Most vuln scanners will only flag version exposure. They will not prove exploitability; exploit detection is more likely through crash spikes, anomalous browser process behavior, or EDR memory-exploitation telemetry if present.
STEP 03
Gain code execution in the renderer sandbox
A successful exploit yields arbitrary code execution inside a sandboxed Chrome process. That matters for browser session theft, same-process data access, and staging, but it is still below full device compromise because Chromium deliberately treats the renderer as untrusted.
Conditions required:
- Exploit succeeds against the specific victim build
- Chrome sandbox is enabled and functioning normally
Where this breaks in practice:
- The sandbox is the decisive brake on impact
- Code execution remains constrained by broker policies, process isolation, and OS sandboxing rules
- Many enterprise claims of 'RCE' map to content-process execution, not immediate host takeover
Detection/coverage: EDR may see anomalous memory behavior in chrome.exe or crash/termination patterns, but many products will classify this generically as browser exploitation rather than identify CVE-2026-11118 specifically.
STEP 04
Attempt post-exploitation beyond the sandbox
To turn this into full endpoint compromise, the attacker usually needs a second bug such as a sandbox escape, kernel privilege escalation, or abused local trust boundary. Without that chain, the blast radius is mostly the browser security context and whatever secrets are reachable there.
Conditions required:
- Attacker has a viable follow-on escape or local privilege technique
- Defender controls do not block follow-on activity
Where this breaks in practice:
- This CVE alone does not provide the escape
- Modern EDR, application control, exploit protection, and sandbox hardening raise the cost sharply
- No public in-the-wild evidence currently shows this CVE being used in a working chain
Detection/coverage: Detection improves materially at this step: EDR, exploit guard, child-process policy violations, abnormal token use, and suspicious brokered file/process actions are the places to watch.
03 · Intelligence Metadata
The supporting signals.
| In-the-wild status | No confirmed exploitation evidence located, and not listed in CISA KEV as of 2026-06-06. That is meaningful downward pressure for a browser bug that would otherwise get attention fast if actively chained. |
|---|---|
| Proof-of-concept availability | No public PoC found during review. Chromium issue 501424047 exists but bug details are restricted, which slows copycat exploitation. |
| EPSS | EPSS supplied in the prompt is 0.00071, which is extremely low in absolute terms. I could not independently query this exact CVE value through the tool, but the official FIRST API format is documented here and supports per-CVE lookups. |
| KEV status | Not KEV-listed. For prioritization, that means no CISA-backed evidence of exploitation pressure right now; if it lands in KEV later, this rating should move up immediately. |
| CVSS vector reality check | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H captures a drive-by client bug, but the important omitted real-world detail is that the NVD text says execution is inside a sandbox. |
| Affected versions | Affected: Google Chrome prior to 149.0.7827.53. The Chrome desktop stable advisory says the fixed train is 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and Mac. |
| Vendor severity mismatch | There is a noteworthy split: the Chrome/NVD description says "Chromium security severity: Medium", while the user-supplied CVSS baseline is 8.8 HIGH from the ADP vector. Practically, the sandbox-limited outcome is why I side closer to Medium. |
| Scanning/exposure data | This is a client-side browser vulnerability, so Shodan/Censys/FOFA-style internet census is largely the wrong lens. Exposure has to be measured from endpoint/browser inventory, not external attack-surface scans; GreyNoise-style scan telemetry is also unlikely to be decisive unless exploitation becomes noisy at scale. |
| Disclosure date | Published/disclosed 2026-06-04 in NVD, with the Chrome stable desktop update posted 2026-06-02. |
| Reporter | The public Chrome release entry shows Reported by Google on 2026-04-10 for CVE-2026-11118; no external researcher attribution is exposed in the public advisory. |
04 · The Call
noisgate verdict.
Final Verdict
↓ DOWNGRADED to MEDIUM (6.1/10)
The single most important severity brake is that successful exploitation yields code execution inside Chrome's sandbox, not immediate host-level compromise. That sharply narrows blast radius unless the attacker already has, or can reliably chain, a second vulnerability to escape the renderer boundary.
HIGH Version scope and fixed build identification
MEDIUM Real-world exploitability estimate without public bug details or PoC
Why this verdict
- Downgrade for sandbox containment: the advisory text explicitly says arbitrary code execution occurs *inside a sandbox*, which is a major reduction from full endpoint RCE.
- Downgrade for attacker chain length: turning renderer code execution into durable host compromise usually requires a second bug such as a sandbox escape or local privilege escalation.
- Downgrade for delivery friction: this is
UI:R; the attacker needs a victim to open malicious content, so this is not wormable and not a blind network-service hit. - Downgrade for current threat signal: no KEV listing, no confirmed in-the-wild exploitation, and a very low EPSS value argue against panic patching.
- Hold at Medium because browser reach is huge: Chrome is everywhere, and drive-by memory corruption in a default browser still matters even when contained.
Why not higher?
I am not keeping this at HIGH because the advertised impact overreads what defenders usually mean by "remote code execution." This bug gives the attacker a foothold in a sandboxed browser process, and the missing sandbox-escape stage is not a footnote; it is the difference between session-level abuse and full device compromise.
Why not lower?
I am not dropping this to LOW because a remotely delivered browser memory corruption bug in a ubiquitous app is still operationally relevant. If a user hits a malicious page on a stale build, exploitation can hand an attacker meaningful execution and access within the browser context, which is enough for credential/session abuse and chain-building.
05 · Compensating Control
What to do — in priority order.
- Enforce Chrome auto-update compliance — Use endpoint management to verify stable-channel uptake and hunt for pinned or broken update clients. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice stale browsers should be corrected in the next normal desktop patch cycle because browser drift is easy to fix.
- Block risky browsing paths — Tighten secure web gateway, DNS filtering, Safe Browsing enforcement, and phishing controls to reduce user exposure to attacker-controlled pages. This is a sensible temporary reduction step while vulnerable endpoints age out, even though there is no formal noisgate mitigation deadline for MEDIUM issues.
- Prefer remote browser isolation for high-risk users — Place administrators, finance, executives, and heavily targeted users behind browser isolation or hardened browsing profiles where available. This lowers the chance that a single renderer exploit reaches sensitive sessions while remediation rolls through the fleet.
- Monitor browser exploit telemetry — Watch EDR, Windows Eventing, macOS Unified Logs, crash analytics, and proxy logs for abnormal browser crashes, suspicious renderer behavior, and exploit-prevention events. For MEDIUM issues this is a verification-and-detection measure rather than an emergency containment mandate.
What doesn't work
- Network perimeter scanning does not help much because this is not an exposed server-side service; you need endpoint version inventory.
- MFA alone does not stop exploitation of a renderer memory corruption bug; it only reduces some downstream account-abuse paths.
- WAF rules are mostly irrelevant because the malicious content is delivered to a browser, not to your web application for server-side parsing.
06 · Verification
Crowdsourced verification payload.
Run this on the target host or through your software inventory agent. Invoke it with python3 chrome_cve_2026_11118_check.py on Windows, macOS, or Linux; no administrator rights are required for standard install locations, but elevated rights may improve detection of machine-wide installs.
#!/usr/bin/env python3\n# chrome_cve_2026_11118_check.py\n# Checks whether Google Chrome is vulnerable to CVE-2026-11118 based on version.\n# Output: VULNERABLE / PATCHED / UNKNOWN\n# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN\n\nimport os\nimport platform\nimport re\nimport subprocess\nimport sys\nfrom shutil import which\n\nPATCHED = (149, 0, 7827, 53)\n\ndef parse_version(text):\n if not text:\n return None\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 run_cmd(cmd):\n try:\n p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)\n out = (p.stdout or '') + '\\n' + (p.stderr or '')\n return out.strip()\n except Exception:\n return ''\n\ndef find_chrome_version_windows():\n candidates = []\n for env in ('PROGRAMFILES', 'PROGRAMFILES(X86)', 'LOCALAPPDATA'):\n base = os.environ.get(env)\n if base:\n candidates.append(os.path.join(base, 'Google', 'Chrome', 'Application', 'chrome.exe'))\n for path in candidates:\n if os.path.exists(path):\n out = run_cmd(['powershell', '-NoProfile', '-Command', f\"(Get-Item '{path}').VersionInfo.ProductVersion\"])\n ver = parse_version(out)\n if ver:\n return ver, path\n out = run_cmd(['reg', 'query', r'HKCU\\Software\\Google\\Chrome\\BLBeacon', '/v', 'version'])\n ver = parse_version(out)\n if ver:\n return ver, 'HKCU BLBeacon'\n out = run_cmd(['reg', 'query', r'HKLM\\Software\\Google\\Chrome\\BLBeacon', '/v', 'version'])\n ver = parse_version(out)\n if ver:\n return ver, 'HKLM BLBeacon'\n return None, None\n\ndef find_chrome_version_macos():\n path = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'\n if os.path.exists(path):\n out = run_cmd([path, '--version'])\n ver = parse_version(out)\n if ver:\n return ver, path\n mdfind = which('mdfind')\n if mdfind:\n results = run_cmd([mdfind, 'kMDItemCFBundleIdentifier == "com.google.Chrome"'])\n for app in [x.strip() for x in results.splitlines() if x.strip()]:\n binpath = os.path.join(app, 'Contents', 'MacOS', 'Google Chrome')\n if os.path.exists(binpath):\n out = run_cmd([binpath, '--version'])\n ver = parse_version(out)\n if ver:\n return ver, binpath\n return None, None\n\ndef find_chrome_version_linux():\n bins = ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']\n for b in bins:\n exe = which(b)\n if exe:\n out = run_cmd([exe, '--version'])\n ver = parse_version(out)\n if ver:\n return ver, exe\n return None, None\n\ndef compare_versions(a, b):\n return (a > b) - (a < b)\n\ndef main():\n system = platform.system().lower()\n if 'windows' in system:\n version, source = find_chrome_version_windows()\n elif 'darwin' in system or 'mac' in system:\n version, source = find_chrome_version_macos()\n else:\n version, source = find_chrome_version_linux()\n\n if not version:\n print('UNKNOWN: Google Chrome version not found')\n sys.exit(2)\n\n if compare_versions(version, PATCHED) < 0:\n print(f'VULNERABLE: detected {".".join(map(str, version))} from {source}; fixed is >= {".".join(map(str, PATCHED))}')\n sys.exit(1)\n else:\n print(f'PATCHED: detected {".".join(map(str, version))} from {source}; fixed is >= {".".join(map(str, PATCHED))}')\n sys.exit(0)\n\nif __name__ == '__main__':\n main()07 · Bottom Line
If you remember one thing.
TL;DR
Monday morning, treat this as a Medium browser-fleet hygiene issue, not an all-hands host-compromise emergency. Validate Chrome auto-update health, identify endpoints still below 149.0.7827.53, and clean up broken/pinned update channels; there is noisgate mitigation SLA for this bucket — no mitigation SLA — go straight to the 365-day remediation window — and the noisgate remediation SLA is ≤365 days, though any enterprise with functioning browser management should realistically clear stale versions in the next routine desktop patch cycle rather than letting this sit.
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.