On 2 October 2026 the security researcher David Buchanan published a photograph of a EuroMillions ticket whose Content Credentials say it was taken on the afternoon of 28 August, hours before that evening's draw, and the ticket in the photo shows the winning numbers. The claim signature validates. The trusted timestamp validates. Neither covers a single byte of the image, because the manifest declares one exclusion range that spans the entire file, and every C2PA verification tool he could find reported nothing unusual. The ticket is visibly edited, and he says so. The point is not lottery fraud. The point is that a green check answers the question "does this signature validate over what it says it covers", and the only question that matters is what it covers. This article explains the mechanism, what the specification already requires, what has changed in the verifiers since, and how to read a credential so the demo cannot fool you.
What exclusions are for
A C2PA manifest binds itself to the file through a data hash assertion. The assertion holds a hash of the file's bytes and a list of exclusions: byte ranges, each a start offset and a length, that are left out of the hash. The signer computes the hash over everything outside those ranges, signs it, and a verifier recomputes it the same way.
Exclusions exist for an honest reason. The manifest is embedded inside the file it describes, so the bytes of the manifest itself cannot be part of the hash that the manifest contains. Some formats add a second wrinkle. A PNG chunk carries a CRC32 checksum that has to be rewritten after the manifest is inserted, so those bytes change after signing and must sit outside the hash too. The specification also lets a signer exclude metadata sections, for example so a GPS location can be redacted later without breaking the signature.
The feature is sound when the excluded ranges are small, known and accounted for. The demo turned on the fact that nothing in the tools checked whether they were.
What the demo did
The manifest's data hash assertion lists a single exclusion: start 0, length 3,995,383. That is the size of the whole file. Everything is excluded, so the hash that remains is the SHA-256 of an empty input, which in the manifest reads 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=. Buchanan confirmed it by hashing nothing on the command line, and so did we.
The claim signature then signs that hash, correctly. The RFC 3161 timestamp countersigns the claim signature, correctly. The specification is precise about what a timestamp proves: that "the signature itself actually existed at a certain date and time". It dates the claim, not the pixels. With the pixels excluded from the claim, the timestamp dates a statement about nothing, and the image can be edited after the fact without touching either signature.
Two caveats from the author belong here, because they are easy to lose in the retelling. The timestamp authority was not attacked. He assumes it works as advertised, and the demo needs it to. And he did not time-travel. He photographed a real ticket and edited the numbers in after they were announced, which the metadata cannot see because the metadata is not looking.
Why the verifiers passed it
He dumped the manifest with the reference command-line tool and linked the image to the Content Authenticity Initiative's public verifier. His words: "as of today all the C2PA verification tools I can find don't flag anything as unusual." The reason is structural. A verifier recomputes the hash over the bytes the manifest tells it to hash, compares the result with the signed value, checks the signature and the certificate chain, and reports the outcome. Each step is right. None of them asks whether the set of bytes being hashed is a reasonable set of bytes to hash.
The fix is harder than it looks, and Buchanan is candid about that. His first draft said exclusions should be removed from the standard, and he withdrew it: formats like PNG need them. His final recommendation is to "carefully and explicitly specify which parts of a file are allowed to be excluded, for each supported file format", and to require verifiers to enforce that. A whole-file exclusion is the easy case to catch. A small exclusion placed over the part of a frame that matters is the hard one, and detecting that a partial exclusion hides a meaningful change is not trivial.
What the specification already says
This is where the story is more nuanced than "the standard has a hole". Version 2.4 of the C2PA specification, published in April 2026, already tells validators what an exclusion may contain. In the section on validating the asset's content, a validator shall ensure that the data inside the exclusion range holding the manifest store "consists of only the C2PA Manifest Store" plus clearly marked padding. If the validator "encounters any data other than what is permitted", the manifest "shall be rejected with a failure code of assertion.dataHash.mismatch". For JPEG the rule is concrete: the exclusion's length must match the total length of the APP11 segments that hold the manifest. Exclusions beyond the manifest store, the metadata ranges, are allowed and only earn the informational code assertion.dataHash.additionalExclusionsPresent.
So a conforming validator should have rejected the lottery ticket. The exclusion that contains the manifest store also contains four million bytes of image. The gap in October was between the text and the tools.
The tools have been moving. In September 2026 the maintainers of the reference library merged two fixes, one for detached manifests and one for embedded ones, that re-parse the asset, find where the manifest store actually sits, and reject a declared exclusion that does not match it, with the failure code the specification names. The second fix quotes the section above and was prompted by a different trick on the same feature: shrinking a signed manifest and filling the freed space inside the still-signed exclusion with renderable content. Whether the verifier in front of you carries those checks depends on which library version it runs, which is why Buchanan's "as of today" was the right phrasing and why "maybe they've introduced mitigations" is his closing note.
The metadata exclusions are the part the specification leaves open. A researcher team at UMBC, with Neal Krawetz among the authors, made that point in April 2026: the standard's integrity claim applies only to bytes outside the exclusion ranges, bytes inside them "can be modified without detection", and their example was the Pixel 10 Pro placing GPS data in an exclusion range so a false location can be inserted. They also found that nothing in the signed data references the timestamp, so a timestamp can be removed and replaced. The paper's recommendation is the same as Buchanan's from the other direction: protect the whole file, and bind the timestamp to the content.
The three claims a credential makes, after this
People read three things into a valid credential. Each survives this episode in a narrower form.
"The file is unchanged since it was signed." True for the bytes the hash covers, and for no others. With a whole-file exclusion, that is zero bytes. With metadata exclusions, it is everything except the ranges the signer chose, and the viewer rarely sees which ranges those were. The claim should read: the bytes inside the hash are unchanged, and here is the list of what was left out.
"The photo existed at this time." The timestamp dates the signature over the claim. It dates the pixels only when the claim's hash actually covers them, and even then the UMBC finding stands: the token is not bound into the signed data, so it can be swapped. Our guide to proving a photo existed on a date already treats the C2PA timestamp as one source among several. After this, it should be read as a timestamp on a claim whose coverage you have to check first.
"The camera took this." This is the second time in a year that a valid, camera-grade signature proved less than it appeared to. In September 2025 the Nikon Z6 III was made to sign an image it had not captured, and Nikon revoked every certificate it had issued. On 29 October 2026 Buchanan published a certificate that chains to Google's C2PA root, which sits on the official trust list, with the method withheld, and noted that the verification tools at the top of search results do not check revocation at all. The signature tells you which key signed. Whether the key was in a camera, and whether the camera was looking at a scene or a screen, is outside the signature.
None of this makes Content Credentials useless. A manifest with a known signer, a hash that covers the file, and an intact chain is a strong statement about history. It is a statement that has to be read, not a badge that can be trusted at a glance, and the reading has one new step.
How to read a manifest yourself
The step is to look at the exclusions. Open the data hash assertion, the one labelled c2pa.hash.data, and read its exclusion list. Then ask three questions.
Is there an exclusion whose length is the size of the file, or close to it? That is a signature over nothing, whatever the verifier says.
Is the hash value 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=? That is the SHA-256 of an empty input, and it means the same thing.
Are there exclusions beyond the one that holds the manifest? Each one is a range the signer chose not to vouch for. A metadata exclusion is normal and the specification allows it. An exclusion that lands inside image data is not, and a verifier that only prints an informational code will not stop you from missing it.
Our free Content Credentials Inspector shows the raw manifest, assertions included, so the exclusion list is one click away. We should be as plain about our own tool as about everyone else's: it runs the reference library in your browser, and the version it runs today was published in June 2026, before the September fixes. It will show you the exclusions. It will not, yet, refuse a whole-file exclusion on its own. We are updating it, and until then the list is yours to read.
What a RAW comparison does differently
A signature is a claim by a signer about a set of bytes. Everything in this article is about the gap between what the claim covers and what the reader assumed it covered. A RAW comparison closes that gap by not relying on the claim at all. The exported image is compared with the sensor data the camera recorded: noise that behaves like sensor noise, highlights that clip the way the sensor clips, a demosaic pattern that matches the colour filter array, structure that agrees between the two files. A credential that covers nothing changes that result not at all, because the result was never read from the credential.
That is the order Lumethic verification works in. Verify the content against the original first, then treat a signature as what it is, a record of who signed and when, read with its exclusion list open. The first checks are free and need no account.
Frequently Asked Questions
Can a valid C2PA signature be faked?
The signature in the October 2026 demo was not faked. It was real, correctly computed and correctly time-stamped, over a hash that excluded the entire file. The lesson is narrower and more useful than "C2PA is broken": a valid signature proves only that the bytes it covers are unchanged, and a manifest can declare that it covers almost nothing. Reading the exclusion list is how you find out.
Does a C2PA timestamp prove when a photo was taken?
It proves when the claim signature existed, on the timestamp authority's clock. That dates the image only if the claim's hash covers the image. In the demo it covered no bytes, so the timestamp dated a statement about nothing. Separately, the UMBC analysis found that the timestamp token is not bound into the signed data, so it can be replaced. Treat it as one dated source among several, not as a capture time.
What are C2PA exclusions?
Byte ranges, given as a start and a length, that the data hash assertion leaves out of the hash. They exist because the embedded manifest cannot hash itself, because some formats such as PNG rewrite checksums after signing, and because the standard allows metadata to be redacted later. The specification restricts what the manifest-store exclusion may contain. Other exclusions are permitted and only noted.
Why did the CAI verifier not flag the demo?
Because the tools available in early October checked whether the signature validated over the declared ranges, which it did, and not whether the declared ranges were permissible. The specification already required the second check for the manifest-store exclusion, and the reference library merged enforcement in September 2026. Whether a given verifier has it depends on the library version it runs.
How do I check an image for this?
Open the manifest in an inspector that shows the raw assertions, find c2pa.hash.data, and read the exclusions. A single exclusion as long as the file, or a hash equal to the empty-input SHA-256, means the signature covers nothing. Any exclusion inside image data is a reason to stop trusting the credential for that image.
Does this affect photos from signing cameras?
The exclusion flaw is about what a manifest declares, so any signer can produce such a manifest, including a compromised or misused camera key. A camera that follows the specification excludes only its own manifest store and, on some models, metadata ranges. The practical check is the same for every source: read the list.
