Adobe C2PA Tool (c2patool / c2pa-rs, Content Authenticity Initiative)
By Adobe Bug bounty on Sorona
- Top reward
- $10,000
- Top severity paid
- Critical
- Assets in scope
- 9
- Public CVEs
- 34
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays up to $10,000
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Payment
- Proof of identity needed to get paid.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical |
|
$10,000 from $5,000 |
| High |
|
$5,000 from $1,000 |
| Medium |
|
$1,000 from $200 |
| Low |
|
$200 from $100 |
- Safe harbor
-
Partial
Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
9 assets you may test, 7 excluded.
Web 1
- https://github.com/contentauth/c2patool
Products and areas 8
- Assertion and binding handling: hard bindings, data hashes, box hashes and the ingredient chain that ties a derived asset back to the ones it came from
- c2pa-rs, the Rust library c2patool is built on, where parsing, signing and validation actually happen and which every invocation of the tool reaches
- Manifest ingestion from attacker-supplied assets: the JUMBF boxes and embedded manifest stores carried inside image, video and audio containers, decoded before anything has been authenticated
- Signature and certificate-chain verification, trust-list handling and timestamp checking, the decisions that end in a manifest being reported as valid
- The HackerOne asset row "C2PA Tool", marked eligible for bounty, which Adobe's policy points at as "the c2patool (https://github.com/contentauth/c2patool) located in the Content Authenticity GitHub project". The same row spans the hosted Content Credentials Verify site alongside the open-source tooling
- The hosted Content Credentials Verify site, which the asset row covers alongside the tooling
- The policy's own statement of what it accepts at code level: "Failures to properly detect invalid, untrusted, or tampered C2PA manifests under default configurations", and "Other security issues directly related to C2PA metadata processing or verification"
- The writing side as well as the reading side: signing, manifest embedding, resource extraction and the files the tool produces when it creates or updates a credential
Out of scope (7)
- Adobe's other products, which sit on other asset rows of the same HackerOne program rather than on this one
- Anything that only reproduces under a non-default configuration, since the in-scope wording is anchored to default configurations
- Denial of service and memory exhaustion driven by large inputs, which the policy places out of scope outright
- Enforcement of the CAWG X.509 trust model, also recorded as not currently accepted
- Network access triggered by C2PA manifest input, which the policy records as not currently accepted while mitigations are in progress
- Payment gates that apply across the Adobe program: identity verification before a payout is released, and the stated requirement to "provide your Testing IP address" in order to receive a monetary payout where that applies
- "Use of unsupported platforms, unreleased versions, or non-standard build processes", quoted from the policy's out-of-scope list: build it the way the project builds it
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.
While testing
-
Submit through sorona.xyz first.
-
Show the failure under a default configuration
-
Network access triggered by C2PA manifest input is recorded as not currently accepted
-
Enforcement of the CAWG X.509 trust model is likewise recorded as not currently accepted
-
Build and run against a supported platform and a released version using the project's standard build
-
Identity verification is required before Adobe releases a payout; there is no submission fee
-
Report to Adobe through HackerOne first
Not accepted
-
Network access triggered by C2PA manifest input
-
Enforcement of the CAWG X.509 trust model
-
Denial of service and memory exhaustion driven by large inputs
-
Anything that only reproduces under a non-default configuration
-
Use of unsupported platforms, unreleased versions, or non-standard build processes
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
Sorona credits this project with 34 CVEs, 34 of them recent. The individual records appear here after the next sync.
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
Skip to content What this pays sorona.xyz pays 1.25× the program's reward, up to +$1,000 per finding, plus a complexity bonus of up to $1,000 for especially complex or well-chained bugs. Finding │ Program pays │ Through sorona.xyz Critical (CVSS 9.0 - 10.0), Tier 1 range; on a Tier 2 product the same band pays $2,500 - $5,000 │ $5,000 - $10,000 │ $6,000 - $11,000 High (CVSS 7.0 - 8.9), Tier 1 range; on a Tier 2 product the same band pays $500 - $2,500 │ $1,000 - $5,000 │ $1,250 - $6,000 Medium (CVSS 4.0 - 6.9), Tier 1 range; on a Tier 2 product the same band pays $100 - $500 │ $200 - $1,000 │ $250 - $1,250 Low (CVSS 0.1 - 3.9), Tier 1 range; on a Tier 2 product the same band pays up to $100 │ $100 - $200 │ $125 - $250 Submit a vulnerability CVE history 34 Last 12 months 34 Lifetime Latest advisories Loading the feed Overview C2PA is the provenance standard behind Content Credentials: a signed manifest travelling inside an image, video or audio file that records what device or tool produced it and what was done to it since. c2patool is the command-line reference implementation the Adobe-led Content Authenticity Initiative publishes, and c2pa-rs is the Rust library underneath it that does the actual parsing, signing and validation, the same code path that camera firmware, editing tools and platform verification pipelines lean on when they decide whether a credential is genuine. That is why a bug here is unlike a bug in most parsers: the entire value of a Content Credential is that a tampered manifest fails to verify, so a validation bypass does not leak data, it silently converts a forgery into an authentic-looking provenance chain. Adobe covers this asset on its public bug bounty and pays cash: $5,000 to $10,000 for a Critical down to $100 to $200 for a Low on the Tier 1 range, with Adobe not publishing which tier this asset sits in, on a Tier 2 product the same bands run $2,500 to $5,000 down to $100. The policy names two classes it is explicitly not accepting right now, network access triggered by manifest input and enforcement of the CAWG X.509 trust model, so read those before you spend time on either. sorona.xyz adds 1.25× on top of whatever Adobe awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. In scope The HackerOne asset row "C2PA Tool", marked eligible for bounty, which Adobe's policy points at as "the c2patool (https://github.com/contentauth/c2patool) located in the Content Authenticity GitHub project". The same row spans the hosted Content Credentials Verify site alongside the open-source tooling The policy's own statement of what it accepts at code level: "Failures to properly detect invalid, untrusted, or tampered C2PA manifests under default configurations", and "Other security issues directly related to C2PA metadata processing or verification" c2pa-rs, the Rust library c2patool is built on, where parsing, signing and validation actually happen and which every invocation of the tool reaches Manifest ingestion from attacker-supplied assets: the JUMBF boxes and embedded manifest stores carried inside image, video and audio containers, decoded before anything has been authenticated Signature and certificate-chain verification, trust-list handling and timestamp checking, the decisions that end in a manifest being reported as valid Assertion and binding handling: hard bindings, data hashes, box hashes and the ingredient chain that ties a derived asset back to the ones it came from The writing side as well as the reading side: signing, manifest embedding, resource extraction and the files the tool produces when it creates or updates a credential The hosted Content Credentials Verify site, which the asset row covers alongside the tooling Out of scope Network access triggered by C2PA manifest input, which the policy records as not currently accepted while mitigations are in progress Enforcement of the CAWG X.509 trust model, also recorded as not currently accepted Denial of service and memory exhaustion driven by large inputs, which the policy places out of scope outright Anything that only reproduces under a non-default configuration, since the in-scope wording is anchored to default configurations "Use of unsupported platforms, unreleased versions, or non-standard build processes", quoted from the policy's out-of-scope list: build it the way the project builds it Adobe's other products, which sit on other asset rows of the same HackerOne program rather than on this one Payment gates that apply across the Adobe program: identity verification before a payout is released, and the stated requirement to "provide your Testing IP address" in order to receive a monetary payout where that applies Most-valued findings A validation bypass that makes a tampered or forged manifest verify as authentic under a default configuration: the program's headline in-scope class, the one that defeats the standard's whole purpose, and the shape most likely to reach the $5,000 to $10,000 Critical band Signature or certificate-chain acceptance flaws where a manifest signed by a key that should not be trusted still validates, since that is a trust decision rather than a display bug Memory-safety defects in the Rust parsing paths reachable purely from an attacker-supplied asset, including anything in the unsafe blocks or the codec dependencies that decode embedded resources Confusion between what was signed and what is reported: a manifest whose asserted actions or ingredients differ from the asset actually rendered, so the credential describes something other than the file a user is looking at Path traversal or arbitrary file write when the tool extracts embedded resources or writes its outputs from an untrusted asset, which turns a verification run into a local compromise Program rules Submit through sorona.xyz first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards. Show the failure under a default configuration — the program's in-scope wording is "Failures to properly detect invalid, untrusted, or tampered C2PA manifests under default configurations", and a finding that needs a weakened configuration falls outside it Network access triggered by C2PA manifest input is recorded as not currently accepted, with mitigations in progress, so that behaviour is real but not payable today Enforcement of the CAWG X.509 trust model is likewise recorded as not currently accepted Build and run against a supported platform and a released version using the project's standard build; the policy places "Use of unsupported platforms, unreleased versions, or non-standard build processes" out of scope Identity verification is required before Adobe releases a payout; there is no submission fee Report to Adobe through HackerOne first, and read what the policy says about sharing a finding with anyone else before the report goes anywhere except to Adobe Disclosure Coordinated through HackerOne, on Adobe's clock. File with Adobe through HackerOne directly, and hold the detail until Adobe confirms a fix has shipped and you are clear to publish. Note also that a fix here has to propagate into everything that embeds the library, so give the ecosystem room after Adobe ships. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability