This is a second locked door inside an already-broken house, not the front door itself
CVE-2026-10924 is an integer overflow in Chrome's Chromecast/media-routing code. Based on the vendor wording you provided, affected builds are Chrome versions before 149.0.7827.53 (with Google's early stable desktop post listing 149.0.7827.53/.54 for Windows and Mac), and exploitation requires the attacker to have *already compromised the renderer process* first. In plain English: a malicious site alone is not enough; the attacker needs a separate renderer bug or equivalent foothold inside the sandboxed tab process before this flaw becomes reachable.
Google's HIGH 8.3 baseline makes sense in a pure browser-exploit-chain context because sandbox escapes are strategically valuable. But for enterprise patch triage, that score overstates the standalone urgency: this is *post-initial-compromise inside the browser*, not a one-bug remote takeover. No KEV listing, very low EPSS, no public exploit chain, and probable feature-path friction around Chromecast/media routing all push this down to MEDIUM for fleet scheduling.
4 steps from start to impact.
Land renderer code execution
- User visits attacker-controlled or compromised content
- A separate renderer-compromise vulnerability or equivalent sandboxed code-exec primitive exists
- Exploit mitigations on the endpoint do not stop the first-stage bug
- This prerequisite already assumes a successful browser exploit or similar compromise stage
- Modern Chrome hardening, site isolation, and endpoint exploit protection reduce first-stage reliability
- No public evidence ties this CVE to an in-the-wild first-stage chain
chrome.exe child-process or memory-protection events are more useful than network scanning.Reach the Chromecast code path
- Chromecast or related media-routing functionality is present and reachable in the target build
- The renderer compromise can invoke the relevant cast/media-routing path
- Many enterprise fleets rarely use casting features on managed desktops
- Some orgs disable or restrict media routing/casting through policy
- Feature reachability is narrower than a generic web-facing parsing bug
Trigger integer overflow for memory corruption
- Precise control over the vulnerable input values
- Build-specific exploit reliability despite ASLR, CFI, and allocator behavior
- Crash-only behavior can be upgraded to controlled corruption
- Integer-overflow-to-RCE chains are often version- and architecture-sensitive
- Chrome's exploit mitigations materially raise exploit-development cost
- No public PoC suggests the bug is non-trivial to weaponize
Cross the boundary and cash out
- The overflow yields a controllable primitive across the intended trust boundary
- Post-exploitation payloads survive browser and endpoint defenses
- This is a chain-completion step, not a direct internet-reachable compromise
- EDR, application control, and browser sandboxing still constrain follow-on actions
The supporting signals.
| In-the-wild status | No public exploitation evidence found and not listed in CISA KEV as of this assessment. |
|---|---|
| Proof-of-concept availability | No public PoC located for CVE-2026-10924. That usually means either restricted bug details or a still-nontrivial exploit path. |
| EPSS | 0.00068 — extremely low predicted exploitation probability, which matches the fact pattern for a second-stage browser chain component. |
| KEV status | Not KEV-listed. No override to emergency handling on that basis. |
| CVSS vector | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H — the *Scope: Changed* and high CIA impact reflect a boundary-crossing browser bug, but AC:H and the renderer-compromise prerequisite make the raw score too optimistic for patch scheduling. |
| Affected versions | Vendor intel says Chrome prior to 149.0.7827.53. Google's early stable desktop post shows patched desktop rollout at 149.0.7827.53/.54 for Windows and Mac. |
| Fixed versions | Treat 149.0.7827.53/.54 or later as fixed for the desktop builds referenced in Google's release post. Validate distro/vendor-repackaged browser channels separately if you do not use direct Google builds. |
| Scanning / exposure data | Internet exposure telemetry is not very meaningful here. This is a client-side, post-renderer-compromise flaw, so Shodan/Censys/FOFA-style external counts do not map well to risk; your real exposure metric is managed Chrome version lag across the endpoint fleet. |
| Disclosure date | 2026-06-04 from the intel block you supplied. I did not find a public NVD/MITRE record during this assessment, so date and metadata should be treated as vendor-supplied / prompt-supplied intel. |
| Researcher / reporting | Not publicly attributable from the sources I could verify. Chromium commonly restricts bug details until a majority of users are updated, and many fixed security bugs only become public later. |
noisgate verdict.
The decisive downgrade is the prerequisite: the attacker must already control the renderer process, which means this is a *chain component* rather than an initial-access browser bug. That sharply narrows the reachable population and pushes real-world risk below the vendor's generic browser-boundary score despite the potentially serious impact once chained.
Why this verdict
- -1.6 for prior compromise requirement: vendor CVSS treats this like broadly reachable web risk, but the attacker must first win a separate renderer compromise. That implies post-initial-access inside Chrome's sandbox, not a clean one-bug web takeover.
- -0.4 for exposure narrowing: the vulnerable path sits in Chromecast/media-routing functionality, which is less universally exercised than core rendering, JavaScript, or image parsing surfaces in enterprise browsing.
- -0.3 for exploit maturity: no KEV, no public PoC, and tiny EPSS all say the market has not turned this into a commodity chain component.
- +0.2 for blast-radius significance once chained: if an attacker already has renderer code execution, a successful second-stage browser escape can still materially raise impact on a high-value workstation.
Why not higher?
It is not higher because the key prerequisite already assumes a prior exploit success. Requiring renderer compromise plus likely feature-path reachability turns this into a selective, expensive chain component rather than a fleet-wide emergency on its own.
Why not lower?
It is not lower because Chrome is ubiquitous and browser sandbox escapes matter disproportionately on admin, developer, and executive endpoints. Even without public exploitation, a working chain can convert a contained tab-level compromise into something much more operationally damaging.
What to do — in priority order.
- Enforce Chrome auto-update — Make sure managed browsers are actually receiving Google updates and that version drift is visible in your browser-management console. For a MEDIUM verdict there is no mitigation SLA, so use this as risk reduction while driving toward the remediation window; in practice, Chrome should not sit unpatched for long because update friction is low.
- Restrict or disable media routing where unused — If your enterprise does not need casting, use Chrome enterprise policy to reduce exposure to the Chromecast/media-router path. This is a sensible compensating control for the affected feature set; for a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window while keeping unnecessary features off managed endpoints.
- Prioritize high-value endpoint tiers — Admin workstations, developer laptops, and browsing-heavy user populations are where a second-stage browser escape has the most payoff. Use asset criticality to clean up laggards first even though the formal noisgate bucket here is MEDIUM.
- Hunt for browser exploit signals — Monitor for Chrome crash bursts, exploit-guard alerts, suspicious browser child processes, and anomalous cast/media-router use. These controls do not patch the bug, but they are the most realistic way to catch a chained browser exploit attempt.
- Perimeter scanning doesn't help much because this is not an internet-facing service exposure problem.
- MFA doesn't materially reduce risk here; the attack path is through browser memory corruption, not account takeover.
- WAFs and email gateways only help *indirectly* by reducing delivery of first-stage content. They do nothing once a malicious page is already rendering inside Chrome.
Crowdsourced verification payload.
Run this on the target endpoint or through your software-distribution/remote-exec tooling. Invoke it with python3 check_chrome_cve_2026_10924.py on macOS/Linux or py check_chrome_cve_2026_10924.py on Windows; local user rights are usually enough, but registry/path access on locked-down Windows images may work more reliably with standard endpoint-management privileges.
#!/usr/bin/env python3
# Check local Google Chrome version against CVE-2026-10924 fixed build.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
FIXED = (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 cmp_ver(a, b):
return (a > b) - (a < b)
def run_cmd(cmd):
try:
out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True)
return out.strip()
except Exception:
return None
def get_windows_version():
commands = [
["reg", "query", r"HKCU\Software\Google\Chrome\BLBeacon", "/v", "version"],
["reg", "query", r"HKLM\Software\Google\Chrome\BLBeacon", "/v", "version"],
["reg", "query", r"HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon", "/v", "version"],
]
for cmd in commands:
out = run_cmd(cmd)
if out:
v = parse_version(out)
if v:
return v, "registry"
paths = [
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"),
]
for p in paths:
if p and os.path.exists(p):
out = run_cmd(["powershell", "-NoProfile", "-Command", f"(Get-Item '{p}').VersionInfo.ProductVersion"])
if out:
v = parse_version(out)
if v:
return v, p
return None, None
def get_macos_version():
app = "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
if os.path.exists(app):
out = run_cmd([app, "--version"])
if out:
v = parse_version(out)
if v:
return v, app
return None, None
def get_linux_version():
candidates = ["google-chrome", "google-chrome-stable", "/opt/google/chrome/chrome"]
for c in candidates:
out = run_cmd([c, "--version"]) if not c.startswith("/") else (run_cmd([c, "--version"]) if os.path.exists(c) else None)
if out:
v = parse_version(out)
if v:
return v, c
return None, None
def main():
system = platform.system().lower()
if "windows" in system:
version, source = get_windows_version()
elif "darwin" in system:
version, source = get_macos_version()
else:
version, source = get_linux_version()
if not version:
print("UNKNOWN - Google Chrome version not found")
sys.exit(2)
if cmp_ver(version, FIXED) >= 0:
print(f"PATCHED - Detected Google Chrome {'.'.join(map(str, version))} via {source}")
sys.exit(0)
else:
print(f"VULNERABLE - Detected Google Chrome {'.'.join(map(str, version))} via {source}; fixed is 149.0.7827.53+")
sys.exit(1)
if __name__ == "__main__":
main()
If you remember one thing.
149.0.7827.53/.54, and let browser auto-update clean up the bulk while you manually chase the laggards and policy-block unused casting features. For this MEDIUM reassessment there is noisgate mitigation SLA — go straight to the 365-day remediation window — but because Chrome is cheap to update and this bug is a plausible chain component, you should still close version drift well before the noisgate remediation SLA deadline of 365 days rather than treating it like ordinary backlog dust.Sources
- Google Chrome Releases - Early Stable Update for Desktop (`149.0.7827.53/.54`)
- Google Chrome Releases index
- Chromium Security
- Chromium Security Quarterly Updates
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS
- Chrome Enterprise - View Chrome browser details
- Google Chrome Help - Fix Chrome update problems
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.