The C2PA Exclusion Range Flaw: Why Signature Verification Must Check Coverage

A common pitfall in signature verification is asking only "is the signature valid?" without asking "what exactly does the signature cover?" C2PA's exclusion range flaw puts this question in the spotlight: an attacker can craft a document whose signature still passes verification but actually protects zero bytes. Worse, the same pattern can be found in SAML and JWT implementations. Below we break this down across three layers: the vulnerability mechanism, the cross-protocol commonality, and a defensive checklist.

The Core of the Flaw: A Valid Signature Does Not Mean the Content Is Covered

The C2PA specification allows declaring "exclusion ranges" in the signature computation to skip certain byte intervals that should not be signed (such as placeholders or external references). The problem lies on the verification side: when a verifier only checks whether the cryptographic signature matches, without strictly checking whether the exclusion ranges cover the actual content, an absurd state arises — the signature is mathematically valid, but the number of bytes it covers is zero. In other words, an attacker declares the entire file as "excluded," the signature still passes verification, and the content is left entirely unprotected.

The danger of this flaw is that it bypasses the semantic layer of the trust chain. Traditional signature verification outputs a binary "pass/fail," but what security actually needs is "pass, and covered the expected payload." When a verifier lacks that second judgment, the signature mechanism degrades from integrity protection into a blank check that can be exploited at will.

C2PA (Coalition for Content Provenance and Authenticity) is an open technical standard for digital content provenance and authenticity, jointly promoted by organizations such as Adobe, Microsoft, and the BBC. It records the origin, edit history, and issuer of content by embedding a signed manifest in the file, and is commonly used to distinguish genuine captures from AI-generated or tampered media. A C2PA manifest is itself a CBOR structure containing assertions, credentials, and a signature block. Among these, the "exclusion range" is a field in the manifest that tells the verifier which byte intervals to skip when computing the signature hash — typical scenarios include placeholders that need later filling, external references, or the signature block itself. Because the signature hashes the result of "file bytes minus the exclusion intervals," once the exclusion intervals are maliciously expanded to cover the entire content, the hash input degrades to empty: the signature still passes mathematical verification, but no payload is actually protected. Understanding this data structure is a prerequisite for understanding the vulnerability.

Why SAML and JWT Cannot Escape It Either

According to security researchers' analysis, the same flaw pattern also exists in SAML assertions and JWT tokens. SAML's XML signatures support specifying the element range covered by the signature via XPath or ID references; JWT's JWS relies on base64url-encoded payload segments. Both share a common feature: the object of the signature operation is a "selected set of bytes," and verifiers often assume the selection logic is correct by default.

Once an attacker can influence the range declaration (for example, by injecting additional exclusion nodes or tampering with encoding boundaries), they may cause the signature to cover an empty or irrelevant segment while leaving the real privilege claims outside the protection. Multi-source analysis agrees that this is not an implementation oversight in some particular library, but a consequence of the "signature coverage range" metadata being underestimated in protocol design. Different sources phrase it slightly differently: some researchers emphasize inconsistent interpretation of range semantics by parsers, while others focus more on verification APIs lacking an explicit coverage-check return value. Both perspectives point to the same conclusion — ranges must be verified, not trusted.

SAML (Security Assertion Markup Language) is an XML-based standard for single sign-on and identity federation, widely used for enterprise SSO. SAML assertions are signed by the identity provider, and the service provider trusts the attribute claims within them after verifying the signature. XML Signature (XMLDSig) supports specifying the document fragment covered by the signature via the URI attribute of the Reference element, using ID references, XPath expressions, or XPointer to delimit the range. This flexibility is precisely the source of risk: if the verifier's parsing of the Reference URI is inconsistent with the business code's parsing of the assertion, an attacker can make the signature cover a harmless fragment while placing the real privilege claims outside the protection. This class of attack is known as XML Signature Wrapping. JWT (JSON Web Token), on the other hand, is defined by the JWS specification: the token is split into three base64url-encoded parts — header, payload, and signature — and the signature covers the ASCII bytes of "header.payload." JWT itself has no explicit concept of exclusion ranges, but inconsistent handling of base64url boundaries, trailing whitespace, or encoding variants by parsers can likewise create a discrepancy between what the signature covers and what is actually used. The commonality between the two is this: the signature protects "selected bytes," and the semantic correctness of the selection logic is often left unverified.

Defensive Checklist: Verify Which Bytes the Signature Covers

Elevating "coverage range" to a first-class citizen of the verification process is the most pragmatic remediation direction at present. The following checklist items can serve as implementation references:

• Explicitly parse range declarations: Fully parse exclusion ranges or reference ranges before verification, and reject empty ranges, overlapping ranges, and out-of-bounds ranges.
• Assert non-empty coverage: After the signature passes, additionally verify that the number of covered bytes is greater than zero and includes all critical fields (such as C2PA assertions, SAML Subject/Attribute, and JWT claims).
• Unify parsing paths: Signature verification and business logic reads must use the same set of parsing results, to avoid parsing-differential attacks where "verification sees A, usage sees B."
• Reject implicit defaults: Do not silently fall back to "sign everything" when a range declaration is missing, and do not leniently handle abnormal ranges.
• Cover malicious ranges in regression tests: Include constructed samples such as empty ranges, full exclusion, and overlapping exclusions in the test set; the verifier should fail consistently rather than pass.

The value of these checks goes beyond patching a single CVE. They advance signature verification from "cryptographically correct" to "semantically correct," which is precisely the security foundation that content credentials, identity assertions, and API tokens all depend on. For teams using C2PA for content provenance, or relying on SAML/JWT for identity authorization, it is time to check whether their verification paths really ask the question: does this signature cover what it claims to protect?

One-line Summary

C2PA's exclusion range flaw reveals the risk of a valid signature with zero coverage, and SAML and JWT are affected as well.

Paragraph Summary

The article analyzes the mechanism of the exclusion range flaw in the C2PA specification: verifiers only check whether the cryptographic signature matches, without checking the byte range the signature actually covers, so an attacker can declare the entire file as an excluded interval, making the signature mathematically valid while protecting zero content. This flaw pattern is not unique to C2PA — SAML's XML signature reference ranges and JWT's JWS encoding boundaries suffer from the same problem of "range declarations being trusted rather than verified." The root cause is that protocol design underestimates the semantic importance of the signature coverage range metadata, and verification APIs generally lack explicit coverage checks. The article concludes with a defensive checklist, including explicitly parsing range declarations, asserting non-empty coverage, unifying verification and business parsing paths, rejecting implicit default fallbacks, and incorporating malicious constructions such as empty ranges, full exclusion, and overlapping exclusions into regression tests.