CVE-2026-10890 · Use after free in Cast in Google Chrome prior to 149.0.7827.53 allowed an attacker on the local network segment to potentially exploit heap

01 · The Real Story

This is a loaded nail gun left in the break room, not a sniper rifle on the public internet

CVE-2026-10890 is a use-after-free in Chrome's Cast path affecting Google Chrome versions before 149.0.7827.53. In plain English: if Chrome is reachable by a malicious Cast interaction from the same local network segment, memory can be reused after free and pushed into heap corruption, opening the door to browser-process compromise. The affected population is broad at the software level because Chrome is everywhere, but narrow at the exploitability level because the attacker must be adjacent on the network and the target has to be in a deployment where Cast/Media Router is usable and reachable.

paragraph 2: Google calling this HIGH 8.8 is fair in a laboratory sense because the bug is memory unsafe, unauthenticated, and can plausibly end in code execution. In enterprise reality, though, AV:A is the whole story: this is not internet-reachable, it usually implies the attacker already landed on the victim Wi-Fi/VLAN or a trusted adjacent segment, and many corporate builds either do not rely on Cast at all or can disable it centrally. That combination pushes this down to MEDIUM for fleet prioritization unless you have dense shared-network environments like classrooms, hot desks, guest Wi-Fi bridges, or unmanaged meeting-room casting.

"Technically ugly, operationally constrained: same-segment access and Cast reachability keep this out of the top patch tier."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Gain same-segment position with a Cast-capable lure

The attacker first needs adjacent network access to the victim: same Wi-Fi, same routed local segment, or another position able to exchange the traffic Cast discovery/control requires. In practice this is usually done with a custom Cast receiver emulator or LAN tooling such as scapy plus a small HTTP service to imitate the device and feed Chrome data it was willing to parse.

Conditions required:

Attacker is on the same local network segment or equivalently adjacent path
Target runs vulnerable Chrome prior to 149.0.7827.53
Cast or Media Router functionality is enabled and reachable enough to interact

Where this breaks in practice:

This is not internet scale; the attacker already needs local network adjacency
Many enterprise users never use Cast, reducing reachable population
Wireless client isolation, segmented meeting-room networks, or NAC can break this stage entirely

Detection/coverage: Traditional external attack-surface scanners will miss this. Coverage is mostly from EDR/network telemetry on unusual local discovery/control traffic and from enterprise config review confirming whether EnableMediaRouter is in use.

STEP 02

Trigger the Cast memory-lifecycle bug

Once Chrome interacts with the malicious Cast workflow, the attacker drives the use-after-free condition in the Cast component. A weaponized harness would combine Cast message shaping with heap grooming to turn a crash-class bug into controlled corruption inside the browser process.

Conditions required:

A vulnerable code path in Cast is actually reached on the target build
The attacker can supply protocol inputs Chrome will accept from the adjacent network

Where this breaks in practice:

Chrome memory corruption is harder to exploit than to crash because allocators, sandboxing, and exploit mitigations raise the bar
Public technical details are typically restricted early in Chrome releases, delaying broad weaponization

Detection/coverage: You may see browser crash spikes, ASan-like signatures in pre-release testing, or EDR events tied to abnormal child-process/browser instability. Commodity vuln scanners generally cannot prove exploitability here.

STEP 03

Convert corruption into browser-process execution

The next step is taking the heap corruption and landing code execution or equivalent control inside the Chrome process. This usually requires a mature exploit chain rather than a one-packet win, especially on fully patched operating systems with current exploit mitigations.

Conditions required:

Reliable heap shaping against the victim platform and Chrome build
No defensive crash-before-control behavior stopping the chain

Where this breaks in practice:

Reliability varies by OS, allocator state, and Chrome build
Modern browser hardening means many attempts become denial-of-service rather than stable code exec

Detection/coverage: EDR can sometimes catch the aftermath: browser exploitation telemetry, shellcode-like memory behavior, or suspicious child-process activity. Signature-only scanners have poor direct visibility.

STEP 04

Escape the browser sandbox for meaningful host impact

If the attacker wants host compromise rather than just browser-process control, they normally need a second bug or another post-exploitation path to break out of Chrome's sandbox. Without that chain, the blast radius is usually the user's browser context and whatever data/process capabilities that context can already reach.

Conditions required:

A follow-on sandbox escape or token/credential abuse path exists
The attacker can operate on the endpoint after browser compromise

Where this breaks in practice:

A standalone browser bug often stops short of full endpoint takeover
EDR, application control, and OS mitigations raise cost sharply at this stage

Detection/coverage: This is where defenders usually get their shot: EDR, behavioral detections, and identity telemetry are far better at spotting the post-browser phase than the initial Cast trigger.

03 · Intelligence Metadata

The supporting signals.

In-the-wild status	No public evidence of active exploitation found in the reviewed primary sources, and not KEV-listed.
Proof-of-concept availability	No public PoC located in reviewed primary sources. This fits Chrome's normal pattern of restricting bug details until enough users are patched.
EPSS	0.00007; effectively background-noise territory. That does not make the bug safe, but it does argue against emergency fleet-wide disruption.
KEV status	Absent from CISA KEV as reviewed; no KEV date applies.
CVSS vector	`CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` — the vendor score is driven by no auth/no click/high impact, but the adjacent-network requirement is a major real-world limiter.
Affected versions	Google Chrome prior to 149.0.7827.53. Operationally, prioritize any managed desktop/laptop cohorts that still expose Google Cast / Media Router.
Fixed versions	149.0.7827.53 is the stated floor from the CVE text; Google's early-stable desktop rollout also references 149.0.7827.53/.54 for Windows/macOS and 149.0.7827.53 in Beta.
Scanning / exposure reality	This is not meaningfully measurable with Shodan/Censys/FOFA because it is a client-side browser flaw, not a server banner problem. Exposure is really installed base × adjacent-network reachability × Cast enabled/useful.
Disclosure date	2026-06-04.
Reporting / attribution	Public release material reviewed does not yet attribute an external reporter. Treat that as unknown, not as evidence of low quality or low risk.

04 · The Call

noisgate verdict.

Final Verdict

↓ DOWNGRADED to MEDIUM (5.9/10)

The decisive factor is the attacker-position requirement: this bug needs adjacent local-network access, which usually means the adversary is already on the victim's Wi-Fi/VLAN or another trusted segment. That sharply cuts the reachable population versus true remote browser bugs and makes this a post-initial-access amplifier, not a first-wave internet threat.

HIGH Assessment that same-segment access is the primary downward pressure

MEDIUM Assessment of reachable enterprise population because Cast usage varies widely by environment

Why this verdict

Vendor 8.8 starts high, but AV:A is a tax — adjacent-network exploitation is materially less dangerous at fleet scale than unauthenticated internet-reachable RCE.
Requires prior position on the local network — that implies a previous compromise stage, rogue insider, unmanaged guest access, or weak segmentation before this CVE matters.
Reachable population is narrower than Chrome's install base — many enterprises can centrally disable Media Router/Cast or simply do not use it in normal office workflows.
No KEV and extremely low EPSS — there is no strong evidence that broad criminal weaponization is underway.
Blast radius is usually browser-context first — meaningful host takeover still likely needs a second step beyond the initial corruption.

Why not higher?

If this were remote over the internet or already actively exploited, the score would jump fast because Chrome is ubiquitous and memory corruption bugs age badly. But the chain is narrowed by same-segment access, likely dependence on Cast-reachable conditions, and the usual need to convert a browser memory bug into reliable execution and then possibly sandbox escape.

Why not lower?

This is still a memory corruption flaw in Chrome, not a harmless feature bug. In flat or semi-trusted networks like classrooms, hospitals, shared offices, labs, and conference spaces, one foothold can let an attacker hunt laterally across nearby endpoints without needing credentials or clicks.

05 · Compensating Control

What to do — in priority order.

Disable Media Router where unused — If your users do not need browser-based casting, set the Chrome Enterprise EnableMediaRouter policy to Disabled. For a MEDIUM verdict there is no mitigation SLA, so do this in the next normal change window; it shrinks the reachable population more effectively than any network signature.
Keep Cast receivers off user subnets — Move Chromecast and similar presentation devices to segmented AV/IoT VLANs with tightly controlled paths from managed endpoints. There is no mitigation SLA for MEDIUM here, but this is the right structural fix for adjacent-network abuse and should be scheduled as standard network hygiene.
Preserve client isolation on wireless and guest networks — Wireless client isolation, NAC, and restricted east-west paths directly attack the exploit's AV:A prerequisite. Roll this into normal network policy maintenance; the value is broader than this single CVE.
Watch for browser crash clusters and odd local discovery traffic — Because scanners will not see this well, rely on EDR crash telemetry, browser instability spikes, and unusual local discovery/control traffic around meeting-room and shared-network spaces. This is detection hardening, not a substitute for patching.

What doesn't work

A perimeter WAF does not help; the exploit path is not a web app on your edge.
Email filtering is mostly irrelevant; this is not a phishing-click-dependent browser bug in the provided description.
Internet ingress blocking misses the point because the attacker lives on the adjacent network, not the public internet.
Assuming Chrome sandboxing alone solves it is wrong; it may limit blast radius, but it does not prevent the initial browser-process compromise.

06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint itself or through your software-distribution/EDR script runner. Invoke with python3 check_chrome_cve_2026_10890.py on macOS/Linux or py -3 check_chrome_cve_2026_10890.py on Windows; no admin rights are required if Chrome is installed in standard locations, though registry access on Windows must be permitted.

noisgate-verify.py

PYTHONREAD-ONLYSAFE

#!/usr/bin/env python3\n# check_chrome_cve_2026_10890.py\n# Detects whether Google Chrome is below 149.0.7827.53\n# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN\n\nimport os\nimport platform\nimport re\nimport subprocess\nimport sys\n\nTHRESHOLD = (149, 0, 7827, 53)\n\ndef parse_ver(s):\n    if not s:\n        return None\n    m = re.search(r'(\\d+)\\.(\\d+)\\.(\\d+)\\.(\\d+)', s)\n    if not m:\n        return None\n    return tuple(int(x) for x in m.groups())\n\ndef cmp_ver(a, b):\n    return (a > b) - (a < b)\n\ndef run_cmd(cmd):\n    try:\n        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)\n        if p.returncode == 0:\n            return p.stdout.strip() or p.stderr.strip()\n    except Exception:\n        pass\n    return None\n\ndef detect_windows():\n    candidates = [\n        ["reg", "query", r"HKLM\\SOFTWARE\\Google\\Chrome\\BLBeacon", "/v", "version"],\n        ["reg", "query", r"HKLM\\SOFTWARE\\WOW6432Node\\Google\\Chrome\\BLBeacon", "/v", "version"],\n        ["reg", "query", r"HKCU\\SOFTWARE\\Google\\Chrome\\BLBeacon", "/v", "version"],\n    ]\n    for cmd in candidates:\n        out = run_cmd(cmd)\n        v = parse_ver(out)\n        if v:\n            return v, out\n    exe_paths = [\n        os.path.expandvars(r"%ProgramFiles%\\Google\\Chrome\\Application\\chrome.exe"),\n        os.path.expandvars(r"%ProgramFiles(x86)%\\Google\\Chrome\\Application\\chrome.exe"),\n        os.path.expandvars(r"%LocalAppData%\\Google\\Chrome\\Application\\chrome.exe"),\n    ]\n    for path in exe_paths:\n        if path and os.path.exists(path):\n            out = run_cmd([path, "--version"])\n            v = parse_ver(out)\n            if v:\n                return v, out\n    return None, None\n\ndef detect_macos():\n    plist = "/Applications/Google Chrome.app/Contents/Info.plist"\n    if os.path.exists(plist):\n        out = run_cmd(["/usr/bin/defaults", "read", plist.replace("/Contents/Info.plist", ""), "CFBundleShortVersionString"])\n        v = parse_ver(out)\n        if v:\n            return v, out\n    chrome = "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"\n    if os.path.exists(chrome):\n        out = run_cmd([chrome, "--version"])\n        v = parse_ver(out)\n        if v:\n            return v, out\n    return None, None\n\ndef detect_linux():\n    cmds = [\n        ["google-chrome", "--version"],\n        ["google-chrome-stable", "--version"],\n        ["chromium-browser", "--version"],\n        ["chromium", "--version"],\n    ]\n    for cmd in cmds:\n        out = run_cmd(cmd)\n        v = parse_ver(out)\n        if v:\n            return v, out\n    return None, None\n\ndef main():\n    system = platform.system().lower()\n    if "windows" in system:\n        version, raw = detect_windows()\n    elif "darwin" in system:\n        version, raw = detect_macos()\n    else:\n        version, raw = detect_linux()\n\n    if not version:\n        print("UNKNOWN: Google Chrome version not found")\n        sys.exit(2)\n\n    if cmp_ver(version, THRESHOLD) < 0:\n        print(f"VULNERABLE: detected Chrome {'.'.join(map(str, version))} < {'.'.join(map(str, THRESHOLD))}")\n        sys.exit(1)\n    else:\n        print(f"PATCHED: detected Chrome {'.'.join(map(str, version))} >= {'.'.join(map(str, THRESHOLD))}")\n        sys.exit(0)\n\nif __name__ == "__main__":\n    main()\n

07 · Bottom Line

If you remember one thing.

TL;DR

Monday morning, do not treat this like an emergency internet fire unless you run high-risk shared-network environments where Cast is common. For a MEDIUM noisgate rating there is no noisgate mitigation SLA — go straight to the 365-day remediation window; patch Chrome to 149.0.7827.53 or later within the noisgate remediation SLA of ≤365 days, and in the same normal change cycle disable Media Router on cohorts that do not need it and review network isolation around meeting-room / classroom / guest-wireless segments.

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.