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.
4 steps from start to impact.
Get adjacent to the victim network
tcpdump and Scapy.- 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
- 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
Find a Chrome host with Cast reachable
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.- 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
- 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
Send malicious Cast traffic
Scapy or a private proof-of-concept; no public exploit code was found during this assessment.- 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
- 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
Abuse the bypass for low-grade impact
- The malformed traffic actually reaches the vulnerable Cast logic
- The target environment uses Cast in a way that exposes something worth abusing
- 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
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found, and the CVE is not listed in CISA KEV. |
|---|---|
| Public PoC availability | No public proof-of-concept located. Chromium bug details are commonly restricted until patch uptake, which raises attacker friction. |
| EPSS | 0.00005 probability, effectively floor-level risk in the near term. |
| KEV status | Not KEV-listed as of the catalog check; there is no CISA due date. |
| CVSS vector reality check | CVSS: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 versions | Google Chrome desktop builds before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS. |
| Fixed versions | Patch 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 exposure | This 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 reporter | Publicly disclosed on 2026-06-05. I found no public external researcher attribution for this specific CVE. |
| Chromium internal severity | Public mirrors describe the underlying Chromium security severity as Low, which better matches operational reality than the vendor CVSS bucket. |
noisgate verdict.
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.
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.1baseline.
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.
What to do — in priority order.
- 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
LOWverdict, should be handled as backlog hygiene with no formal mitigation SLA unless you know you have exposed shared-network use cases. - 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.
- 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.
- 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/54or Windows/macOS Extended Stable148.0.7778.254through your normal browser update rings.
- 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.
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.
#!/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()
If you remember one thing.
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
- Google Chrome Releases - Stable Channel Update for Desktop
- Google Chrome Releases - Extended Stable Updates for Desktop
- Canadian Centre for Cyber Security - Google Chrome security advisory AV26-544
- SUSE CVE page for CVE-2026-11276
- openSUSE patchinfo including CVE-2026-11276
- FIRST EPSS data and statistics
- CISA Known Exploited Vulnerabilities Catalog
- Chromium Security
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.