This is a booby-trapped video, not a worm ripping through your estate
CVE-2026-11198 is an input-validation flaw in Chrome's Codecs component that affects Chrome builds prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on Windows and macOS. The public description says a remote attacker could *potentially* achieve a sandbox escape through a crafted video file, which makes this a client-side content-parsing issue rather than an always-reachable service flaw.
The supplied CRITICAL 9.6 label overstates operational risk for most enterprises. In the real world this requires a user to render attacker-controlled media, hits one endpoint at a time, has no KEV listing, no public exploit chain, a very low supplied EPSS, and even Chrome's own CNA text marks it as Chromium security severity: Medium.
4 steps from start to impact.
Deliver a crafted video payload
- Target uses Chrome below
149.0.7827.53/.54 - Target renders attacker-controlled video content in Chrome
- Attacker can reach the user through the web, chat, or email
- Requires user interaction (
UI:R), so this is not self-propagating - Email filtering, Safe Browsing, URL filtering, and user habits cut delivery volume
- Many enterprise users are already on auto-updating browser channels
Trigger the codec parser flaw
Codecs. This is where a proof-of-concept would need tight format control and version specificity to turn a parsing weakness into reliable exploitation.- Exact vulnerable build is present
- The malicious media exercises the affected codec path
- Chrome parses the content rather than blocking or failing early
- No public PoC was found
- Codec bugs are often format- and platform-sensitive
- Crash-to-code-exec reliability is usually much lower than CVSS implies
Cross the sandbox boundary
- The vulnerability is actually reachable to a privileged boundary crossing
- Exploit survives modern Chrome mitigations and OS hardening
- Attacker has a working post-trigger chain, not just a crash
- This is the highest-friction stage in the chain
- Chrome's own advisory categorizes this CVE as
Medium, which is a strong downward signal - No in-the-wild evidence was found
Operate on the compromised endpoint
- Successful sandbox escape
- Useful post-exploitation payload
- Insufficient EDR or application control on the endpoint
- EDR, ASR, application control, and egress controls often break post-exploitation
- Impact is bounded to the targeted user/device unless chained further
- No evidence this CVE currently supports broad opportunistic campaigns
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found, and not listed in CISA KEV as of 2026-06-06. |
|---|---|
| PoC availability | No public GitHub or researcher PoC located for CVE-2026-11198; bug details remain restricted in Chromium issue 504395300. |
| EPSS | Supplied EPSS is 0.0009 (~0.09%), which is very low and consistent with weak near-term exploitation pressure. |
| KEV status | No KEV listing found; no date added or federal due date applies. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H describes a severe client-side outcome on paper, but UI:R means the attack still depends on tricking users into rendering attacker content. |
| Affected versions | Chrome before 149.0.7827.53 per the CVE record; Google's stable release notes map that to 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows/macOS. |
| Fixed versions | Fixed in Chrome 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/macOS. Early stable for Windows/macOS began on 2026-05-29; broad stable promotion followed on 2026-06-02. |
| Disclosure timeline | CVE record published 2026-06-04; Chrome stable desktop release containing the fix was posted 2026-06-02. |
| Reporter / advisory severity | Chrome's stable advisory says Google reported it on 2026-04-20, and the CNA text exposed via Vulnerability-Lookup labels it Chromium security severity: Medium. |
| Exposure reality | Internet scanner data like Shodan/Censys is not very meaningful here because this is a desktop browser client bug, not a remotely discoverable service. Exposure should be measured from fleet inventory, and Chrome's huge install base still matters: StatCounter shows Chrome around 68% worldwide browser share. |
noisgate verdict.
The single decisive factor is chain friction at the sandbox-escape stage combined with required user interaction. This is a broad client population, but there is no exploitation evidence, no public PoC, and the impact lands one workstation at a time rather than exposing a server-side estate-wide entry point.
Why this verdict
- Down from 9.6 because
UI:Ris real friction — the attacker needs a user to open or render malicious media, which pushes this out of wormable/server-exposed territory and into phishing or web-lure tradecraft. - Down again because the hardest step is the one that matters — turning a codec parsing bug into a reliable *sandbox escape* is materially harder than crashing a browser process, and there is no public chain showing that reliability.
- Down again because exploitation pressure is weak — no KEV entry, no public PoC found, and the supplied EPSS is only
0.0009. - Not lower because Chrome is everywhere — Chrome has enormous enterprise reach, so even a client-side bug with friction can still matter if your patch hygiene is poor.
- Not lower because the stated outcome is serious if achieved — a successful sandbox escape on a user workstation is a meaningful endpoint compromise, just not the same operational class as an unauthenticated internet-facing server RCE.
Why not higher?
There is no evidence this is being exploited in the wild, no public weaponization, and the chain requires user-driven content rendering. Most importantly, the vulnerability's scariest word is *potentially*: the public description does not demonstrate a mature, reliable exploit path through Chrome's sandbox protections.
Why not lower?
This still sits in a massively deployed browser, and the affected component processes untrusted content from the internet by design. If an exploit chain emerges, the path to endpoint compromise is straightforward enough that this cannot be treated as mere backlog hygiene.
What to do — in priority order.
- Verify browser auto-update health — Confirm managed Chrome update channels, version reporting, and stalled-updater exceptions across the fleet so vulnerable endpoints do not linger. For a
MEDIUMverdict there is no mitigation SLA — go straight to the 365-day remediation window, but this control should be validated in the next regular endpoint engineering cycle because browsers age badly. - Reduce risky content delivery — Tighten web filtering, attachment detonation, and download reputation checks for unsolicited media payloads and newly registered lure domains. There is no mitigation SLA for
MEDIUM, but use the normal remediation window to shrink exposure while patched browser versions propagate. - Harden endpoint post-exploitation controls — Ensure EDR prevention, application control, and browser child-process restrictions are enabled so a successful browser escape does not become durable host compromise. For
MEDIUM, fold this into standard hardening work rather than an emergency change. - Inventory vulnerable versions — Use endpoint management, software inventory, or the verification script below to identify Chrome builds older than
149.0.7827.53/.54. With no mitigation SLA forMEDIUM, the priority is clean scoping and steady patch closure inside the remediation window.
- A perimeter WAF does nothing useful here because the target is a browser client rendering attacker content, not your web app.
- Network vulnerability scanning is weak coverage for this class because it cannot reliably tell whether a user's browser process is parsing a vulnerable codec path.
- Relying on
users won't open weird filesis not a control; drive-by pages, embedded media, and ad traffic make that assumption brittle.
Crowdsourced verification payload.
Run this on the target endpoint or through your endpoint management tool. Invoke it as python3 chrome_cve_2026_11198_check.py on Linux/macOS or py chrome_cve_2026_11198_check.py on Windows; no admin rights are normally required, though broader path/registry visibility on locked-down systems may help.
#!/usr/bin/env python3
# CVE-2026-11198 Chrome version check
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 1=vulnerable, 0=patched, 2=unknown
import os
import platform
import re
import shutil
import subprocess
import sys
TARGET = (149, 0, 7827, 53)
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=5)
out = (p.stdout or '') + ' ' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def candidate_paths():
system = platform.system().lower()
paths = []
if system == 'windows':
local = os.environ.get('LOCALAPPDATA', '')
program_files = os.environ.get('ProgramFiles', '')
program_files_x86 = os.environ.get('ProgramFiles(x86)', '')
paths.extend([
os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(program_files, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(program_files_x86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
])
elif system == 'darwin':
paths.extend([
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
])
else:
for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:
p = shutil.which(name)
if p:
paths.append(p)
paths.extend([
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/opt/google/chrome/chrome',
'/usr/bin/chromium',
'/usr/bin/chromium-browser',
])
seen = []
for p in paths:
if p and p not in seen:
seen.append(p)
return seen
def get_windows_registry_version():
try:
import winreg
except Exception:
return None
keys = [
r'SOFTWARE\Google\Chrome\BLBeacon',
r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
]
hives = []
try:
hives.append(winreg.HKEY_CURRENT_USER)
hives.append(winreg.HKEY_LOCAL_MACHINE)
except Exception:
return None
for hive in hives:
for key in keys:
try:
with winreg.OpenKey(hive, key) as k:
value, _ = winreg.QueryValueEx(k, 'version')
ver = parse_version(str(value))
if ver:
return ver
except Exception:
continue
return None
def detect_versions():
found = []
if platform.system().lower() == 'windows':
reg_ver = get_windows_registry_version()
if reg_ver:
found.append(('registry', reg_ver))
for path in candidate_paths():
if not os.path.exists(path):
continue
out = run_cmd([path, '--version'])
ver = parse_version(out)
if ver:
found.append((path, ver))
return found
def main():
found = detect_versions()
if not found:
print('UNKNOWN: Google Chrome version could not be determined on this host')
sys.exit(2)
lowest = min(ver for _, ver in found)
details = ', '.join([f'{src}={".".join(map(str, ver))}' for src, ver in found])
if version_lt(lowest, TARGET):
print(f'VULNERABLE: found Chrome version(s) below 149.0.7827.53 ({details})')
sys.exit(1)
else:
print(f'PATCHED: found Chrome version(s) at or above 149.0.7827.53 ({details})')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
MEDIUM and there is no KEV or active exploitation signal, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; your noisgate remediation SLA is <= 365 days, though a sensible enterprise should close a browser client bug like this in the next regular endpoint/browser release cycle, not at day 364.Sources
- Chrome Releases - Stable Channel Update for Desktop
- Chrome Releases - Early Stable Update for Desktop
- Vulnerability-Lookup - CVE-2026-11198
- Chromium issue 504395300
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
- StatCounter browser market share worldwide
- Canadian Centre for Cyber Security advisory AV26-544
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.