This is a bad lock on an interior door, not an open front gate
CVE-2026-11282 is a Linux-only Google Chrome sandbox policy enforcement flaw affecting versions prior to 149.0.7827.53. A malicious site can potentially abuse the browser's Linux sandbox handling via crafted HTML so code or actions that should stay trapped in the renderer may break containment and reach beyond the intended browser isolation boundary.
The 9.6/CRITICAL label overstates enterprise reality. This is still a real browser boundary failure, but it is client-side, user-interaction-driven, Linux-only, not internet-scannable, and currently lacks KEV listing, public PoC, or observed exploitation evidence; those are major downward pressures compared with a remotely reachable server bug.
4 steps from start to impact.
Land the user on attacker-controlled content
- Victim uses Google Chrome on Linux
- Browser version is below
149.0.7827.53 - Victim opens attacker-controlled or attacker-influenced web content
- This is UI:R; no drive-by against a server fleet
- Many enterprises have a much smaller Linux browser population than Windows or macOS
- Safe Browsing, URL filtering, mail security, and user isolation can stop delivery before exploit
Trigger the Linux sandbox policy weakness
502023400. Public technical detail is still sparse because Chromium notes that bug details may stay restricted until most users are patched, so defenders should assume the exploit path is not yet fully documented in public.- Exploit path must still be reachable in the deployed Linux build
- Attacker content must hit the exact code path fixed in Chrome 149.0.7827.53
- No public PoC was found in retrieved sources
- Restricted bug details slow commoditization
- Browser exploit reliability often varies by distro, kernel, and sandbox configuration
Break containment out of the renderer sandbox
- Exploit must bypass the specific Linux sandbox enforcement control
- Target host must not have another isolation layer stopping post-sandbox actions
- Escaping the renderer is serious, but it is still bounded by user context and host controls
- Application isolation, restrictive SELinux/AppArmor profiles, and EDR can reduce follow-on success
- Some real-world impact may still require chaining with another primitive
Monetize with user-context actions
- Valuable local data or enterprise sessions exist on the host
- Attacker has a useful post-escape objective
- No evidence yet of broad in-the-wild weaponization
- User-context access is meaningful but not equivalent to domain-wide compromise
- Privileged admin separation and browser isolation sharply reduce blast radius
The supporting signals.
| In-the-wild status | No confirmed public exploitation evidence found in retrieved sources; not listed in CISA KEV as of 2026-06-06. |
|---|---|
| PoC availability | No public PoC located. The Chromium bug 502023400 is still effectively non-public from anonymous access, which usually delays copycat exploit development. |
| EPSS | 0.00089 from the user-supplied intel block — extremely low predicted near-term exploitation probability. Exact percentile was not confirmed from retrieved primary sources. |
| KEV status | Not KEV-listed. No CISA due date or federal emergency patch signal is attached. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H — the *score assumes worst-case impact after user interaction*, but it does not price in Linux-only reach or client-side deployment friction. |
| Affected versions | Google Chrome on Linux prior to 149.0.7827.53. Retrieved sources do not show Windows, macOS, or ChromeOS as affected for this CVE. |
| Fixed version | Google Chrome 149.0.7827.53 on Linux. Chrome's desktop stable note on 2026-06-02 shipped that Linux build; distro-packaged Chromium backports were not established in retrieved sources. |
| Exposure / scanning reality | Not internet-scannable in the usual Shodan/Censys/FOFA sense because this is a client browser flaw, not a remotely enumerable listening service. Asset inventory and EDR are the right discovery controls. |
| Disclosure timeline | Chrome shipped the fix on 2026-06-02; NVD shows the CVE record published on 2026-06-04 and CISA-ADP enrichment on 2026-06-05. |
| Reporter / researcher | The public stable release note does not name an external reporter for this CVE, and the linked Chromium issue is access-restricted from anonymous view. |
noisgate verdict.
The decisive factor is reachability friction: this bug hits only Google Chrome on Linux, requires user interaction, and lives on the client side, so it cannot be mass-exploited like an unauthenticated edge service. It stays meaningful because sandbox escapes are valuable browser-chain components, but the lack of KEV, PoC, and exposure-at-scale keeps it firmly below emergency patch territory.
Why this verdict
- [object Object]
- Downgrade for attacker position: exploitation starts from a malicious web page with user interaction, not unauthenticated remote access to a service. That immediately removes the 'scan once, hit thousands of hosts' economics that justify many critical scores.
- Downgrade for population reach: the vulnerable set is Linux Chrome only. In most enterprises, that implies a narrower and more specialized workstation population than general desktop browser exposure.
- Downgrade for threat intel weakness: no KEV listing, no public PoC, and EPSS 0.00089 mean there is no current sign this is being operationalized at scale.
- Hold at MEDIUM, not LOW: this is still a sandbox escape, which attacks one of Chrome's core containment layers. On high-value Linux admin/dev workstations, a browser boundary break can expose tokens, source, secrets, and follow-on access.
Why not higher?
A higher rating would require a stronger amplifier such as active exploitation, a public weaponized PoC, cross-platform reach, or server-side exposure. None of those are present in the retrieved sources, and the client-side Linux-only deployment reality cuts hard against a CRITICAL/HIGH response.
Why not lower?
A lower rating would ignore that sandbox escapes are strategically valuable even when they are not yet hot in the wild. This is also a remote trigger via web content, so affected Linux workstations that browse untrusted content are exposed without any prior local foothold.
What to do — in priority order.
- Verify browser auto-update works — Make sure Linux Chrome endpoints can actually reach Google's update channels and are not pinned below
149.0.7827.53. Because this is a MEDIUM verdict, there is no noisgate mitigation SLA; use this as a low-friction control while you work inside the 365-day remediation window. - Separate privileged browsing from admin workstations — Keep routine web browsing off Linux systems that hold production credentials, cloud admin sessions, signing keys, or source secrets. There is no noisgate mitigation SLA for MEDIUM issues, but reducing the value of the target host is still worth doing immediately where feasible.
- Enforce URL filtering and Safe Browsing — This bug needs the user to reach attacker-controlled content, so web filtering, DNS controls, and Chrome's phishing protections are directly relevant. With a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but keep these controls healthy because they cut the initial prerequisite.
- Harden Linux endpoint isolation — Use SELinux/AppArmor, least-privilege local accounts, and EDR policies that flag Chrome spawning shells or touching sensitive paths. These controls do not fix the bug, but they can reduce what a post-sandbox attacker can do while patching proceeds inside the 365-day remediation window.
- A WAF does not help; this is a client browser bug, not a vulnerable web application endpoint you can shield at the perimeter.
- Perimeter port scanning does not help; there is no listening service to enumerate because the exposure lives in the browser process on endpoints.
- Relying on MFA alone does not help; if the browser host is compromised in user context, session theft and token abuse can bypass the spirit of MFA.
Crowdsourced verification payload.
Run this on the target Linux endpoint or through your fleet agent. Invoke it as bash check-chrome-cve-2026-11282.sh; no root is required, but root helps if you want package-manager fallback checks to see system packages consistently.
#!/usr/bin/env bash
# check-chrome-cve-2026-11282.sh
# Determine whether Google Chrome on Linux is vulnerable to CVE-2026-11282
# Vulnerable: versions prior to 149.0.7827.53
# Outputs exactly one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
FIXED="149.0.7827.53"
ver_lt() {
# returns 0 if $1 < $2
[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ] && return 1
[ "$1" = "$2" ] && return 1
return 0
}
extract_version() {
# Pull first dotted version token from input
sed -nE 's/.* ([0-9]+(\.[0-9]+){2,}).*/\1/p' | head -n1
}
chrome_version=""
source_note=""
for bin in google-chrome-stable google-chrome /opt/google/chrome/google-chrome; do
if command -v "$bin" >/dev/null 2>&1; then
chrome_version="$($bin --version 2>/dev/null | extract_version)"
source_note="$bin"
break
fi
if [ -x "$bin" ]; then
chrome_version="$($bin --version 2>/dev/null | extract_version)"
source_note="$bin"
break
fi
done
# Package-manager fallback for Google Chrome only
if [ -z "$chrome_version" ]; then
if command -v dpkg-query >/dev/null 2>&1; then
chrome_version="$(dpkg-query -W -f='${Version}\n' google-chrome-stable 2>/dev/null | sed 's/-.*//' | head -n1)"
if [ -n "$chrome_version" ]; then
source_note="dpkg:google-chrome-stable"
fi
fi
fi
if [ -z "$chrome_version" ] && command -v rpm >/dev/null 2>&1; then
chrome_version="$(rpm -q --qf '%{VERSION}\n' google-chrome-stable 2>/dev/null | head -n1)"
if [ -n "$chrome_version" ] && [ "$chrome_version" != "package google-chrome-stable is not installed" ]; then
source_note="rpm:google-chrome-stable"
else
chrome_version=""
fi
fi
# If only Chromium is present, patch state is distro-specific for this CVE text.
if [ -z "$chrome_version" ]; then
for cbin in chromium chromium-browser; do
if command -v "$cbin" >/dev/null 2>&1; then
echo "UNKNOWN"
exit 2
fi
done
fi
if [ -z "$chrome_version" ]; then
echo "UNKNOWN"
exit 2
fi
if ver_lt "$chrome_version" "$FIXED"; then
echo "VULNERABLE"
exit 1
fi
echo "PATCHED"
exit 0
If you remember one thing.
149.0.7827.53 as standard browser hygiene, with extra attention to admin, developer, and cloud-ops workstations where a browser sandbox escape has outsized value. Because this is not KEV-listed and there is no active exploitation evidence, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; use the noisgate remediation SLA to finish patching within 365 days, but most teams should simply let this ride their next normal browser update ring rather than treat it as an emergency exception.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.