- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 14
- Public CVEs
- 0
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays from $1,500
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- 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 | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- 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
14 assets you may test, 6 excluded.
Web 1
- https://github.com/distribution/distribution
Products and areas 13
- Blob upload in both forms, monolithic and chunked, including resumable upload state and the cross-repository blob mount
- Deletion and garbage collection: manifest delete, tag delete, blob delete and the storage.delete.enabled gate that is supposed to govern them
- Digest verification and content addressing, wherever content is accepted, stored or served
- Manifest parsing and validation across Docker schema1, schema2, OCI image manifest and OCI image index, plus the referrers API built on top
- Notifications and webhooks, and everything the registry sends outbound as a result
- Pull-through cache and proxy mode, including the upstream credentials the registry holds and every request it makes on a client's behalf
- The configuration surface in full, plus TLS termination and the middleware layer including redirect and CloudFront
- The OCI distribution API in full: manifest, blob, tag, catalog and referrers endpoints, and every method each of them accepts
- The policy asks for any security issue to be reported privately to the CNCF security list and rules out public issues. It draws no boundary narrower than the registry itself
- The redis descriptor and blob descriptor cache, including how a cached entry is scoped and invalidated
- The simpler auth backends the registry ships, htpasswd and silly, and the access controller interface itself
- The storage driver layer across filesystem, S3, GCS, Azure and OSS, and the path layout each one writes
- The token authentication flow end to end: the bearer challenge, the www-authenticate realm and service parameters, JWT validation, key and certificate handling, and scope parsing
Out of scope (6)
- Client-side tooling such as Docker Engine, Podman or Skopeo, which have their own entries here
- Deliberate operator configuration, such as running with delete.enabled on for anonymous users, serving without TLS or leaving the catalog endpoint public on purpose
- Harbor, the GitLab Container Registry and other products that embed or fork this code, where the defect is in their own additions
- Object storage services themselves rather than the registry's use of them
- Public disclosure ahead of the coordinated release
- The external token auth service in a token-auth deployment, where that service is a separate implementation
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy. "We" in these lines means Sorona, not this site.
While testing
-
Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly.
-
Report privately to the address on the policy page , the address named in SECURITY.md
-
GitHub private vulnerability reporting is enabled on distribution/distribution, so a draft advisory is a second working channel
-
Do not open a public issue for a security problem; the policy rules it out
-
State the deployment mode. Pull-through cache, plain registry and a registry behind a token auth service have materially different trust boundaries, and two of the last four advisories only existed in one of them
-
Name the storage driver and whether a redis cache was configured. Both have carried findings of their own
-
Say whether the finding needs an authenticated pusher, an authenticated puller or no credentials at all. That distinction sets the severity here
-
Hold detail until the advisory is out, and expect downstream registries to still be catching up afterwards.
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.
No CVEs matched yet. We match NVD records by vendor name, so products sold under another name can be missing.
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 This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 3 Last 12 months Access control 35 % Authentication & token handling 30 % Credential exposure 20 % Cache handling 15 % Latest advisories Loading the feed Overview Distribution is the OCI reference registry, the code that ships as the registry:2 image and the default choice for anyone self-hosting a container registry. It is also embedded or forked into Harbor, the GitLab Container Registry and a range of vendor registries, so a defect here reaches every image those registries serve. CVE-2026-33540 is the reference point: a registry running in pull-through cache mode could be made to send its upstream credentials to an attacker-controlled host. The project pays nothing for a report and routes everything through a CNCF security list, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy asks for any security issue to be reported privately to the CNCF security list and rules out public issues. It draws no boundary narrower than the registry itself The OCI distribution API in full: manifest, blob, tag, catalog and referrers endpoints, and every method each of them accepts Blob upload in both forms, monolithic and chunked, including resumable upload state and the cross-repository blob mount The token authentication flow end to end: the bearer challenge, the www-authenticate realm and service parameters, JWT validation, key and certificate handling, and scope parsing The simpler auth backends the registry ships, htpasswd and silly, and the access controller interface itself Pull-through cache and proxy mode, including the upstream credentials the registry holds and every request it makes on a client's behalf The storage driver layer across filesystem, S3, GCS, Azure and OSS, and the path layout each one writes The redis descriptor and blob descriptor cache, including how a cached entry is scoped and invalidated Deletion and garbage collection: manifest delete, tag delete, blob delete and the storage.delete.enabled gate that is supposed to govern them Manifest parsing and validation across Docker schema1, schema2, OCI image manifest and OCI image index, plus the referrers API built on top Digest verification and content addressing, wherever content is accepted, stored or served Notifications and webhooks, and everything the registry sends outbound as a result The configuration surface in full, plus TLS termination and the middleware layer including redirect and CloudFront Out of scope Harbor, the GitLab Container Registry and other products that embed or fork this code, where the defect is in their own additions The external token auth service in a token-auth deployment, where that service is a separate implementation Client-side tooling such as Docker Engine, Podman or Skopeo, which have their own entries here Deliberate operator configuration, such as running with delete.enabled on for anonymous users, serving without TLS or leaving the catalog endpoint public on purpose Object storage services themselves rather than the registry's use of them Public disclosure ahead of the coordinated release Most-valued findings Anything that gets the registry to hand its upstream credentials to somewhere they do not belong. CVE-2026-33540 did it through the www-authenticate bearer realm on a pull-through cache, and that is the highest-value class here Token authentication defects, especially anywhere an untrusted key can influence JWT validation. CVE-2025-24976 allowed an untrusted signing key to be injected into a token Access control that can be walked around: a scope that grants more than it names, a pull token that permits a push or delete, or an anonymous request that reaches an authenticated path Cache poisoning and stale-content resurrection. CVE-2026-35172 brought back access to a deleted blob through the repository-scoped redis descriptor cache, so cache scoping is worth attacking directly Deletion gates that do not hold, of the CVE-2026-41888 shape where tag deletion went through despite storage.delete.enabled being off Image substitution: any path where the content served for a digest or a tag is not what was pushed, since that turns one registry bug into a supply-chain compromise for every consumer Manifest and index parsing defects, including confusion between schema versions and referrers handling that lets one repository's content surface under another Storage driver path handling, where a repository or digest value influences the path written on the backend Server-side request forgery out of proxy mode, notifications or any other outbound request the registry makes Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report privately to [email protected] , the address named in SECURITY.md GitHub private vulnerability reporting is enabled on distribution/distribution, so a draft advisory is a second working channel Do not open a public issue for a security problem; the policy rules it out State the deployment mode. Pull-through cache, plain registry and a registry behind a token auth service have materially different trust boundaries, and two of the last four advisories only existed in one of them Name the storage driver and whether a redis cache was configured. Both have carried findings of their own Say whether the finding needs an authenticated pusher, an authenticated puller or no credentials at all. That distinction sets the severity here There is no cash payment on this channel. The project offers no reward and no swag Disclosure Coordinated privately through the CNCF security list and published as a GitHub Security Advisory alongside a patched release. The project ships fixes on the supported release branches and the registry:2 image follows, but the practical exposure window is longer than that: Harbor, the GitLab Container Registry and several vendor registries embed or fork this code and each picks the fix up on its own schedule. Hold detail until the advisory is out, and expect downstream registries to still be catching up afterwards. 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