CVE-2026-11241 · Insufficient validation of untrusted input in Cast in Google Chrome prior to 149.0.7827.53 allowed an attacker on the local network segment

01 · The Real Story

This is a booby-trapped conference-room TV, not an internet-facing edge appliance

CVE-2026-11241 is an input-validation flaw in Chrome's Cast handling. Affected builds are Chrome desktop versions before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS; the attacker has to be on the same local network segment and reach Cast discovery/communication paths with crafted local-network traffic.

Google's HIGH 8.0 baseline overstates enterprise urgency. In the real world this is *adjacent-network* plus *user-interaction* plus *feature-specific* exploitation, which means the attacker is already on the victim's Wi-Fi/L2 domain and the victim still has to exercise Cast-capable code; that is materially narrower than the browser bugs defenders usually drop everything for.

"Same-Wi-Fi, user-assisted Cast abuse is a real bug, but it is not an internet-scale Chrome fire drill."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Land on the victim's local segment

The attacker needs to share the victim's broadcast domain or a forwarded discovery segment where Cast traffic is visible. In practice that means guest Wi-Fi, conference-room networks, shared residential/hotel Wi-Fi, lab VLANs, or an already-compromised internal endpoint. Typical tooling is just normal network foothold tradecraft plus packet visibility; there is no need for prior Chrome authentication.

Conditions required:

Attacker is on the same local network segment, or on a segment where Cast discovery/traffic is bridged
Victim device can discover Cast peers over the local network

Where this breaks in practice:

Most enterprises segment guest/BYOD away from managed endpoints
mDNS/Bonjour forwarding is often disabled or tightly scoped
Conference-room and kiosk populations are much smaller than the full browser fleet

Detection/coverage: NAC, WLAN controller logs, and lateral-movement detections can often prove the attacker was already inside the local trust zone, but they will not identify this CVE specifically.

STEP 02

Present a malicious Cast target

The attacker advertises or impersonates Cast-relevant services and waits for Chrome to enumerate them. Commodity local-network tooling like avahi-publish-service, bettercap, or a bespoke mDNS/SSDP emulator is enough to weaponize discovery paths if the vulnerable parser/handler is reachable.

Conditions required:

Chrome Cast/local-device discovery is enabled and functioning
Attacker can emit crafted discovery or session traffic to the victim

Where this breaks in practice:

Many enterprise endpoints never use Cast at all
Some orgs disable Cast-related controls or block the required ports/protocols
Users must be in an environment where local casting actually works

Detection/coverage: Rogue-service discovery is hard to signature cleanly; network monitoring can flag unusual mDNS/SSDP volume or unexpected listeners on Cast-related ports, but scanner coverage is weak.

STEP 03

Trigger the vulnerable Cast code path

Because the supplied vector is UI:R, the victim still has to do something that causes Chrome to process the malicious Cast input—most plausibly opening Cast UI or otherwise interacting with a Cast-capable workflow. Once that happens, the crafted local-network data reaches the insufficient-validation bug in Cast.

Conditions required:

Victim interacts with a Cast workflow in Chrome
Vulnerable Chrome version is still installed

Where this breaks in practice:

User interaction cuts out broad drive-by exploitation
The bug is not reachable from the open internet
Browsers auto-update aggressively in many managed fleets

Detection/coverage: There is no dependable remote scanner for this step; detection is mostly version-based exposure management plus crash telemetry or browser diagnostics.

STEP 04

Use the privilege gain inside the browser trust boundary

If exploitation succeeds, the attacker gets a privilege increase associated with the vulnerable Chrome Cast component and can likely read or perform actions the original local-network input path should not have allowed. That can matter on shared networks, but the blast radius is still bounded to endpoints that are both vulnerable and actually exposed to Cast interactions.

Conditions required:

Exploit is reliable against the target build
Target browser session contains data worth stealing or actions worth taking

Where this breaks in practice:

No public exploitation evidence or public PoC was found
Exact post-exploit capability is sparsely documented by the vendor
EDR/browser-hardening may catch noisy follow-on behavior even if it misses the initial bug

Detection/coverage: Expect weak preventative detection and better post-facto signals: browser crashes, anomalous child-process behavior, and user reports from shared-network locations.

03 · Intelligence Metadata

The supporting signals.

In-the-wild status	No public evidence of active exploitation found as of 2026-06-08; not mentioned in Google-facing advisories reviewed and not KEV-listed.
Public PoC availability	No public GitHub/web PoC located in current searches for `CVE-2026-11241`; weaponization would likely be custom local-network Cast emulation rather than copy-paste RCE tooling.
EPSS	`0.00015` (~0.015%), which is deep background-noise territory and matches the narrow attacker-position requirement.
KEV status	Not listed in CISA KEV as of 2026-06-08.
CVSS vector readout	`CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H` = adjacent network only, no auth, but does require user interaction; that `AV:A + UI:R` combo is the key downgrade pressure.
Affected versions	Chrome desktop prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on Windows/macOS, per the Chrome release and Cyber Centre advisory.
Fixed versions	Upgrade to 149.0.7827.53 (Linux) or 149.0.7827.53/.54 (Windows/macOS). No distro-specific Chromium backport bulletin for this exact CVE was located yet.
Exposure / scanning reality	This is a poor fit for internet scan math: Shodan/Censys/FOFA do not meaningfully capture same-segment Cast abuse. Reachability is dominated by local Wi-Fi/L2 design, mDNS forwarding, and whether users actually use Cast.
Disclosure date	2026-06-05
Reporter / researcher	No public finder attribution located in the reviewed sources for this specific CVE; Chrome often withholds detail around fresh browser bugs.

04 · The Call

noisgate verdict.

Final Verdict

↓ DOWNGRADED to MEDIUM (5.4/10)

The decisive factor is attacker position: this bug requires the adversary to already share the victim's local network segment and then rely on Cast-specific user activity. That slashes exposed population compared with internet-reachable Chrome flaws, so the vendor's generic browser-impact score does not hold up as enterprise patch-priority truth.

HIGH Attack-precondition downgrade driven by `AV:A` and `UI:R`

MEDIUM Exact post-exploit privilege gain and impact details

Why this verdict

Adjacent-network only: AV:A means the attacker is not on the internet; they must already be on the victim's Wi-Fi/L2 domain or a specially bridged segment. That is immediate downward pressure from the vendor's 8.0 baseline.
User interaction still required: UI:R matters here because the victim must touch a Cast-capable workflow. This is not a no-click browser bug and not a passive exposure on every Chrome launch.
Feature exposure is narrow: Cast usage on managed enterprise desktops is uneven, and many orgs break or disable the path with segmentation, multicast controls, or policy. That sharply reduces the reachable population versus ordinary web-rendering bugs.

Why not higher?

There is no public KEV entry, no active-exploitation reporting, and no public PoC located. More importantly, the attack chain assumes a nearby attacker and a Cast interaction path, which removes the mass internet-scale exposure that usually justifies a HIGH or CRITICAL browser emergency.

Why not lower?

The flaw still requires no authentication once the attacker is on the segment, and Chrome is ubiquitous enough that shared-network scenarios are not hypothetical. If your estate includes meeting-room PCs, education labs, hospitality endpoints, kiosks, or mixed-trust Wi-Fi, the reachable slice is real enough to keep this above pure backlog trivia.

05 · Compensating Control

What to do — in priority order.

Restrict Cast on managed endpoints — Disable or limit Cast-related browser use where it has no business value, especially on shared workstations, kiosks, and meeting-room systems. For a MEDIUM verdict there is no mitigation SLA; apply this as routine hardening while patch rollout proceeds.
Keep guest and BYOD off the same trust zone — Separate unmanaged devices from managed Chrome endpoints and avoid broad mDNS/Bonjour forwarding between those segments. This directly attacks the most important prerequisite—the attacker's same-segment position—and, for MEDIUM, there is no mitigation SLA beyond normal network-hardening cadence.
Enforce version compliance — Use endpoint management to identify Chrome builds below 149.0.7827.53/.54 and keep auto-update enabled. For MEDIUM, there is no mitigation SLA; use your normal browser compliance wave, but don't let unmanaged outliers linger.
Watch for rogue local discovery traffic — Baseline mDNS/SSDP and Cast-related ports in conference rooms, training labs, and guest-adjacent spaces so sudden rogue advertisements stand out. This is a detective control, not a substitute for patching, and for MEDIUM it can be folded into regular monitoring work.

What doesn't work

A WAF or internet edge ACL does not help; the bug is not primarily internet-facing and lives on the victim's local segment.
MFA does not meaningfully reduce risk because the attacker does not need to log in to Chrome to reach the vulnerable path.
External attack-surface scanners will miss most of the real exposure because same-segment Cast discovery is the gating condition.

06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-distribution/EDR scripting channel. Invoke it with python3 chrome_cve_2026_11241_check.py on macOS/Linux or py chrome_cve_2026_11241_check.py on Windows; standard user rights are usually enough because it only reads installed Chrome version metadata from common paths and the registry.

noisgate-verify.py

PYTHONREAD-ONLYSAFE

#!/usr/bin/env python3\n# CVE-2026-11241 local verification helper\n# Output: VULNERABLE / PATCHED / UNKNOWN\n# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN\n\nimport os\nimport platform\nimport re\nimport subprocess\nimport sys\n\nFIXED = (149, 0, 7827, 53)\n\ndef parse_version(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        out = (p.stdout or '') + '\n' + (p.stderr or '')\n        return out.strip()\n    except Exception:\n        return ''\n\ndef get_windows_version():\n    try:\n        import winreg\n    except Exception:\n        return None\n\n    reg_paths = [\n        (winreg.HKEY_CURRENT_USER, r'Software\\Google\\Chrome\\BLBeacon', 'version'),\n        (winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\\Google\\Chrome\\BLBeacon', 'version'),\n        (winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\\WOW6432Node\\Google\\Chrome\\BLBeacon', 'version'),\n    ]\n    for hive, path, name in reg_paths:\n        try:\n            with winreg.OpenKey(hive, path) as k:\n                val, _ = winreg.QueryValueEx(k, name)\n                v = parse_version(str(val))\n                if v:\n                    return v\n        except Exception:\n            pass\n\n    paths = [\n        os.path.join(os.environ.get('ProgramFiles', r'C:\\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),\n        os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),\n        os.path.join(os.environ.get('LOCALAPPDATA', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),\n    ]\n    ps = r\"$p='%s'; if (Test-Path $p) {(Get-Item $p).VersionInfo.ProductVersion}\"\n    for p in paths:\n        if p and os.path.exists(p):\n            out = run_cmd(['powershell', '-NoProfile', '-Command', ps % p.replace("'", "''")])\n            v = parse_version(out)\n            if v:\n                return v\n    return None\n\ndef get_macos_version():\n    app = '/Applications/Google Chrome.app/Contents/Info.plist'\n    if os.path.exists(app):\n        out = run_cmd(['/usr/bin/defaults', 'read', '/Applications/Google Chrome.app/Contents/Info', 'KSVersion'])\n        v = parse_version(out)\n        if v:\n            return v\n        out = run_cmd(['/usr/libexec/PlistBuddy', '-c', 'Print :KSVersion', app])\n        v = parse_version(out)\n        if v:\n            return v\n    out = run_cmd(['/Applications/Google Chrome.app/Contents/MacOS/Google Chrome', '--version'])\n    v = parse_version(out)\n    if v:\n        return v\n    return None\n\ndef get_linux_version():\n    candidates = [\n        ['google-chrome', '--version'],\n        ['google-chrome-stable', '--version'],\n        ['chromium', '--version'],\n        ['chromium-browser', '--version'],\n    ]\n    for cmd in candidates:\n        out = run_cmd(cmd)\n        v = parse_version(out)\n        if v:\n            return v\n    return None\n\ndef main():\n    system = platform.system().lower()\n    version = None\n\n    if 'windows' in system:\n        version = get_windows_version()\n    elif 'darwin' in system:\n        version = get_macos_version()\n    else:\n        version = get_linux_version()\n\n    if not version:\n        print('UNKNOWN - could not determine installed Chrome/Chromium version')\n        sys.exit(2)\n\n    print('Detected version: %s' % '.'.join(map(str, version)))\n\n    if cmp_ver(version, FIXED) < 0:\n        print('VULNERABLE - version is older than 149.0.7827.53')\n        sys.exit(1)\n    else:\n        print('PATCHED - version is 149.0.7827.53 or newer')\n        sys.exit(0)\n\nif __name__ == '__main__':\n    main()\n

07 · Bottom Line

If you remember one thing.

TL;DR

Monday morning, treat this as a routine-but-real browser exposure, not a stop-the-world event: inventory every Chrome desktop instance below 149.0.7827.53/.54, with extra attention to kiosks, meeting-room PCs, education/hospitality endpoints, and any fleet that sits on mixed-trust or guest-adjacent Wi-Fi. For a MEDIUM reassessment, the noisgate mitigation SLA does not apply — no mitigation SLA — go straight to the 365-day remediation window — and the noisgate remediation SLA is ≤365 days; in practice, because Chrome updates are cheap, fold this into your next standard browser rollout rather than letting it age toward that outer limit.

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.