Decred Bug Bounty

Rules

We ask that you respect the following rules and guidelines. Repeated violations will lead to disqualification from the bounty program.

• All bug reports need to have clear reproduction steps and/or proof of concept.

• Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.

• Any type of public disclosure of the vulnerability without prior approval from the bug bounty program will make it ineligible for payout.

• Please inform us if you have your own timeline for full disclosure (90 days minimum). Unless specified we will release the information at our own pace.

• All Current/Past (for up-to 6 months) Decred contractors are barred from taking part in this bug bounty program.

• You must not leverage the existence of a vulnerability or access to sensitive or confidential data to make threats, extortionate demands, or ransom requests.

• Hazardous testing without explicit authorization will lead to disqualification. This includes:

  1. Issues relating to excessive traffic/requests (e.g. DoS, DDoS)
  2. Attacks which may affect the availability of systems
  3. Social engineering attacks (e.g., phishing, opening support requests)
  4. Attacks that are noisy to users or admins (e.g., spamming notifications or forms)
  5. Attacks against physical facilities

• Content generated by LLMs must be meaningfully edited, validated, or supported by original analysis. Reports consisting primarily of low-effort, irrelevant, or excessively verbose content will be rejected.

Reminders

• Almost all of Decred’s projects can be run locally and reproduction instruction are available on GitHub. We strongly recommend you to do this.

• There is a completely separate Decred testnet which is specifically created for software testing. Testing on the public testnet will prevent impact on mainnet and removes the risk of causing real financial damage. It is also possible to create your own personal simnet, running on your own local system with low enough difficulty to mine blocks using only a CPU.

• Always check the “issues” in GitHub of a project to avoid a duplicate report.

• Decred project is not responsible for any loss of DCR due to bug testing.

Payout

The OWASP Risk Rating Methodology will be used for assessing vulnerabilities and determining payout amount.

The impact on the Decred ecosystem will also be taken into consideration. An RCE in dcrwebapi (low impact) is not the same as an RCE in dcrd or Decrediton (higher impact). The payout amount is decided by a core “bug bounty” group. Once decided, there will be no changes to the payout amount unless the vulnerability impact changes.

The following are also factors in the payout:

• Quality of the initial writeup.
• Quality of vulnerability reproduction steps and/or proof of concept.

The bounty program is funded by the Decred Treasury, therefore all payments are in DCR only. Recipients are required to create a Decred wallet and provide a payment address. Payouts are sent at the beginning of each month using the average DCR/USDT rate of the previous month.

For vulnerabilities that require a patch rollout and pose a risk to the network participants, we might choose to only release 60% of the payout amount first and hold the 40% until a patch has been released and distributed.

The maximum approved budget for the payouts is capped at 100,000 USD. Please be aware of this when you are submitting multiple critical vulnerabilities. If the limit is reached then a new proposal will have to be submitted and get stakeholder approval before you get paid fully.

The bounty hunter will be given one month to claim it after which the bounty will be considered forfeit.

Indicative payout amounts

Note: up to 500 USD

Low: up to 1,500 USD

Medium: up to 5,000 USD

High: up to 15,000 USD

Critical: up to 30,000 USD

In Scope

To be eligible for the bounty program, reports must be reproducible security vulnerabilities in the latest production release or the master branch of the following projects:

* cspp only csppsolver cmd, and solver and solverrpc packages are in scope.

** dcrlnd scope has some limitations, please read the linked github page before testing.

Out of scope

• Chat and communication platforms including Slack, RocketChat, Matrix, Discord and the Decred forum
• Email servers
• Testing or staging sites
• Projects still under development
• Unsupported projects including:
  • dcrios
  • dcrandroid
• Deprecated projects including:
  • insight and insight-api
  • bitcore-wallet-service
  • Paymetheus
  • Copay
  • dcr-netstats
  • dcrstakepool
  • atomicswap

Ineligible Findings

• Bugs which do not lead to security vulnerabilities.

• Bugs in old releases, proof-of-concept code, or feature branches.

• Duplicate reports or reports of bugs which are already known (note that some of our issue tracking is private).

• Vulnerabilities requiring extensive access to the host system (eg. physical access, root login) are only accepted if said access may be gained via a flaw in our source code.

• Typical resource exhaustion attacks involving normal network operation are already well known limitations of peer-to-peer networks and generally are not covered. They will be considered on a case by case basis.

• The following issues will be closed as invalid except in rare circumstances demonstrating clear security impact:

  1. Theoretical vulnerabilities that require unlikely user interaction or circumstances. For example:

     1. Vulnerabilities only affecting users of unsupported or end-of-life browsers or operating systems.
     2. Broken link hijacking.
     3. Tabnabbing.
     4. Content spoofing and text injection issues.
     5. Self-exploitation, such as self-XSS or self-DoS (unless it can be used to attack a different account).

  2. Theoretical vulnerabilities that do not demonstrate real-world security impact. For example:

     1. Clickjacking on pages with no sensitive actions.
     2. Cross-Site Request Forgery (CSRF) on forms with no sensitive actions (e.g., Logout).
     3. Permissive CORS configurations without demonstrated security impact.
     4. Software version disclosure / banner identification issues / descriptive error messages or headers (e.g., stack traces, application or server errors).
     5. Comma Separated Values (CSV) injection.
     6. Open redirects (unless you can demonstrate additional security impact).
     7. Outdated software/library versions.

  3. Optional security hardening steps / missing best practices. For example:

     1. SSL/TLS Configurations.
     2. Lack of SSL Pinning.
     3. Insecure settings in non-sensitive cookies (e.g., missing HttpOnly/Secure flags).
     4. Content-Security-Policy configuration opinions.
     5. DMARC, SPF, or other email server or DNS configuration settings and policies.
     6. Most issues related to rate limiting.

Please follow a standard format when submitting vulnerabilities

Title:

Affected website or repository:

Vulnerability Type:

Details:

Impact of Vulnerability:

Reproduction or POC details:

Fix:

Email your bug report to bugbounty{[@]}decred.org. This email address can also be used as a channel to establish more secure communications, for example in the event of a particularly sensitive report.