← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-10924 · CWE-472 · Disclosed 2026-06-04

Integer overflow in Chromecast in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Important only as a chain component: this needs prior renderer compromise before it matters"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land renderer code execution

The attacker first needs a separate bug that yields control of Chrome's renderer process, typically through malicious web content, a compromised ad path, or a browser exploit stager using custom JavaScript/WASM. This CVE does not provide that initial foothold; it only matters once the renderer is already hostile.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Traditional vuln scanners will miss this stage. Browser crash telemetry, EDR exploit detections, and suspicious chrome.exe child-process or memory-protection events are more useful than network scanning.
STEP 02

Reach the Chromecast code path

With renderer control, the attacker then drives the affected Chromecast/media-routing functionality and feeds crafted values into the vulnerable path. The likely weaponized mechanism is abuse of the Media Router / Cast plumbing exposed to the renderer-browser boundary.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Little scanner coverage. Useful signals are Chrome enterprise policy inventory, browser version inventory, and anomalous cast/media-router usage on endpoints where that feature is normally absent.
STEP 03

Trigger integer overflow for memory corruption

The attacker uses crafted integer values to force an overflow and turn that into controlled memory corruption. In a real exploit chain, this would be a purpose-built sandbox-escape payload rather than a commodity PoC.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Look for Chrome crash spikes, renderer/browser process restarts, and exploit-guard or EDR memory-corruption alerts. Signature-based detection is weak without a public PoC.
STEP 04

Cross the boundary and cash out

If the corruption is steered correctly, the attacker can likely escape the renderer's sandbox boundary and gain access to higher-privilege browser or host capabilities. That is the real risk: not initial access, but turning a tab compromise into a more meaningful endpoint compromise.
Conditions required:
  • The overflow yields a controllable primitive across the intended trust boundary
  • Post-exploitation payloads survive browser and endpoint defenses
Where this breaks in practice:
  • This is a chain-completion step, not a direct internet-reachable compromise
  • EDR, application control, and browser sandboxing still constrain follow-on actions
Detection/coverage: Best detected through EDR, browser crash forensics, and abnormal post-browser process activity. Network scanners provide essentially no coverage.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found and not listed in CISA KEV as of this assessment.
Proof-of-concept availabilityNo public PoC located for CVE-2026-10924. That usually means either restricted bug details or a still-nontrivial exploit path.
EPSS0.00068 — extremely low predicted exploitation probability, which matches the fact pattern for a second-stage browser chain component.
KEV statusNot KEV-listed. No override to emergency handling on that basis.
CVSS vectorCVSS: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 versionsVendor 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 versionsTreat 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 dataInternet 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 date2026-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 / reportingNot 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.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.2/10)

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.

HIGH Renderer-compromise prerequisite is the main downward driver
MEDIUM Affected-version and fixed-version interpretation from Google's `149.0.7827.53/.54` desktop release note
LOW Exact exploit outcome beyond 'boundary crossing after renderer compromise' because the public bug record is not visible

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: pull a version report for all managed Chrome endpoints, identify anything below 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

  1. Google Chrome Releases - Early Stable Update for Desktop (`149.0.7827.53/.54`)
  2. Google Chrome Releases index
  3. Chromium Security
  4. Chromium Security Quarterly Updates
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS
  7. Chrome Enterprise - View Chrome browser details
  8. Google Chrome Help - Fix Chrome update problems
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.