Researcher breaks C2PA photo credentials on Android, Google won't fix

Security researcher David Buchanan published a report on 25 August 2026 saying that Android phones can be made to sign fake photos as if a real camera took them. That breaks the one promise the technology exists to make. Google reviewed his findings, paid a $7,500 bug bounty, and closed the report as "Won't fix (infeasible)."

The technology is C2PA, short for the Coalition for Content Provenance and Authenticity. It attaches a signed record to a photo, called a Content Credential, saying which device or app produced it. The point is to tell a real camera photo apart from an image a generative AI model made up. Buchanan's conclusion is blunt: "C2PA on the Android platform is broken, in a way that cannot be realistically patched."

What Google said its Pixel implementation guaranteed

Google announced Pixel 10 as the first phone line with Content Credentials in every photo, in a post dated 10 September 2025 by Eric Lynch and Sherif Hanna. The post says Pixel Camera reached "Assurance Level 2, the highest security rating currently defined by the C2PA Conformance Program."

Google's post describes a chain of hardware checks behind that rating. Android Key Attestation proves a signing key was made inside a protected chip. The Titan M2 security chip stores the key so software cannot read it. Remote Key Provisioning hands out certificates only to what Google calls a "Play Protect Certified version of Android." A clock inside the Tensor G5 chip timestamps photos even with no network. Google also uses what it calls a "One-and-Done" strategy, where each key signs exactly one image, so two photos cannot be linked to the same phone.

Where the chain came apart

Buchanan targeted the attestation step, not the key storage. His report says Android Key Attestation and Google Play Integrity can both be defeated. A compromised phone can therefore still convince Google's servers it is trustworthy, and collect a valid signing certificate. Two separate attacks did it.

The first is software. Buchanan reports that a one-click root exploit, tracked as CVE-2026-43499, defeats the attestation check. The phone is fully compromised and still passes as trustworthy. The second attack is hardware fault injection: electromagnetic glitching aimed at the phone's DRAM memory to make the chip misbehave at a chosen moment. Buchanan reports bypassing the StrongBox hardware security module this way.

Device tested	Method reported
Pixel 8a	software root exploit
Pixel 9a	Root-My-Pixel one-click root
Samsung A07	attestation bypass
Amazon Fire TV Stick	attestation bypass
Meta Quest 3S	attestation bypass

The software hole can be patched. The hardware one is the reason Buchanan says the problem is permanent. Glitching a memory chip is a physical attack on silicon that is already in people's hands, and no software update changes the silicon. That is the gap behind Google's "infeasible" verdict.

Note where the failure sits. Both attacks aim at the checks that decide whether a phone deserves a certificate at all. A phone that should not qualify can have a legitimate key issued to it, and can then sign whatever it likes.

What this means for developers

Treat a valid Content Credential as evidence about software, not proof about reality. It tells you a signature verified against a certificate chain. It does not tell you a camera pointed at a real scene. If you are building a claims pipeline, a newsroom tool, or a marketplace that checks uploads, do not write code paths that auto-approve an image because the credential passed. Keep the manual review step you were planning to remove.

Check what your verification library actually reports. Assurance Level 2 is a statement about the capturing app's conformance, not about the scene. Surface the level and the issuing certificate in your own logs and UI, rather than collapsing everything into a boolean. A reviewer who can see "Pixel Camera, Assurance Level 2" can weigh it. A reviewer who sees only a green check cannot.

The asymmetry is worth planning around. C2PA is still useful in the negative direction: a missing or invalid credential is a real signal that something was stripped, edited, or generated. A present and valid one now has a known ceiling on what it proves. Rank your trust signals accordingly and keep at least one that does not depend on the device being honest, such as provenance you recorded yourself at upload time.

Finally, watch the disclosure outcome as much as the exploit. Google paid the bounty and declined the fix, which is an honest answer rather than a denial, and it tells you the standard's threat model assumed hardware that holds. If your product roadmap has "verify with Content Credentials" written on it as a trust milestone, that line needs rewording before it ships.