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

Insufficient policy enforcement in Sandbox in Google Chrome on Linux prior to 149

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

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.

"Important sandbox boundary bug, but Linux-only client-side reach and zero exploitation intel keep it out of the fire drill tier."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on attacker-controlled content

The attacker needs a victim to load a malicious page in Google Chrome on Linux. In practice that means phishing, malvertising, a compromised trusted site, or embedding the exploit in content the user already browses. The weaponized component here is just a crafted HTML/JS page, not an edge-service exploit.
Conditions required:
  • Victim uses Google Chrome on Linux
  • Browser version is below 149.0.7827.53
  • Victim opens attacker-controlled or attacker-influenced web content
Where this breaks in practice:
  • 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
Detection/coverage: Detection is mostly pre-execution: web proxy, DNS filtering, EDR browser telemetry, and phishing controls. Version scanners can find vulnerable builds, but they do not prove exploit reachability.
STEP 02

Trigger the Linux sandbox policy weakness

Once rendered, the malicious page attempts to exercise the sandbox policy enforcement flaw tracked by Chromium issue 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.
Conditions required:
  • 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
Where this breaks in practice:
  • No public PoC was found in retrieved sources
  • Restricted bug details slow commoditization
  • Browser exploit reliability often varies by distro, kernel, and sandbox configuration
Detection/coverage: Commodity vuln scanners are version-only here. There is no reliable network IDS signature for a generic 'crafted HTML page' exploit path.
STEP 03

Break containment out of the renderer sandbox

If successful, the attacker moves from untrusted web content into a position outside the intended Chrome renderer sandbox boundary on Linux. That matters because Chrome's sandbox is the blast-wall that normally turns many browser bugs into contained crashes instead of workstation compromise or data access.
Conditions required:
  • Exploit must bypass the specific Linux sandbox enforcement control
  • Target host must not have another isolation layer stopping post-sandbox actions
Where this breaks in practice:
  • 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
Detection/coverage: Look for abnormal child processes, file access, credential store access, or shell execution from Chrome/Chromium-related processes in EDR.
STEP 04

Monetize with user-context actions

Post-escape outcomes are the usual workstation playbook: local data theft, session/token harvesting, access to developer material, or launching follow-on payloads under the logged-in user. On Linux admin and engineering workstations, that can still be strategically valuable even without root privileges.
Conditions required:
  • Valuable local data or enterprise sessions exist on the host
  • Attacker has a useful post-escape objective
Where this breaks in practice:
  • 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
Detection/coverage: EDR should catch most noisy post-exploitation steps. DLP and identity telemetry may reveal token theft or unusual access after the browser event.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed public exploitation evidence found in retrieved sources; not listed in CISA KEV as of 2026-06-06.
PoC availabilityNo public PoC located. The Chromium bug 502023400 is still effectively non-public from anonymous access, which usually delays copycat exploit development.
EPSS0.00089 from the user-supplied intel block — extremely low predicted near-term exploitation probability. Exact percentile was not confirmed from retrieved primary sources.
KEV statusNot KEV-listed. No CISA due date or federal emergency patch signal is attached.
CVSS vectorCVSS: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 versionsGoogle Chrome on Linux prior to 149.0.7827.53. Retrieved sources do not show Windows, macOS, or ChromeOS as affected for this CVE.
Fixed versionGoogle 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 realityNot 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 timelineChrome 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 / researcherThe public stable release note does not name an external reporter for this CVE, and the linked Chromium issue is access-restricted from anonymous view.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.9/10)

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.

HIGH Affected product/version boundary: Linux Chrome before `149.0.7827.53`
MEDIUM Severity downgrade versus vendor/CISA-ADP baseline
LOW Exact exploit mechanics because Chromium bug details remain restricted

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: query your Linux fleet for Google Chrome versions and close out anything below 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

  1. NVD CVE-2026-11282
  2. Chrome Releases: Stable Channel Update for Desktop (149.0.7827.53 Linux)
  3. Chromium issue 502023400
  4. Chromium Linux sandbox README
  5. Chromium sandbox design overview
  6. FIRST EPSS API documentation
  7. FIRST EPSS FAQ
  8. CISA Known Exploited Vulnerabilities Catalog
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.