David Buchanan published a demonstration on August 25 in which a generated image carried a valid Pixel Camera Content Credential: signer Pixel Camera, Assurance Level 2, file unaltered since signing.[1] The checker confirmed what it was built to confirm, that a trusted camera-app key signed a hashed manifest, not that a sensor captured the scene.
He had reported the issue to Google's Vulnerability Reward Program at least ninety days earlier. Google paid $7,500 and closed the report as "Won't fix (infeasible)."[1]
Buchanan's point is about who can ask the chip to sign. "an attacker does not need the raw key material! As root, they can ask StrongBox to use these keys to sign whatever data they like, and produce C2PA forgeries."[1] The Titan M2 still holds the key, and the key does not leave the chip. Root on the phone can still request a signature for a file the camera sensor never saw, and StrongBox will sign it so the credential verifies.
Google already wrote, in the Pixel Camera post, that "the security of any claim is fundamentally dependent on the integrity of the application and the OS, an integrity that relies on both being kept current with the latest security patches."[2] The same post said Content Credentials "are not the sole solution for identifying the provenance of digital media."[2]
The rating still matters. Google wrote that "The Pixel Camera app achieved Assurance Level 2, the highest security rating currently defined by the C2PA Conformance Program. Assurance Level 2 for a mobile app is currently only possible on the Android platform."[2] AL2 describes how the key is stored and how the certificate chain is formed. It does not describe whether the bytes being signed came from the image sensor.
Buchanan adds another cut. If the operating system is compromised without unlocking the bootloader, attestation can still look like a genuine, patched device even when the chain looks clean. His summary: "C2PA on the Android platform is broken, in a way that cannot be realistically patched."[1] Google's VRP note, as he quotes it, treats hardware glitching and side-channel attacks as out of scope while thanking him for the research.[1] The path he documented for the software case does not depend on glitching the hardware.
NVD independently lists CVE-2026-43499 as a Linux kernel use-after-free (CWE-416), published May 21, 2026 and last modified August 22. CISA's SSVC recorded exploitation as "poc" on August 21.[3] Buchanan's claim that a one-click in-the-wild root exists for fully patched Pixel phones is his. This review did not reproduce the demonstration.
C2PA's own explainer already draws a tighter line than a green checkmark: "Content Credentials do not provide value judgments about whether a given set of provenance data is 'true', but instead merely whether the provenance information is well-formed and free from tampering, valid and trusted (in that the signer of the Content Credential is associated with a known trust list)."[4] A credential is a signed, hashed manifest. Change the file after signing and the hash should fail. The credential does not inspect the world before the signing event.
The August 11 piece The Label Is a Clue followed generation-side marks: watermarks and metadata that travel with model output.[5] Camera credentials sit on the capture side. The two records can live on the same file and still answer different questions.
After a Pixel Camera credential passes, a verifier can still say the file has not been modified since that key signed it, the signer is associated with Pixel Camera, and the implementation was certified at Assurance Level 2. The verifier cannot say a sensor captured the scene. Dedicated cameras and newsroom-managed capture pipelines sit in a different threat model. Buchanan's finding is about the Android software path. It does not automatically travel to every signed photograph.
Verification bottleneck
A green camera credential currently answers a signer-and-integrity question, and most tools stop there.
- Most current checks stop at credential validity: signature, hash, trust-list signer. Whether the signer had any contact with a sensor is a second question, and it is rarely on the same screen.
- Assurance Level 2 describes key protection and certificate issuance. It does not describe the gate between the sensor and the signing request.
- Standard C2PA displays do not surface attestation freshness or patch state. A device can carry an AL2 rating and still be running a kernel with a public proof-of-concept path.
- The scarce skill is reading a capture credential as signer-and-integrity evidence. Scene-presence is a separate claim, and the two currently look the same in most tools.
Opportunities
Newsrooms and platforms that already accept camera credentials in intake have a paperwork gap. A capture-credential review sheet can record signer identity, trust-list status, assurance level, whether a revocation check ran, and a standing field for what the credential does not attest. That last field is missing from a lot of existing checklists. Idea fodder only. Not advice.
C2PA toolmakers have a smaller version of the same job. The specification already separates well-formedness from truth. Putting "what this credential does not prove" next to the green check is an interface choice. It does not require a new standard.
A signed hashed manifest still binds a signer to a file. The open work is teaching reviewers what that binding is, and what it leaves out.
Sources
[1] David Buchanan, C2PA Cameras Do Not Survive Contact With Reality, August 25, 2026
[3] National Vulnerability Database, CVE-2026-43499
[4] C2PA, C2PA and Content Credentials Explainer (specification 2.2)
[5] Hypernovelty Institute, The Label Is a Clue, August 11, 2026