← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-9111 · CWE-416 · Disclosed 2026-05-20

Use after free in WebRTC in Google Chrome on Linux prior to 148

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

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.

"Real bug, real RCE potential, but Linux-only + user-driven delivery + no exploitation signals keep this out of the fire drill lane"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker-controlled content

The attacker needs a Linux Chrome user to load a malicious page or ad frame that exercises the vulnerable WebRTC code path. In practice this is delivered with a phishing lure, watering-hole placement, malvertising, or a compromised site rather than direct network reachability. No public exploit kit is tied to this CVE in the reviewed sources.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Network scanners like Shodan/Censys are a poor fit because this is a client-side browser flaw, not an internet-facing service fingerprint. Exposure is best found through EDR, package inventory, MDM, or local version checks.
STEP 02

Trigger the WebRTC memory corruption

Once the page is loaded, the exploit must drive WebRTC objects into a use-after-free state. The Chrome advisory names the bug class and component but keeps bug details restricted, which is normal while rollout is in progress. That restriction slows copycat weaponization even if it does not eliminate it.
Conditions required:
  • Attacker can execute JavaScript or otherwise influence page behavior
  • Target build is still running a vulnerable WebRTC implementation
Where this breaks in practice:
  • 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
Detection/coverage: Vulnerability scanners can usually flag version exposure, but not exploitability of the specific WebRTC path. Browser crash telemetry and EDR child-process or memory-anomaly detections may catch unstable attempts.
STEP 03

Escape renderer constraints to reach durable host impact

Chrome on Linux uses a multi-process architecture and layered sandboxing specifically because renderers process untrusted input and are expected to be compromise-prone. That means the CVE's practical impact in many environments starts inside a sandboxed renderer context, and durable host takeover may require an additional sandbox bypass, policy weakness, or post-exploitation path. This is the single biggest downward pressure on severity for defenders scheduling patches.
Conditions required:
  • Successful memory corruption and code execution in the affected process
  • A path from compromised browser process to host-level objectives
Where this breaks in practice:
  • 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-sandbox are a minority but are higher risk
Detection/coverage: Look for Chrome/Chromium spawning shells, downloaders, unusual interpreters, or writing executables in user-writable paths. chrome://sandbox can help spot weakened local browser sandbox posture during triage.
STEP 04

Monetize the foothold

If the exploit chain is reliable enough, the attacker can steal session material, pivot into developer credentials, or chain local privilege escalation. On Linux developer/admin endpoints, the blast radius can be meaningful because those users often hold cloud, CI/CD, and SSH secrets. That said, this is still a subset-of-a-subset problem, not an estate-wide remotely reachable platform collapse.
Conditions required:
  • Compromised user has access to valuable tokens, code, or admin workflows
  • Follow-on controls do not stop persistence or lateral movement
Where this breaks in practice:
  • 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
Detection/coverage: Focus on browser token access, unusual Git/SSH activity, cloud CLI use, and secret-store access immediately after suspicious browsing events.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found in reviewed sources, and no CISA KEV listing was found for this CVE.
Proof-of-concept availabilityNo public functional PoC located; Chromium issue 504551032 appears restricted, which is typical during patch rollout.
EPSS0.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 statusNot KEV-listed as of the reviewed sources.
CVSS vectorCVSS: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 versionsPublished CVE/NVD text says Google Chrome on Linux prior to 148.0.7778.179.
Fixed versions / backportsGoogle'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 dataThis 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 date2026-05-20 in the CVE/NVD record; Google's stable desktop update post is dated 2026-05-19.
ReporterGoogle's advisory says the issue was reported by Google on 2026-04-20.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.4/10)

The decisive downgrade factor is that this is a Linux-only, user-driven client exploit path, not an unauthenticated server-side exposure. Without KEV, campaign reporting, or a public PoC, the reachable population and observed attacker pressure are too narrow to justify a HIGH enterprise patch emergency.

HIGH The vulnerability is real and affects Chrome/Chromium Linux builds in the stated version range
MEDIUM The practical severity downgrade driven by attacker-position and exposure friction
LOW Exact Linux fixed-version string because the CVE text cites `.179` while Google's release post says Linux received `.178`

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.

05 · Compensating Control

What to do — in priority order.

  1. Inventory Linux Chrome and Chromium now — Use EDR, package inventory, or MDM to enumerate 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.
  2. Prioritize developer and admin Linux cohorts — Patch or isolate endpoints used for cloud administration, source-code access, CI/CD, and SSH first because those users carry the highest post-browser blast radius. Even without a mitigation SLA, these are the systems where interim containment buys the most risk reduction while you work inside the 365-day remediation window.
  3. Enforce browser auto-update and package provenance — Make sure fleet policy allows Chrome/Chromium updates and that distro-managed Chromium packages are pulling from supported security channels. Do this immediately as control hygiene; for MEDIUM, there is no mitigation SLA, but this is the lowest-friction path to staying inside the remediation window.
  4. Reduce hostile content reach — Apply or verify URL filtering, secure web gateway controls, and browser isolation for higher-risk Linux users to cut off the prerequisite of rendering attacker-controlled content. This is an interim risk reducer while you complete remediation within the 365-day window.
  5. Audit for weakened sandbox posture — Hunt for Linux Chrome launches with flags like --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.
What doesn't work
  • 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.
06 · Verification

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.

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

If you remember one thing.

TL;DR
Monday morning, scope Linux browser exposure first, not the whole enterprise: pull an inventory of Linux endpoints running Chrome/Chromium, sort out which ones are engineering/admin/high-value user systems, and verify whether they are below the vendor or distro fixed build. Because this is a MEDIUM reassessment, there is noisgate mitigation SLA here — no mitigation SLA — go straight to the 365-day remediation window — but do not read that as 'ignore it': knock out high-value Linux user cohorts early, then complete the rest inside the noisgate remediation SLA of 365 days while documenting the version-string discrepancy between .178 and .179 in your patch notes.

Sources

  1. Google Chrome Releases: Stable Channel Update for Desktop (May 19, 2026)
  2. NVD record for CVE-2026-9111
  3. CVE.org record for CVE-2026-9111
  4. Chromium Linux sandbox documentation
  5. Chromium Linux sandboxing overview
  6. Debian Security Advisory DSA-6287-1
  7. SUSE CVE page for CVE-2026-9111
  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.