A 0-click exploit chain for the Pixel 9 (Project Zero)

[Posted January 16, 2026 by corbet]

The Project Zero blog has a three-part series describing a working, zero-click exploit for Pixel 9 devices.

Over the past few years, several AI-powered features have been added to mobile phones that allow users to better search and understand their messages. One effect of this change is increased 0-click attack surface, as efficient analysis often requires message media to be decoded before the message is opened by the user. One such feature is audio transcription. Incoming SMS and RCS audio attachments received by Google Messages are now automatically decoded with no user interaction. As a result, audio decoders are now in the 0-click attack surface of most Android phones.

The blog entry does not question the wisdom of directly exposing audio decoders to external attackers, but it does provide a lot of detail showing how it can go wrong. The first part looks at compromising the codec; part two extends the exploit to the kernel, and part three looks at the implications:

It is alarming that it took 139 days for a vulnerability exploitable in a 0-click context to get patched on any Android device, and it took Pixel 54 days longer. The vulnerability was public for 82 days before it was patched by Pixel.

to post comments

Does Google Message underlie other Android SMS apps?

Posted Jan 16, 2026 6:02 UTC (Fri) by alison (subscriber, #63752) [Link] (1 responses)

Or do those of us who install alternatives avoid passing through it at all? Disabling audio attachments, if possible, sounds like a smart strategy. It's sad what a large fraction of vulnerabilities are due to obscure features that few users want.

Does Google Message underlie other Android SMS apps?

Posted Jan 17, 2026 3:52 UTC (Sat) by mrekow (subscriber, #179961) [Link]

The AOSP SMS app (used in some form by all "alternative" Androids) is separate, and to my knowledge does not automatically decode audio attachments (since it doesn't perform any audio transcription).

Google's business model

Posted Jan 16, 2026 8:39 UTC (Fri) by smurf (subscriber, #17840) [Link] (15 responses)

> The blog entry does not question the wisdom of directly exposing audio decoders to external attackers

Well of course not. The money grubbers at Google don't like that. Can't have anybody subverting marketing craziness.

These days, sensible people don't SMS/RCS messages any more, much less with sound bites attached. (a) because it's expensive while Signal is free, and (b) because SS7 is still insecure as heck. Worse, with ubiquitous auto-transcription the phisher doesn't even have to AI-replicate the voice of the purported sender any more.

But of course Google won't say that publicly. The carriers would roast them. De-emphasizing or even de-listing Pixels on their "get a 'free' phone with your 99-year slavery contract" pages would cost Google real money.

Google's business model

Posted Jan 16, 2026 9:03 UTC (Fri) by Wol (subscriber, #4433) [Link] (13 responses)

> These days, sensible people don't SMS/RCS messages any more

Afaik there is no problem with SMS. But "SMS" is like "SD Card" nowadays - it's a pretty safe bet that what advertises itself as an SD card is in fact something rather different - most SD cards are only 2GB and anything over 4GB can't be an SD card - I've forgotten what the real names are nowadays.

I'm quite happy with SMS (and p***ed off with Google for trying to force all messages over their alternative service which uses chargeable data not free texts) but MMS is a chargeable extra on my tariff, so I avoid it. I personally use email instead, because I'm forwarding a photo I took on the phone.

And as for those photos, likewise Google's habit of demanding to "back up your precious photos" - THEY'RE JUNK. I have a 24MP DSLR which takes much better photos - not least because as far as I can tell the phone and camera use different definitions of "pixel". The camera's much larger sensor has twice as many "pixels" as my 50MP phone from what I can tell, and it's a basic rule of physics that "a good big-un will always beat a good small-un".

Cheers,
Wol

Google's business model

Posted Jan 16, 2026 10:32 UTC (Fri) by rschroev (subscriber, #4164) [Link] (12 responses)

SD Standard Capicity (SDSC, 2 GB, originally called Secure Digital), SD High Capacity (SDHC, 32 GB), SD eXtended Capacity (SDXC, 2 TB), SD Ultra Capacity (SDUC, 128 TB).

With names like that I think it's perfectly to refer to all of them as SD cards in a general sense.

Google's business model

Posted Jan 16, 2026 11:39 UTC (Fri) by Wol (subscriber, #4433) [Link] (11 responses)

Which is fine until you actually want a *real* SD card. Having been in that position, it's a bit of a nightmare because nobody can understand what you're saying.

How does your hearer know whether you mean "That class of devices commonly referred to as SD cards", or "Those devices that actually comply with the formal SD specification"?

In this particular case, the OP was talking about "sending audio over SMS", so it's clear he wasn't actually talking about genuine SMS. But should he really have been saying "Don't use (genuine) SMS because those things that call themselves SMS but aren't can be abused"?

Cheers,
Wol

Google's business model

Posted Jan 16, 2026 16:18 UTC (Fri) by cloehle (subscriber, #128160) [Link] (10 responses)

Am I missing something or should this be pretty simple?
All cards with <2GB are SDSC and must be.
They should then be fully SD spec compliant (with all the peculiarities like byte-addressing).
There's no way for the 'newer' spec cards to have >2GB and all features are constrained by that?
(advertised) card capacity being the one characteristic about SD cards that is always available when purchasing this shouldn't really be an issue?

Google's business model

Posted Jan 16, 2026 16:32 UTC (Fri) by pizza (subscriber, #46) [Link]

> There's no way for the 'newer' spec cards to have >2GB and all features are constrained by that?

SD cards >= 2GB (ie gen2 and newer) use block addressing instead of byte addressing and are incompatible with hosts that only speak 1st-gen SD.

The different SD generations report different card info versions, so the old host is expected to safely reject any card with an unknown version.

Google's business model

Posted Jan 16, 2026 17:06 UTC (Fri) by Wol (subscriber, #4433) [Link] (8 responses)

The problem is when you go into a shop and ask for an SD card because you *MEAN* *SD* because that's all your device will accept.

The shop assistant can't understand why you don't want a 4GB card because "it's an SD card". Been there done that.

Even worse, I've had devices that actually want a "genuine SD" 4GB card. I believe the spec does actually permit that - it requires unsigned arithmetic - but (almost?) without exception every 4GB card I've seen was SDHC. Try explaining THAT to your typical shop guy who rarely has a clue about what he's selling!

Cheers,
Wol

Google's business model

Posted Jan 16, 2026 17:25 UTC (Fri) by pizza (subscriber, #46) [Link] (3 responses)

> I've had devices that actually want a "genuine SD" 4GB card. [...] I believe the spec does actually permit that

To quote the actual SD spec:

* Standard Capacity SD Memory Card (SDSC) supports capacity up to and including 2 G bytes (2^31 bytes). All versions of the Physical Layer Specifications define the Standard Capacity SD Memory Card.
* High Capacity SD Memory Card (SDHC) supports capacity more than 2 G bytes (2^31 bytes) up to and including 32 G bytes and is defined from the Physical Layer Specification Version 2.00.

According to the spec, there is no such thing as a "4GB SDSC" card.

Google's business model

Posted Jan 17, 2026 11:58 UTC (Sat) by smurf (subscriber, #17840) [Link] (2 responses)

> According to the spec, there is no such thing as a "4GB SDSC" card.

Nobody disputes that – but silly reasons like not-quite-adherence to some spec or other never stopped people from making semi-compliant gadgets. Like, ever.

At the time, when the SDHC standard was new and not quite well supported, these things did exist. I think I had one of them too.

Today, with less than zero market for these cards (given that in a SDHC-compliant host they'd probably advertise a capacity of either two or zero GBytes)? Not so much.

Google's business model

Posted Jan 17, 2026 12:10 UTC (Sat) by pizza (subscriber, #46) [Link] (1 responses)

> Nobody disputes that – but silly reasons like not-quite-adherence to some spec or other never stopped people from making semi-compliant gadgets. Like, ever.

Sure. But when that happens they get to keep the pieces when things inevitably break.

And deliberately seeking out something that intentionally non-spec compliant tends to not go well.

Google's business model

Posted Jan 17, 2026 13:05 UTC (Sat) by Wol (subscriber, #4433) [Link]

The device in question was a Garmin Satnav, which took SDSC cards. When the map data went over 2GB you were supposed to use a 4GB card ...

Not so bad in that they said the largest card my Father-in-law's Olympus would support was 128MB, I wanted to put a bigger one in, and it clearly could not address all the available memory. Quite why they limited the camera (or card, I think it was an MMC) to 128MB I don't know.

Nowadays, of course, capacity is so huge it's hard to fill up a chip (my DSLR has 100GB, which it tells me is enough for 1100 photos - I can't see me getting through that in a day out ...) but back then I wanted to make sure their cameras had a decent amount of storage ...

Cheers,
Wol

Google's business model

Posted Jan 16, 2026 17:39 UTC (Fri) by iabervon (subscriber, #722) [Link]

I could see devices wanting a "genuine SD" card in the sense that it supports the DRM extensions relative to MMC, and actually wanting it to conform to a standard from the SD Association that isn't their first one.

Google's business model

Posted Jan 16, 2026 19:10 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (1 responses)

Y'know, Microsoft had a long-running habit of referring to UTF-16 as "Unicode," because a long time ago, that was the standard terminology.

It isn't anymore.

Language changes over time. If you want an "SD card" that conforms to the original standard, you're just going to have to ask for an SDSC card. If you want a card that does not conform to the standard (by using unsigned arithmetic where the standard specifies otherwise), then you're probably out of luck.

Google's business model

Posted Jan 19, 2026 9:59 UTC (Mon) by taladar (subscriber, #68407) [Link]

Technically most of the time they also refer to UTF-16 when they actually means UCS-2

Google's business model

Posted Jan 16, 2026 20:49 UTC (Fri) by rschroev (subscriber, #4164) [Link]

Then you specify that you need an SDSC (SD Standard Capicity) card, because that unambiguously refers to the max 2 GB type of cards.

Google's business model

Posted Jan 21, 2026 4:30 UTC (Wed) by dvdeug (subscriber, #10998) [Link]

Sensible people? I have a text message chain I'm on, I have people who communicate on Discord, and I have a few people who message me on Facebook Messenger. Nobody has ever said contact me on Signal. Messenging apps are the biggest place where if you don't have the critical mass, you don't have anything, and sensible people aren't going to try and fight friends and family into using Signal or whatever the new secure hotness is.

Darwin keeps having fun

Posted Jan 16, 2026 13:57 UTC (Fri) by alx.manpages (subscriber, #145117) [Link] (1 responses)

Ain't it beautiful how natural selection still applies even in highly artificial scenarios?

People who follow the shiny AI lights will burn.

Darwin keeps having fun

Posted Jan 16, 2026 17:18 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]

In fairness, voice to text is an area where "AI" models are amazingly good. The voice transcription on my phone is almost as good as a trained stenographer. It has a good enough grammar engine that it can guess which homophone I'm using from context, can tell when I'm using a word as a word and when I'm telling it to add punctuation, etc. The only areas where it really needs work are things like names and technical terms that probably aren't well represented in its corpus.

Sandboxing?

Posted Jan 16, 2026 22:31 UTC (Fri) by josh (subscriber, #17465) [Link] (2 responses)

It genuinely astonishes me that this wasn't running in a sandbox. Any kind of image/audio/video decoder in a context exposed directly to random untrusted content should be running in a sandbox that has zero access to anything other than the codec data. Not just SELinux like everything else; it should be running in a strict seccomp sandbox. As far as I can tell from reading part 1 of the series, this wasn't.

Sandboxing?

Posted Jan 16, 2026 23:35 UTC (Fri) by excors (subscriber, #95769) [Link]

I think that's not possible because of hardware decoders, which need access to more than just the media bitstream. In this case there's a driver at /dev/bigwave that accelerates some AV1 decoding, so that has to be accessible from the mediacodec process. The vulnerable UDC codec runs in the same mediacodec process, and there's a separate vulnerability in /dev/bigwave that allows arbitrary writes to kernel memory, and the two exploits can be chained together.

They say the mediacodec process does have a seccomp policy on many Android devices, but not on Pixel 9 for unknown reasons. But they don't think that would have prevented the exploit, it would have just required a few more weeks of effort.

Sandboxing?

Posted Jan 17, 2026 15:32 UTC (Sat) by paulj (subscriber, #341) [Link]

The decoder _is_ running in a sandbox. They used the decoder bug to then deliver /another/ exploit for the kernel driver for the "BigWave" hardware AV1 decoder - which is accessible from the 'mediacodec' sandbox used for decoding media (though, doesn't seem like this driver was necessary for /particular/ decoder involved in the initial attack). They quickly found 3 different exploitable bugs in said driver, so.. spoiled for choice there.

So, exploit the sandboxed media decoder to deliver the exploit for the hardware decoder acceleration driver -> code execution in kernel -> game over.

Isn’t the title misleading?

Posted Jan 17, 2026 1:05 UTC (Sat) by mirabilos (subscriber, #84359) [Link] (3 responses)

Should it not be:

| A 0-click exploit chain for Google Messages on the Pixel 9

Given it exploits merely a software in the stock ROM, not the device itself (e.g. with GrapheneOS).

Isn’t the title misleading?

Posted Jan 17, 2026 3:57 UTC (Sat) by mrekow (subscriber, #179961) [Link] (2 responses)

Most people using a Pixel 9 will be using a stock ROM, so I think the title is fine in this instance (applying to the majority of users).

Isn’t the title misleading?

Posted Jan 17, 2026 4:48 UTC (Sat) by mirabilos (subscriber, #84359) [Link] (1 responses)

I have the impression that 100% of all GrapheneOS users, and a vast majority of AOSP-based ROM users, acquire Pixel phones, so I doubt that.

Isn’t the title misleading?

Posted Jan 17, 2026 9:43 UTC (Sat) by smurf (subscriber, #17840) [Link]

"Most A do B" does not magically follow from "Almost all B do A".

/self/proc/mem

Posted Jan 17, 2026 5:15 UTC (Sat) by cypherpunks2 (guest, #152408) [Link] (2 responses)

> This syncframe uses DYNAMIC WRITE FAST to write ‘wb’ and “/self/proc/mem” to the address above, so they are available as parameters for a future fopen call, then moves the skip pointer to dynamic_base + 0xD000, so they aren’t immediately corrupted.

> Likewise, the accessibility of /self/proc/mem was a big shortcut to exploitation. Since it is only used during debugging, I wonder if it is possible to implement some sort of mitigation that makes it inaccessible when a device is not being debugged.

I assume they mean /proc/self/mem? I wonder how they made that kind of mistake twice.

/self/proc/mem

Posted Jan 20, 2026 9:25 UTC (Tue) by evomassiny (subscriber, #161550) [Link] (1 responses)

Same for the pseudo-code,
i believe:
```
if ( total_size % 8 )
total_size += (8 - total_size) % total_size;
```

should be:
```
if (total_size % 8)
total_size += 8 - (total_size % 8);
```
otherwise i don't understand what would be the intention

/self/proc/mem

Posted Jan 20, 2026 11:53 UTC (Tue) by excors (subscriber, #95769) [Link]

I can't find the ddp_udc_int_evo_malloc symbol in Pixel 9's libcodec2_soft_ddpdec.so (maybe it was inlined or something); but the original bug report says the vulnerable code is present on MacOS, and a GitHub search shows the symbol exists on iOS (which is probably similar to MacOS), so I guess they decompiled it from MacOS rather than Android.

The iOS decompilation is effectively:

total_size = (alloc_size + extra + 7) & ~7;
if (does_add_overflow(alloc_size, extra) || heap->remaining < total_size) { return 0; }

which makes more sense - it's simply rounding up to 8 bytes, and the bug is that it's only testing for overflow in the non-rounded-up addition. Perhaps the post author tried to paraphrase the decompiled code to avoid the slightly obscure bit-twiddling, or used a different decompiler that produced uglier code they needed to clean up, but they made a mistake. Their rest of their explanation of the overflow sounds fine.

(They say the overflow is present on iOS but not exploitable because the library is built with -fbounds-safety.)