Two bugs, zero taps: Pixel 10 to root through Dolby decoder

Two bugs. No tap, no click, no “you have a new message” that anyone had to open. Project Zero’s writeup walks a Pixel 10 from a completely idle state to root using an initial flaw in a Dolby media component and a second bug to climb out of the sandbox. Google patched the entry point in the January 2026 security bulletin. That was eight months ago. Which is the whole problem.

The mechanism is the boring, familiar one: an audio/video stream gets handed to a Dolby decoder that runs automatically as part of media processing — no user interaction, because parsing untrusted media is exactly the thing phones do without asking. Memory corruption in the decoder gives code execution inside a constrained media sandbox. On its own, that’s contained. The second bug is what turns a contained crash into a compromise, pivoting out of the sandbox toward root. Read the writeup for the exact escalation primitive before you quote it — the entry vector is the part every defender needs to internalise, and it’s the part that generalises to devices Google doesn’t ship.

Here’s what the vendor framing quietly steps around: this is a media-parser attack surface, and media parsers are not a Pixel-exclusive problem. Project Zero’s writeup is about a specific bug in a specific component on Google’s devices — it does not hand you a list of other OEMs shipping the same vulnerable code, so don’t repeat one that isn’t there. But the class is everywhere. Every Android OEM runs codecs that auto-process untrusted media, and their patch cadences are not Google’s. Whether Samsung, OnePlus or Motorola carry this exact flaw is a question to answer per-vendor against their own bulletins — not an assumption to make. So the job isn’t “did Google patch it.” It’s the list below, in order.

  1. Confirm the security patch level on every Pixel 10 you own. Not the Android version — the patch string. Check the exact string Google’s January 2026 bulletin publishes for the fix and treat that date as your floor; Android exposes it as ro.build.version.security_patch in YYYY-MM-DD form. Anything behind that floor is exposed to a publicly documented zero-click chain, and “public” now means the exploit techniques are teaching material.
  2. Audit the whole fleet, not the phone on your desk. Your own device is patched because you’re the kind of person reading this. The 400 handsets in field ops are the risk. Pull patch levels programmatically and treat anything behind the January 2026 floor as a finding, not a nag.
  3. Chase the non-Pixels on the class, not the CVE. This is where six-months-from-now bites you. Other OEMs run the same category of auto-processing media decoders and patch on their own schedules. Map which vendors are in your fleet, find each one’s current bulletin, verify whether their media stack is up to date, and stop assuming “latest Android version” equals “patched.” It doesn’t.
  4. Shrink the zero-click surface where you can’t patch fast. For managed devices, disable auto-download of media in messaging apps and RCS where the workflow tolerates it. It’s a compensating control, not a fix — it removes the “arrives and processes itself” property that makes zero-click zero-click.
  5. Set the compliance floor in your MDM. Push a minimum-patch-level policy in Intune / your EMM so devices behind the January 2026 floor lose access to corporate resources until they update. Reporting finds the gap; policy closes it.

Here’s a report-only sweep over anything reachable via adb. Set THRESHOLD to the exact patch string from Google’s January 2026 bulletin — the comparison is lexicographic, so any later date reads as current. No changes made:

run.shbash — zsh
#!/usr/bin/env bash
# Report-only: flag Android devices behind the Jan-2026 patch floor.
# Set THRESHOLD to the exact ro.build.version.security_patch string
# from Google's January 2026 bulletin before trusting the output.
THRESHOLD="2026-01-01"for serial in $(adb devices | awk 'NR>1 && $2=="device"{print $1}'); do
  patch=$(adb -s "$serial" shell getprop ro.build.version.security_patch | tr -d '\r')
  model=$(adb -s "$serial" shell getprop ro.product.model | tr -d '\r')
  if [[ "$patch" < "$THRESHOLD" ]]; then
    echo "EXPOSED  $serial  $model  patch=$patch"
  else
    echo "ok       $serial  $model  patch=$patch"
  fi
done

For enrolled fleets, don’t do this by hand — query the patch level through your MDM’s device inventory (Intune surfaces it as the Android security patch level per device) and build the below-January-2026 filter into a dynamic group.

Urgency: for Pixel 10 specifically this is confirm-and-move-on — a device on the January 2026 patch floor or later is not vulnerable to this chain. And keep the threat model honest: this is Project Zero research, a disclosure writeup, not an incident report — treat it as a documented capability, not a claim of active exploitation, and don’t manufacture a breach the source doesn’t describe. The real work is this week, and it’s the fleet audit, especially the non-Pixel OEMs whose media decoders sit on their own patch schedules.

Zero-click doesn’t mean sophisticated. It means the attack surface answers the door by itself. Media parsers have been that door for a decade, and we keep acting surprised when someone knocks.