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

Inappropriate implementation in Cast in Google Chrome prior to 149

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

This is a side-door key that only works if the attacker is already standing in your hallway

CVE-2026-11276 is a Cast implementation flaw in Google Chrome that affects desktop builds prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/54 on Windows and macOS. The bug lets an attacker on the *same local network segment* send malicious network traffic and bypass discretionary access control in the Cast path, which translates to unauthorized access to some Cast-related action or state rather than full browser compromise.

Google's MEDIUM 5.1 label is defensible in a vacuum, but it is too generous for most enterprise fleets. The decisive friction is attacker position: this is not internet-reachable and not webpage-triggered, it needs local adjacency on the same LAN/Wi-Fi segment and a reachable Cast surface, which makes it a post-initial-access or insider-style issue with limited blast radius and only low confidentiality/integrity impact.

"Adjacent-network Cast bug with low impact and no exploit noise: patch it, but don't let it cut the line."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Get adjacent to the victim network

The attacker first needs a foothold on the same local network segment as the target Chrome host. In practice that means shared office Wi-Fi, the same wired VLAN, a guest network with poor isolation, or a compromised endpoint already inside the environment. Typical tooling here is ordinary access tooling, not a browser exploit kit: a rogue AP, a compromised workstation, or commodity packet tools such as tcpdump and Scapy.
Conditions required:
  • Attacker is on the same local network segment as the target
  • Target is reachable over local network traffic paths
  • No client isolation or segmentation blocks peer traffic
Where this breaks in practice:
  • This is already a *post-compromise or insider* position in most enterprises
  • Modern guest Wi-Fi often uses client isolation
  • Corp VLAN segmentation and NAC frequently prevent broad lateral peer reachability
Detection/coverage: No vulnerability scanner reliably proves this precondition. Network telemetry can sometimes spot unusual east-west discovery traffic, but coverage is inconsistent.
STEP 02

Find a Chrome host with Cast reachable

The attacker then needs to identify a target where Chrome's Cast functionality is present and locally reachable. Discovery is likely done with avahi-browse, mdns-scan, nmap NSE discovery scripts, or custom multicast listeners to watch mDNS/SSDP-style traffic patterns associated with media discovery and casting workflows.
Conditions required:
  • Chrome is installed in an affected version range
  • Cast-related functionality is enabled or active enough to be reachable
  • Local multicast or discovery traffic is not suppressed
Where this breaks in practice:
  • Many enterprise builds disable or never use Cast
  • Discovery traffic is often filtered across VLANs
  • Laptop populations are large, but *reachable Cast surface* is much smaller than total Chrome install base
Detection/coverage: Exposure management tools usually miss this because it is a client-side feature path, not a service banner you can internet-scan.
STEP 03

Send malicious Cast traffic

With adjacency and a reachable target, the attacker sends crafted network traffic at the Cast component to trigger the access-control bypass. The weaponized tooling would most likely be a custom packet generator built with Scapy or a private proof-of-concept; no public exploit code was found during this assessment.
Conditions required:
  • Attacker understands the Cast message flow enough to craft valid traffic
  • Bug details are available privately or reverse engineered from patches
  • Target is still unpatched
Where this breaks in practice:
  • Chromium issue details are often restricted until broad patch adoption
  • No public PoC was found
  • Implementation bugs in protocol handling are easy to misfire outside lab conditions
Detection/coverage: EDR is unlikely to catch this step directly unless it causes anomalous Chrome behavior. NDR may see odd local traffic patterns, but signature quality will be poor without public exploit samples.
STEP 04

Abuse the bypass for low-grade impact

Successful exploitation yields a bypass of discretionary access control in the Cast path, which lines up with low confidentiality and integrity effects rather than code execution or host takeover. That makes this more useful for opportunistic local abuse, nuisance, or limited unauthorized action than for high-value intrusion chains.
Conditions required:
  • The malformed traffic actually reaches the vulnerable Cast logic
  • The target environment uses Cast in a way that exposes something worth abusing
Where this breaks in practice:
  • Impact is only C:L/I:L/A:N
  • No evidence of chaining into sandbox escape, privilege escalation, or RCE
  • Business blast radius is typically one nearby user or device context, not a fleet-wide compromise
Detection/coverage: Post-event evidence may only be visible in Chrome logs, crash telemetry, or network captures. Traditional vuln scans will not confirm exploitation.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found, and the CVE is not listed in CISA KEV.
Public PoC availabilityNo public proof-of-concept located. Chromium bug details are commonly restricted until patch uptake, which raises attacker friction.
EPSS0.00005 probability, effectively floor-level risk in the near term.
KEV statusNot KEV-listed as of the catalog check; there is no CISA due date.
CVSS vector reality checkCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N maps to a low-impact flaw, but the important practical nuance is that the write-up says *local network segment*, which is really an adjacent/internal-network prerequisite for enterprise triage.
Affected versionsGoogle Chrome desktop builds before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS.
Fixed versionsPatch in stable desktop Chrome 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS). Windows/macOS Extended Stable 148.0.7778.254 also carries the security fixes; openSUSE shipped chromium/chromedriver >= 149.0.7827.53-2.1.
Scanning and exposureThis is not meaningfully internet-scannable like a server CVE. Shodan/Censys-style exposure data is low-value here because reachable population is driven by *same-segment Cast reachability*, not WAN exposure.
Disclosure and reporterPublicly disclosed on 2026-06-05. I found no public external researcher attribution for this specific CVE.
Chromium internal severityPublic mirrors describe the underlying Chromium security severity as Low, which better matches operational reality than the vendor CVSS bucket.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.2/10)

The single biggest downgrade factor is the attacker-position requirement: exploitation needs the attacker on the same local network segment, which usually implies a prior foothold, an insider, or poor guest/corp isolation. With no KEV listing, no public exploitation evidence, and only low confidentiality/integrity impact, this is not the kind of Chrome bug that should displace remotely triggerable browser RCEs or credential theft issues.

HIGH Version range and fixed builds
MEDIUM Operational severity downgrade versus vendor baseline
LOW Exact exploit mechanics, because public bug details remain sparse

Why this verdict

  • Adjacent-network prerequisite cuts the population hard: the attacker must be on the same local segment, which in enterprise terms usually means post-initial-access, insider presence, or shared Wi-Fi adjacency; that is a material downgrade from any remotely deliverable browser bug.
  • Feature reachability is narrower than Chrome install base: Chrome is everywhere, but reachable Cast attack surface is not. Enterprises commonly disable casting, suppress local discovery, or simply never use it on managed endpoints.
  • Threat intel is quiet: no KEV, no public exploitation evidence, no public PoC found, and EPSS is essentially at the floor. That is strong downward pressure from the vendor's 5.1 baseline.

Why not higher?

This is not a drive-by web exploit, not internet-reachable, and not an RCE. The attack path assumes local adjacency plus a Cast-relevant target state, and the resulting impact is only low confidentiality/integrity loss with no availability impact.

Why not lower?

It is still a real access-control bypass in a product deployed at huge scale, and local-segment exposure is not hypothetical in campuses, shared offices, labs, and guest/corp Wi-Fi mistakes. If you have unmanaged nearby devices, poor client isolation, or active Cast usage, the bug is worth fixing even if it should not outrank remotely weaponizable Chrome flaws.

05 · Compensating Control

What to do — in priority order.

  1. Disable Cast where unused — Use Chrome enterprise policy to remove or restrict Cast on managed endpoints that do not need it. This directly shrinks the reachable attack surface and, for a LOW verdict, should be handled as backlog hygiene with no formal mitigation SLA unless you know you have exposed shared-network use cases.
  2. Enforce client isolation on guest and shared Wi-Fi — Turn on peer isolation and keep guest wireless off corp trust zones so adjacent clients cannot directly reach each other. This is the best architectural control for the bug's only realistic attack path and should be folded into normal network-hardening work, again with no formal mitigation SLA for this severity.
  3. Constrain local discovery traffic — Filter or limit mDNS/SSDP-style east-west discovery where it is not business-required. That reduces discovery and exploit reliability for Cast-adjacent abuse and is especially useful in conference rooms, labs, and shared floors.
  4. Keep managed Chrome on stable or Extended Stable auto-update — This bug is best neutralized by version hygiene, not detective controls. Ensure endpoints actually consume Stable 149.0.7827.53/54 or Windows/macOS Extended Stable 148.0.7778.254 through your normal browser update rings.
What doesn't work
  • A WAF does not help; the attack is local network traffic into Cast behavior, not HTTP traffic to a web application.
  • MFA does not help; there is no login step in the exploit path.
  • Internet perimeter blocking does little because the meaningful exposure is east-west local adjacency, not WAN reachability.
  • Generic email filtering is irrelevant unless your only threat model is how the attacker got onto the LAN in the first place.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint itself, or push it through your RMM/SCCM/Jamf/Intune script runner. Invoke it as python3 check_chrome_cve_2026_11276.py on macOS/Linux or py check_chrome_cve_2026_11276.py on Windows; no administrator rights are normally required because it only reads the installed browser version.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11276.py
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import os
import platform
import re
import subprocess
import sys
from shutil import which

FIX_STABLE = (149, 0, 7827, 53)
FIX_EXTENDED = (148, 0, 7778, 254)  # Windows/macOS Extended Stable includes the security fixes


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 run_version(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=5)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def candidate_commands():
    system = platform.system().lower()
    cmds = []

    if system == 'windows':
        for path in [
            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'),
        ]:
            if path and os.path.exists(path):
                cmds.append([path, '--version'])
    elif system == 'darwin':
        path = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
        if os.path.exists(path):
            cmds.append([path, '--version'])
    else:
        for name in ['google-chrome', 'google-chrome-stable', 'chromium-browser', 'chromium']:
            p = which(name)
            if p:
                cmds.append([p, '--version'])

    return cmds


def is_patched(version, system_name):
    # Stable fix for all platforms
    if version >= FIX_STABLE:
        return True

    # Windows/macOS Extended Stable path
    if system_name in ('windows', 'darwin'):
        if version[0:3] == FIX_EXTENDED[0:3] and version >= FIX_EXTENDED:
            return True

    return False


def is_potentially_vulnerable(version, system_name):
    # Any 149 build below stable fix is vulnerable
    if version[0:3] == FIX_STABLE[0:3] and version < FIX_STABLE:
        return True

    # Earlier majors are vulnerable unless they are the known Extended Stable fixed train on Win/macOS
    if version[0] < 149:
        if system_name in ('windows', 'darwin') and version[0:3] == FIX_EXTENDED[0:3] and version >= FIX_EXTENDED:
            return False
        return True

    return False


def main():
    system_name = platform.system().lower()
    cmds = candidate_commands()

    if not cmds:
        print('UNKNOWN - Google Chrome executable not found')
        sys.exit(2)

    seen = []
    for cmd in cmds:
        output = run_version(cmd)
        version = parse_version(output)
        if version:
            seen.append((cmd[0], version, output))

    if not seen:
        print('UNKNOWN - Could not determine installed Chrome version')
        sys.exit(2)

    # Prefer the highest version found if multiple copies exist
    seen.sort(key=lambda x: x[1], reverse=True)
    path, version, raw = seen[0]

    if is_patched(version, system_name):
        print(f'PATCHED - {path} -> {raw}')
        sys.exit(0)

    if is_potentially_vulnerable(version, system_name):
        print(f'VULNERABLE - {path} -> {raw}')
        sys.exit(1)

    print(f'UNKNOWN - {path} -> {raw} (version not mapped cleanly to stable or extended-stable fix trains)')
    sys.exit(2)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not let this jump ahead of remotely triggerable browser bugs, auth bypasses, or RCEs. Put it into normal browser patch governance: identify Chrome versions below 149.0.7827.53/54 and Windows/macOS devices not yet on Extended Stable 148.0.7778.254, disable Cast where it is unnecessary during routine hardening, and clean up guest/shared-network peer isolation gaps; for a LOW verdict there is no noisgate mitigation SLA and noisgate remediation SLA is backlog hygiene, so target the next ordinary browser update cycle rather than an emergency change window.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop
  2. Google Chrome Releases - Extended Stable Updates for Desktop
  3. Canadian Centre for Cyber Security - Google Chrome security advisory AV26-544
  4. SUSE CVE page for CVE-2026-11276
  5. openSUSE patchinfo including CVE-2026-11276
  6. FIRST EPSS data and statistics
  7. CISA Known Exploited Vulnerabilities Catalog
  8. Chromium Security
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.