SecureDrop

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 P1 - Critical │ $2,000 - $2,500 │ $2,500 - $3,125 P2 - High │ $1,000 - $1,500 │ $1,250 - $1,875 P3 - Medium │ $500 - $750 │ $625 - $938 P4 - Low │ $100 - $200 │ $125 - $250 Submit a vulnerability CVE history 4 Last 12 months 7 Lifetime Access control 30 % Info disclosure 30 % Code execution 20 % Parsing/validation 18 % Latest advisories Loading the feed Overview SecureDrop is the standard anonymous tip-submission system for investigative journalism: a Tor onion service that lets a source hand documents to a newsroom without the newsroom ever learning who they are. It is deployed by dozens of major news organisations worldwide, and every one of those instances holds the identities of confidential sources, which makes this a threat model where a single access-control or deanonymization bug is a physical-safety incident rather than a data incident. Score its importance on blast radius, not on install count. The engagement is unusually clean for a paid rail: the complete in-scope target list is three AGPL-3.0 GitHub repositories and nothing else, with no hosted asset, no marketing domain and no SaaS anywhere in it. The Freedom of the Press Foundation, a US non-profit, pays $100 to $2,500 through Bugcrowd on the standard P1-P4 priority scale. sorona.xyz adds 1.25x on top of whatever the engagement awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. In scope The engagement's complete target list is three repositories and nothing else: freedomofpress/securedrop , freedomofpress/securedrop-workstation and freedomofpress/securedrop-client . Source code only, at the full $100 to $2,500 range The SecureDrop server in full: the Source Interface and the Journalist Interface, the Flask applications behind both, submission and reply handling, the Journalist API, and the application and monitor servers The network and service layer as SecureDrop configures it: the onion services and their client authorisation, the Tor configuration the installer writes, and the OSSEC monitoring and alerting path Cryptography and credential handling throughout: the GPG submission keys, source codenames, journalist passphrases and two-factor enrolment, and the key material the client holds SecureDrop Workstation in full: the Qubes qube layout, the inter-qube RPC policies, the dom0 salt provisioning and the updater that keeps it current SecureDrop Client in full: the journalist application, its sync against the Journalist API, the local database and file store, and the export and print paths through the dedicated qubes The deployment code those repositories ship: the Debian packages, the Ansible playbooks and the securedrop-admin tooling an operator runs to stand an instance up Out of scope Hosted and vendor-operated assets: nothing on securedrop.org or freedom.press is in scope, because the engagement lists no hosted target at all Downstream newsroom deployments, which individual news organisations run themselves and which are not the funder's assets to authorise testing against Defects that actually live in Tor, Qubes OS or Debian upstream rather than in SecureDrop's own code, which belong to those projects Classes the Bugcrowd VRT excludes by default, since the empty out-of-scope list means the taxonomy governs: self-XSS, missing security headers and best-practice observations Configuration mistakes by a particular newsroom operator, as opposed to a defect in what the project ships Findings that assume the attacker already holds journalist credentials or the instance's keys, which sits inside the trust boundary rather than across it Reports filed outside Bugcrowd, or by anyone unwilling to hold a Bugcrowd account on the platform's standard payment terms, since the engagement pays no other way Most-valued findings Anything that deanonymizes a source, or narrows the set they could belong to, from data the server or the onion service exposes. This is the highest-consequence finding the project can receive and it shares the top of the distribution at 30% Access-control bypass letting an anonymous visitor of the Source Interface reach journalist functionality or read other sources' submissions, the other 30% and the boundary the whole design rests on Pre-authentication remote code execution on the application server reached through the Source Interface, which is by design open to anyone on the Tor network A malicious submission that escapes the Qubes isolation of the Workstation or the Client, since that isolation is the last thing standing between a hostile file and the journalist's machine Parsing or validation failures on submitted files and their encrypted payloads, at 18%, because a source is by definition an untrusted party the system still has to accept input from Retained state a seizure or a subpoena could turn into source identities: logs, temporary files, database rows or memory the system was supposed to have discarded 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. You need a Bugcrowd account and are bound by its standard payment terms; priority, and therefore the band you land on, is set by Bugcrowd's Vulnerability Rating Taxonomy The scope is source code only: stand up your own instance to test against, because no hosted asset and no newsroom's live deployment is an eligible target The engagement publishes no out-of-scope list, so the VRT's own exclusions govern and the usual best-practice, missing-header and self-XSS findings still will not pay Bugcrowd's Standard Disclosure Terms are incorporated into this brief and treat every submission as the program owner's confidential information, with no public disclosure at any time Duplicates pay the first reporter only, on the platform's usual terms Disclosure Coordinated through Bugcrowd, and gagged by default: the incorporated Standard Disclosure Terms state that submissions are confidential information of the program owner and that no submission may be publicly disclosed at any time. File with Bugcrowd before the finding goes anywhere else, and expect publication to require the Foundation's agreement rather than a fixed clock. 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