- Top reward
- $11,000
- Top severity paid
- Critical
- Assets in scope
- 9
- Public CVEs
- 1
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays up to $11,000
- for critical bugs, from $313.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Replies within 4 days
- As the policy promises.
- 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 |
|
$11,000 |
| High |
|
$6,000 |
| Medium |
|
$2,500 |
| Low |
|
$313 |
- Response
-
Within 4 days
~4 days First response
- 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, 6 excluded.
Web 1
- https://github.com/dependabot/dependabot-core
Products and areas 8
- Credential handling for private registries: the tokens injected into the updater, the proxy that carries them, and every path they can travel back out of
- GitHub prices the Dependabot asset at critical severity and names two eligible classes outright: execution-environment breakout attacks that reach private networked resources or other users' data, and security issues in dependabot-core itself
- Manifest and lockfile parsing, where dependabot-core has to make sense of untrusted package-lock.json, Gemfile.lock, go.sum, pom.xml and their equivalents
- That second line is unqualified, so the repository is the target at every stage of an update run: the file fetchers, the file parsers, the update checkers, the file updaters and the metadata finders that GitHub's scope note points at through the project's architecture overview
- The native helpers that shell out to bundle, npm, pip-compile and go, running real package-manager binaries against attacker-supplied manifests
- The per-ecosystem update logic for Bundler, npm and Yarn, pip, Go modules, Maven, Gradle, Cargo, NuGet, Composer, Hex, Docker, Terraform and GitHub Actions, each of which reads manifests written by somebody else
- The pull-request side of a run, where branch names, commit messages and PR bodies are assembled from release notes and changelogs published by whoever owns the dependency
- The updater container and its isolation from the network around it, which is the second class GitHub names
Out of scope (6)
- Anything reachable only with a self-hosted or modified build of dependabot-core
- Awards are gated on sanctions screening, so a reporter who cannot clear it will not be paid however good the finding
- Bugs that first require a GitHub organisation owner to be compromised
- Denial of service against the hosted Dependabot service by volume rather than by defect
- Malicious-package findings on npm or RubyGems, which are abuse reports to those registries rather than bounty submissions here
- Vulnerabilities in the upstream package managers themselves rather than in dependabot-core, a boundary the scope line draws firmly
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.
-
The defect has to be in dependabot-core , not in the upstream package manager it shells out to
-
The finding must reproduce against Dependabot as GitHub runs it, not against a self-hosted and modified copy of the updater
-
Sanctions screening applies before a bounty can be paid
-
Keep all information about the report on HackerOne while it is open
Not accepted
-
Vulnerabilities in the upstream package managers themselves rather than in dependabot-core
-
Malicious-package findings on npm or RubyGems
-
Denial of service against the hosted Dependabot service by volume rather than by defect
-
Bugs that first require a GitHub organisation owner to be compromised
-
Anything reachable only with a self-hosted or modified build of dependabot-core
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 1 CVEs. 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 │ $10,000 │ $11,000 High │ $5,000 │ $6,000 Medium │ $2,000 │ $2,500 Low │ $250 │ $313 Submit a vulnerability CVE history 0 Last 12 months 1 Lifetime Code execution 40 % Parsing/validation 25 % Info disclosure 20 % Access control 10 % Latest advisories Loading the feed Overview Dependabot runs by default on a very large share of all public repositories on GitHub, and on a very large share of private enterprise repositories through automated security updates; dependabot-core is also the engine behind third-party redistributions on GitLab and Azure DevOps, so the same parsers run well outside GitHub too. It is a machine that voluntarily ingests untrusted dependency manifests from every ecosystem and then executes package-manager binaries against them, holding write access to open pull requests: few pieces of software have a worse input-trust-to-privilege ratio. GitHub's scope table carries the most explicit repo-level line it publishes anywhere, paying for execution-environment breakout and for security issues in dependabot-core itself at $250 for low up to $10,000 for critical. sorona.xyz adds 1.25x on top of whatever GitHub awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. Response times ~4 days First response ~11 days Triage ~44 days Bounty In scope GitHub prices the Dependabot asset at critical severity and names two eligible classes outright: execution-environment breakout attacks that reach private networked resources or other users' data, and security issues in dependabot-core itself That second line is unqualified, so the repository is the target at every stage of an update run: the file fetchers, the file parsers, the update checkers, the file updaters and the metadata finders that GitHub's scope note points at through the project's architecture overview The per-ecosystem update logic for Bundler, npm and Yarn, pip, Go modules, Maven, Gradle, Cargo, NuGet, Composer, Hex, Docker, Terraform and GitHub Actions, each of which reads manifests written by somebody else Manifest and lockfile parsing, where dependabot-core has to make sense of untrusted package-lock.json , Gemfile.lock , go.sum , pom.xml and their equivalents The native helpers that shell out to bundle , npm , pip-compile and go , running real package-manager binaries against attacker-supplied manifests Credential handling for private registries: the tokens injected into the updater, the proxy that carries them, and every path they can travel back out of The updater container and its isolation from the network around it, which is the second class GitHub names The pull-request side of a run, where branch names, commit messages and PR bodies are assembled from release notes and changelogs published by whoever owns the dependency Out of scope Vulnerabilities in the upstream package managers themselves rather than in dependabot-core , a boundary the scope line draws firmly Malicious-package findings on npm or RubyGems, which are abuse reports to those registries rather than bounty submissions here Denial of service against the hosted Dependabot service by volume rather than by defect Bugs that first require a GitHub organisation owner to be compromised Anything reachable only with a self-hosted or modified build of dependabot-core Awards are gated on sanctions screening, so a reporter who cannot clear it will not be paid however good the finding Most-valued findings Code execution reached from a crafted manifest or lockfile that the updater parses, which is the top-paying class and the one the repository's own threat model invites Execution-environment breakout out of the updater container into private networked resources or another user's data, the second class GitHub names explicitly Parser confusion where the manifest dependabot-core reads differs from what the package manager it shells out to executes Leakage of private registry credentials injected into the updater into a pull request, a log, or a request to an attacker-controlled host Access-control gaps that let the updater open or modify a pull request outside the repository it was scoped to 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. Two classes are named as eligible: execution-environment breakout attacks reaching private networked resources or other users' data, and security issues in dependabot-core itself The defect has to be in dependabot-core , not in the upstream package manager it shells out to The finding must reproduce against Dependabot as GitHub runs it, not against a self-hosted and modified copy of the updater Sanctions screening applies before a bounty can be paid Keep all information about the report on HackerOne while it is open Program stats 2,132 Reports resolved $6.5M Bounties paid 62% Response efficiency Disclosure Coordinated through GitHub on HackerOne. GitHub explicitly does not limit what you publish about your own finding, so a write-up is available to you once the fix has landed; while the report is live it stays on the platform. sorona.xyz holds your finding until GitHub has resolved it. 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