Chromium Hides in More Than Your Browser

An actively exploited Chromium sandbox escape is in the wild. Updating Chrome isn't enough — here's every place Chromium secretly lives.

Share

An actively exploited sandbox escape affecting all Chromium versions is topping security feeds this morning — CVE-2026-85046. The reflex move is updating Chrome and closing the ticket. On a typical dev machine, that patches maybe a third of the Chromium copies actually running on it.

The engine also ships inside chat apps, scraping fleets, and CI base images — places that never auto-update. Patching only the browser is partial containment of a bug someone is exploiting right now.

Why this matters

Chromium's security model assumes the renderer loses. Tabs parse untrusted HTML, JavaScript, and image codecs inside a sandboxed process stripped of OS capabilities — enforced with seccomp-bpf on Linux, seatbelt on macOS, restricted tokens on Windows.

A sandbox escape breaks that contract. A hostile page graduates from "compromised tab process" to "arbitrary code running as your user": SSH keys, session cookies, source trees, cloud credentials. And a scraping fleet points that exposure at attacker-controlled pages on purpose, at scale.

How it works

Chromium splits into a privileged browser process and untrusted renderer processes. The sandbox boundary is the interesting part: renderers request everything through an IPC broker that is supposed to validate each message before acting on it with real privileges.

Escapes classically live right there — an IPC handler trusting malformed input, a gap in the OS sandbox policy, a syscall the filter should have blocked. One renderer bug plus one escape bug equals code execution from a single page load. Whatever the specifics of this CVE turn out to be, the response is the same.

Where this helps

  • Fleet machines. Verify versions instead of assuming auto-update won. Distro-packaged Chromium on Linux lags Google's repo badly.
  • Headless fleets. Playwright and Puppeteer pin browser builds into caches and Docker images. Rebuild images, re-run npx playwright install.
  • Electron apps. Slack, VS Code, Discord, and internal tools each bundle their own Chromium, patched only when the vendor ships.
  • Anything running --no-sandbox. Kiosks and legacy Docker setups had no wall to escape from. Treat them as already exposed.

Watch out

  • "All Chromium versions" includes Edge, Brave, Opera, and Vivaldi — forks patch on their own schedules.
  • Electron backports security fixes into patch releases, but vendors must adopt them. Stale apps stay stale for months.
  • Site Isolation contains renderer bugs, not broker escapes. It is not a mitigation here.
  • Android WebView updates through system channels — don't forget phones in the field.

Try it yourself

Inventory every Chromium engine on a machine in one pass:

# Browsers that self-update — verify anyway
for b in google-chrome-stable chromium chromium-browser msedge brave-browser; do
  command -v "$b" >/dev/null && "$b" --version
done

# Copies that never auto-update: Electron apps, Playwright, Puppeteer caches
find /usr /opt /snap "$HOME/.cache/ms-playwright" "$HOME/.cache/puppeteer" \
  -maxdepth 3 -type f \( -name chrome -o -name chromium -o -name headless_shell \) 2>/dev/null |
  while read -r bin; do
    printf '%s -> %s\n' "$bin" "$(strings "$bin" | grep -om1 'Chrome/[0-9]*')"
  done

Anything the script finds with an old Chrome/NNN stamp is a copy nobody is patching for you.

TL;DR

  • An actively exploited sandbox escape affects all Chromium versions (CVE-2026-85046).
  • Renderer bug plus escape equals code execution as the user — and most Chromium copies never auto-update.
  • Today: run the inventory, patch browsers, rebuild CI images, update Electron apps.