This is a sharp knife left in the break room, not a sniper on the roof
CVE-2026-9111 is a use-after-free in Chrome's WebRTC stack that can be triggered when a Linux user loads attacker-controlled web content. The published CVE description says Google Chrome on Linux before 148.0.7778.179 is affected, while Google's May 19, 2026 Stable Channel post says Linux was updated to 148.0.7778.178; defenders should treat anything below the distro-fixed build or below the vendor-fixed build line as suspect until package provenance is confirmed. This is a client-side browser bug, so the attacker does not need prior auth on the endpoint, but they do need the user to render malicious content.
The vendor's 8.8/HIGH baseline is technically fair in a lab because memory corruption in a browser can become code execution. In enterprise reality, though, this is narrowed by three big friction points: it is Linux-only, it is user-interaction driven, and there is no KEV listing or known in-the-wild activity in the sources reviewed. That combination pushes it down from urgent enterprise-wide emergency patching into a targeted Linux endpoint patching problem.
4 steps from start to impact.
Land the victim on attacker-controlled content
- Victim uses Google Chrome or a downstream Chromium build on Linux
- Victim browses to attacker-controlled or attacker-influenced content
- WebRTC code path is reachable in that session
- Requires user interaction and content rendering, not a blind unauthenticated hit on a server port
- Linux desktop population is materially smaller than Windows in most enterprises
- Secure web gateways, browser isolation, URL filtering, and phishing-resistant workflows reduce reach
Trigger the WebRTC memory corruption
- Attacker can execute JavaScript or otherwise influence page behavior
- Target build is still running a vulnerable WebRTC implementation
- No public root-cause write-up or functional PoC was located
- Reliability on modern browser builds is non-trivial even when the bug class is known
- Some enterprise policies disable or constrain WebRTC-dependent workflows
Escape renderer constraints to reach durable host impact
- Successful memory corruption and code execution in the affected process
- A path from compromised browser process to host-level objectives
- Chromium documents layered Linux sandboxing with namespaces and seccomp on supported systems
- Enterprise EDR often catches browser-spawned payloads or suspicious process chains
- Developer workstations running permissive flags like
--no-sandboxare a minority but are higher risk
chrome://sandbox can help spot weakened local browser sandbox posture during triage.Monetize the foothold
- Compromised user has access to valuable tokens, code, or admin workflows
- Follow-on controls do not stop persistence or lateral movement
- Impact is concentrated in Linux user populations, especially engineering and admin cohorts
- Credential vaulting, MFA, PAM, and EDR reduce post-browser payoff
- No current evidence of widespread campaign use
google-chrome, chromium, and chromedriver versions across Linux endpoints. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but you still need clean scoping before you can patch intelligently.--no-sandbox or other unsupported hardening exceptions, especially on developer workstations and build hosts. Those exceptions remove the biggest natural friction in the attack chain and should be corrected while you remediate.- Perimeter vulnerability scanning doesn't solve this because the vulnerable surface is a client browser, not a remotely fingerprintable service.
- WAF rules are irrelevant here unless the only delivery path is one of your own web apps; they do nothing for phishing, malvertising, or third-party sites.
- Relying on 'Linux is a smaller target' is not a control. It reduces population size, not exploitability on the endpoints that matter most.
The supporting signals.
| In-the-wild status | No public exploitation evidence found in reviewed sources, and no CISA KEV listing was found for this CVE. |
|---|---|
| Proof-of-concept availability | No public functional PoC located; Chromium issue 504551032 appears restricted, which is typical during patch rollout. |
| EPSS | 0.00024 from the user-supplied intel; that is very low predictive exploit pressure. Percentile was not independently verified from an accessible FIRST CVE-specific record. |
| KEV status | Not KEV-listed as of the reviewed sources. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — the key real-world brake is UI:R. This is not a blind server-side hit. |
| Affected versions | Published CVE/NVD text says Google Chrome on Linux prior to 148.0.7778.179. |
| Fixed versions / backports | Google's May 19, 2026 release note says Linux was updated to 148.0.7778.178. Debian backported fixes to 148.0.7778.178-1~deb12u1 and 148.0.7778.178-1~deb13u1; SUSE lists fixed Chromium packages at 148.0.7778.178 package builds. |
| Scanning / exposure data | This is not meaningfully internet-enumerable through Shodan/Censys in the usual way because it is a client browser flaw. Exposure has to be measured from asset inventory, package telemetry, EDR, MDM, or local checks, not internet scans. |
| Disclosure date | 2026-05-20 in the CVE/NVD record; Google's stable desktop update post is dated 2026-05-19. |
| Reporter | Google's advisory says the issue was reported by Google on 2026-04-20. |
Sources.
- Google Chrome Releases: Stable Channel Update for Desktop (May 19, 2026)
- NVD record for CVE-2026-9111
- CVE.org record for CVE-2026-9111
- Chromium Linux sandbox documentation
- Chromium Linux sandboxing overview
- Debian Security Advisory DSA-6287-1
- SUSE CVE page for CVE-2026-9111
- CISA Known Exploited Vulnerabilities Catalog
Why this verdict
- Down from 8.8 because the attacker needs user interaction — they must get a Linux Chrome user to load hostile content, which implies phishing, malvertising, or watering-hole success first.
- Down again because it is Linux-only — this immediately shrinks the exposed population in most enterprises, often to engineering, admin, VDI, or kiosk subsets rather than the whole workforce.
- Down again because client-side browser bugs are not estate-wide internet exposure — there is no server port to sweep, no mass unauthenticated reachability, and modern web filtering/browser isolation/EDR can break the chain before impact.
- Down again because current threat pressure is weak — no KEV, no public exploit chain found, and the supplied EPSS is extremely low.
- Not lower than MEDIUM because memory corruption in a browser still matters — Linux developer and admin endpoints can hold high-value cloud, CI/CD, and SSH material, so compromise of the right user can be expensive.
Why not higher?
A higher rating would require an amplifier that is missing here: active exploitation, public weaponization, or broad unauthenticated reach. Instead, the chain starts with getting a Linux user to render hostile content and then still has to survive Chrome's sandbox and enterprise endpoint controls.
Why not lower?
This is still a remote, internet-deliverable memory corruption bug in a major browser component with code-execution potential. For Linux engineering and administrative users, the downstream blast radius can be significant enough that this is not backlog trivia.
Crowdsourced verification payload.
Run this on the target Linux endpoint or via your remote shell/EDR live-response tool. Invoke it as bash check_cve_2026_9111.sh with no arguments; it needs only standard user privileges, though root may be needed to inspect some package-manager metadata paths in hardened environments.
#!/usr/bin/env bash
# check_cve_2026_9111.sh
# Detect likely exposure to CVE-2026-9111 on Linux Chrome/Chromium hosts.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
# Note: Public sources disagree on the Linux fixed version:
# - CVE/NVD text says prior to 148.0.7778.179 is vulnerable
# - Google Chrome Releases says Linux updated to 148.0.7778.178 on 2026-05-19
# We use the stricter threshold (.179) for Google Chrome binaries,
# and report distro Chromium package builds based on their package version strings.
STRICT_FIXED="148.0.7778.179"
VENDOR_LINUX_FIXED="148.0.7778.178"
have_cmd() { command -v "$1" >/dev/null 2>&1; }
ver_lt() {
# returns 0 if $1 < $2
[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ]
}
extract_version() {
# Pull first x.y.z.w-like token
echo "$1" | grep -Eo '[0-9]+(\.[0-9]+){3,}' | head -n1
}
status="UNKNOWN"
reason="No supported Chrome/Chromium install found"
found_any=0
check_binary() {
local bin="$1"
local flavor="$2"
local out ver
if ! have_cmd "$bin"; then
return
fi
found_any=1
out="$($bin --version 2>/dev/null || true)"
ver="$(extract_version "$out")"
if [ -z "$ver" ]; then
status="UNKNOWN"
reason="Could not parse version from $bin"
return
fi
case "$flavor" in
google-chrome)
if ver_lt "$ver" "$STRICT_FIXED"; then
status="VULNERABLE"
reason="$bin version $ver is below strict fixed threshold $STRICT_FIXED for CVE-2026-9111"
else
status="PATCHED"
reason="$bin version $ver is at or above strict fixed threshold $STRICT_FIXED"
fi
;;
chromium)
# Upstream Linux advisory/blog indicates 148.0.7778.178 for Linux.
if ver_lt "$ver" "$VENDOR_LINUX_FIXED"; then
status="VULNERABLE"
reason="$bin version $ver is below Linux fixed threshold $VENDOR_LINUX_FIXED"
else
status="PATCHED"
reason="$bin version $ver is at or above Linux fixed threshold $VENDOR_LINUX_FIXED"
fi
;;
esac
}
check_pkg() {
# Best-effort package checks for distros where Chromium is package-managed.
if have_cmd dpkg-query; then
local pkgver
pkgver="$(dpkg-query -W -f='${Version}\n' chromium 2>/dev/null | head -n1 || true)"
if [ -n "$pkgver" ]; then
found_any=1
case "$pkgver" in
148.0.7778.178-1~deb12u1|148.0.7778.178-1~deb13u1|148.0.7778.178-*|148.0.7778.179-*|149.*|150.*)
status="PATCHED"
reason="Debian/Ubuntu chromium package version $pkgver appears fixed/backported"
return
;;
esac
# Fall back to numeric prefix if present
local base
base="$(echo "$pkgver" | grep -Eo '^[0-9]+(\.[0-9]+){3,}' | head -n1)"
if [ -n "$base" ]; then
if ver_lt "$base" "$VENDOR_LINUX_FIXED"; then
status="VULNERABLE"
reason="chromium package base version $base is below Linux fixed threshold $VENDOR_LINUX_FIXED"
else
status="PATCHED"
reason="chromium package base version $base is at or above Linux fixed threshold $VENDOR_LINUX_FIXED"
fi
return
fi
status="UNKNOWN"
reason="Found chromium package $pkgver but could not map it confidently to fixed/backported status"
fi
fi
if have_cmd rpm; then
local rpmver
rpmver="$(rpm -q --qf '%{VERSION}-%{RELEASE}\n' chromium 2>/dev/null | head -n1 || true)"
if [ -n "$rpmver" ] && [ "$rpmver" != "package chromium is not installed" ]; then
found_any=1
case "$rpmver" in
148.0.7778.178-*|148.0.7778.179-*|149.*|150.*)
status="PATCHED"
reason="RPM chromium package version $rpmver appears fixed/backported"
return
;;
esac
local base
base="$(echo "$rpmver" | grep -Eo '^[0-9]+(\.[0-9]+){3,}' | head -n1)"
if [ -n "$base" ]; then
if ver_lt "$base" "$VENDOR_LINUX_FIXED"; then
status="VULNERABLE"
reason="RPM chromium base version $base is below Linux fixed threshold $VENDOR_LINUX_FIXED"
else
status="PATCHED"
reason="RPM chromium base version $base is at or above Linux fixed threshold $VENDOR_LINUX_FIXED"
fi
return
fi
status="UNKNOWN"
reason="Found RPM chromium package $rpmver but could not map it confidently to fixed/backported status"
fi
fi
}
# Prefer explicit browser binaries first.
check_binary google-chrome google-chrome
if [ "$status" = "UNKNOWN" ]; then check_binary google-chrome-stable google-chrome; fi
if [ "$status" = "UNKNOWN" ]; then check_binary chromium chromium; fi
if [ "$status" = "UNKNOWN" ]; then check_binary chromium-browser chromium; fi
if [ "$status" = "UNKNOWN" ]; then check_pkg; fi
if [ "$found_any" -eq 0 ]; then
echo "UNKNOWN: $reason"
exit 2
fi
case "$status" in
PATCHED)
echo "PATCHED: $reason"
exit 0
;;
VULNERABLE)
echo "VULNERABLE: $reason"
exit 1
;;
*)
echo "UNKNOWN: $reason"
exit 2
;;
esac