This is a cracked windshield on every company car: one bad road can hit a lot of drivers, but most crashes still stop at the glass
CVE-2026-11124 is a client-side memory-corruption bug in Chrome's Skia rendering stack. The CNA record says an *integer overflow* can lead to heap corruption from a crafted HTML page in Google Chrome versions earlier than 149.0.7827.53; Google shipped the fix in the Chrome 149 stable release for Linux 149.0.7827.53 and Windows/macOS 149.0.7827.53/.54. There is a minor metadata mismatch worth noting: Google's release post labels the entry as *heap buffer overflow in Skia*, while the CVE text describes an *integer overflow* that can cause heap corruption.
Google's own severity label is *Medium*, and that is understandable if you score only the immediate bug and assume the browser sandbox holds. In enterprise reality, though, this lands higher: Chrome is everywhere, delivery is cheap for attackers because normal browsing is enough, and rendering bugs are exactly the class that turns malvertising or phishing clicks into initial footholds. The main downward pressures are real too: user interaction is required, there is no public in-the-wild exploitation in the sources reviewed, and the likely first-stage impact is renderer compromise rather than instant full-host takeover.
4 steps from start to impact.
Deliver a malicious page
- Victim uses Chrome earlier than
149.0.7827.53 - Victim loads attacker-controlled or attacker-influenced web content
- Network controls do not fully block the destination
- Requires user interaction or at least a browser navigation event
- Web filtering, Safe Browsing, DNS controls, and mail security can cut down delivery volume
- Attackers still need a trigger that reaches the vulnerable Skia code path reliably
Trigger the Skia overflow
- The affected Skia code path is reachable on the victim platform/build
- Heap layout and content shape line up for corruption
- The browser has not already been updated
- Renderer exploitation reliability varies by platform, allocator state, and hardening level
- Modern Chrome mitigations raise the bar from crash to code execution
- Metadata only says 'potentially exploit heap corruption,' not proven RCE
Gain execution in the renderer sandbox
- Successful memory-corruption exploitation rather than a simple crash
- Mitigations such as allocator hardening, CFG, and ASLR are bypassed or worked around
- The attacker can operate within the renderer's privileges
- Chrome sandboxing and site isolation materially reduce immediate blast radius
- Same-origin and broker boundaries still matter after renderer compromise
- A lot of real-world exploit attempts die here
Chain for higher impact
- Attacker already achieved renderer execution
- A second vulnerability or a usable post-exploitation path exists
- The victim session has valuable data or reachable enterprise apps
- Separate sandbox-escape bugs are uncommon and valuable
- EDR, application control, and browser isolation can break the follow-on stage
- Impact can stay confined to the browser session instead of the whole host
The supporting signals.
| In-the-wild status | No public exploitation evidence in the reviewed sources, and not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public PoC or exploit repository surfaced in the reviewed sources. The Chromium issue is still access-restricted, which is typical while adoption of the fix catches up. |
| EPSS | 0.00035 from the user-supplied intel; that is very low threat likelihood. Percentile was not present in the material reviewed. |
| KEV status | Not KEV-listed in the CISA Known Exploited Vulnerabilities Catalog. |
| Vendor severity | Chromium labels it Medium in the release advisory and CVE text. |
| CVSS / vector situation | There is no published vendor or authority CVSS for this CVE. *Inference only:* adjacent same-release Chrome memory-corruption CVEs on NVD commonly receive CISA-ADP 8.8 with CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, but that vector was not authoritatively published for CVE-2026-11124 in the sources reviewed. |
| Affected versions | Google Chrome earlier than 149.0.7827.53. The desktop stable announcement explicitly covers Windows, macOS, and Linux. |
| Fixed versions | Desktop stable fix landed in Linux 149.0.7827.53 and Windows/macOS 149.0.7827.53/.54. Chrome for Android 149.0.7827.59 states it includes the same desktop security fixes unless otherwise noted. |
| Scanning / exposure reality | Shodan/Censys-style internet exposure counts are not meaningful here because Chrome is endpoint software, not an internet-addressable edge service. Your exposure is your installed browser fleet, not your public IP space. |
| Disclosure / reporting | CVE published 2026-06-04; Google's release post shows it was reported by Google on 2026-04-10. |
noisgate verdict.
The decisive amplifier is reachability at scale: any attacker who can get a user to open a page can target a browser that exists on nearly every endpoint in the fleet. The decisive brake is that this is still a sandboxed, user-interaction-dependent browser bug with no public exploitation evidence, so it does not justify a critical emergency posture by itself.
Why this verdict
- Massively exposed client surface: Chrome is ubiquitous, and the attacker position is only *unauthenticated remote plus user browse event*. That means a wide reachable population across enterprise endpoints, not a niche admin-only feature.
- Low delivery cost, not low exploit cost: the attacker can deliver via ordinary web content, phishing, ads, or compromised sites, so perimeter controls do not eliminate the risk. I adjusted the score upward because the first hop does not require credentials, internal access, or special roles.
- Sandbox is real downward pressure: successful exploitation likely starts in the renderer, which implies constrained privileges and often requires a second bug for full-host compromise. I adjusted the score downward for that compounding friction.
- No active exploitation signal: EPSS is extremely low and the CVE is not in KEV. That removes the biggest reason to call this critical.
- Vendor medium is a bit too calm for fleet prioritization: for a 10,000-host enterprise, one-click browser memory corruption on a universal app deserves faster attention than a generic medium backlog item, even if the browser sandbox keeps it from being top-shelf emergency patching.
Why not higher?
There is no evidence in the reviewed sources that this is being exploited in the wild, and there is no public PoC raising the immediate copycat risk. More importantly, the likely first-stage win is inside Chrome's sandboxed renderer, not an automatic full endpoint takeover, so the blast radius is meaningfully constrained unless the attacker can chain another flaw.
Why not lower?
Scoring this as medium would underweight the real exposure population: browser rendering bugs are one of the cleanest ways to touch a huge endpoint fleet with almost no attacker-side prerequisites. Even with the sandbox, a remotely delivered memory-corruption bug in a universally deployed browser is too operationally important to treat as routine backlog hygiene.
What to do — in priority order.
- Enforce rapid Chrome auto-update — Make sure enterprise policy does not defer stable-channel browser updates longer than necessary, and verify endpoints are actually pulling
149.0.7827.53or later. For a HIGH verdict, get this enforced within 30 days where patching is lagging. - Block unmanaged or stale browser versions — Use MDM, EDR, NAC, or conditional access to identify and restrict endpoints still running older Chrome builds. This reduces the reachable population while the fleet converges, and for a HIGH verdict the control should be in place within 30 days.
- Harden web-content delivery paths — Tighten DNS filtering, secure web gateway policy, Safe Browsing enforcement, and ad/malware category blocking to cut off common delivery channels like phishing pages and malvertising. These are compensating controls, not fixes, and they should be tuned within 30 days.
- Prefer browser isolation for high-risk users — For administrators, finance, help desk, and users with broad SaaS access, route untrusted browsing through remote browser isolation if you have it. That meaningfully reduces exploit usefulness during the patch convergence period and should be prioritized within 30 days for exposed groups.
- A WAF does not help here because the vulnerable parser is the client's browser, not your server.
- MFA is good hygiene but does nothing to stop the initial memory-corruption trigger from a malicious page.
- Network vulnerability scanning alone is weak coverage because it can inventory version state on managed assets but cannot detect exploit attempts or prove renderer-path reachability.
Crowdsourced verification payload.
Run this on the target endpoint or through your software-distribution/EDR script runner. Invoke it with python3 chrome_cve_2026_11124_check.py on macOS/Linux or py chrome_cve_2026_11124_check.py on Windows; no admin rights are normally required, but elevated rights can help if Chrome is installed system-wide in nonstandard paths.
#!/usr/bin/env python3
# CVE-2026-11124 Chrome version check
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
from typing import Optional, Tuple
PATCH_VERSION = (149, 0, 7827, 53)
def parse_version(text: str) -> Optional[Tuple[int, int, int, int]]:
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def run_cmd(cmd):
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
out = (p.stdout or '') + '\n' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def find_windows_version() -> Optional[Tuple[int, int, int, int]]:
candidates = [
os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
]
powershell = shutil.which('powershell') or shutil.which('pwsh')
for path in candidates:
if os.path.exists(path) and powershell:
script = f"(Get-Item '{path}').VersionInfo.ProductVersion"
out = run_cmd([powershell, '-NoProfile', '-Command', script])
v = parse_version(out)
if v:
return v
return None
def find_macos_version() -> Optional[Tuple[int, int, int, int]]:
candidates = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for path in candidates:
if os.path.exists(path):
out = run_cmd([path, '--version'])
v = parse_version(out)
if v:
return v
return None
def find_linux_version() -> Optional[Tuple[int, int, int, int]]:
candidates = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
for exe in candidates:
path = shutil.which(exe)
if path:
out = run_cmd([path, '--version'])
v = parse_version(out)
if v:
return v
return None
def compare_versions(found: Tuple[int, int, int, int], fixed: Tuple[int, int, int, int]) -> int:
if found < fixed:
return -1
if found > fixed:
return 1
return 0
def main():
system = platform.system().lower()
version = None
if 'windows' in system:
version = find_windows_version()
elif 'darwin' in system or 'mac' in system:
version = find_macos_version()
elif 'linux' in system:
version = find_linux_version()
if not version:
print('UNKNOWN: Could not determine installed Chrome/Chromium version')
sys.exit(2)
cmp_result = compare_versions(version, PATCH_VERSION)
version_str = '.'.join(str(x) for x in version)
fixed_str = '.'.join(str(x) for x in PATCH_VERSION)
if cmp_result < 0:
print(f'VULNERABLE: Detected version {version_str} < fixed baseline {fixed_str}')
sys.exit(1)
else:
print(f'PATCHED: Detected version {version_str} >= fixed baseline {fixed_str}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, push the stable build through your browser rings immediately, and use policy controls to squeeze down unmanaged or stale versions within 30 days under the noisgate mitigation SLA; finish full remediation across the fleet within 180 days under the noisgate remediation SLA. If you already have fast browser update machinery, this should be in the next rollout wave, not left to normal medium-severity drift.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.