Stellar.org

Overview

The Stellar Bug Bounty Program provides bounties for vulnerabilities and exploits discovered in Stellar Development Foundation maintained repositories, services, and infrastructure, as well as in the Stellar protocol and core consensus implementation. We recognize the importance of our community and security researchers in helping identify bugs and issues. We encourage responsible disclosure of security vulnerabilities through the bug bounty program described on this page.

Stellar is a layer-1 open-source, decentralized, peer-to-peer blockchain network that provides a framework for developers to create applications, issue assets, and connect to existing financial rails. Soroban is the smart contracts platform that integrates with and works alongside the Stellar blockchain.

#Program Transition

Effective 7 MAY 2026, SDF has consolidated its bug bounty programs into this single HackerOne program. The Stellar ImmuneFi program at immunefi.com/bug-bounty/stellar is deprecated. Reports previously submitted through ImmuneFi will continue to be honored and processed under the terms in effect at the time of submission. All new reports should be submitted through HackerOne. This policy does not modify, supersede, or administer any separate OpenZeppelin Stellar Contracts bounty unless SDF expressly states otherwise in writing.

Primacy of Rules

Stellar adheres to the Primacy of Rules. The whole bug bounty program is run strictly under the terms and conditions stated within this page.

Scope

This program covers SDF maintained open-source repositories, services, applications, and websites, as well as the Stellar protocol and core consensus implementation. In-scope assets are organized into two groups, each with its own reward scale (defined in the Rewards section below).

In scope — Standard reward scale

Open-source repositories:

• All open-source projects under the Stellar GitHub organization, unless a repository explicitly states that it is out of scope or falls under the Protocol and Core Carveout below

Online services, apps, and websites:

• https://www.stellar.org
• https://www.stellar.org/account-viewer
• https://launch.stellar.org
• https://developers.stellar.org
• https://communityfund.stellar.org

In scope — Protocol and Core Carveout (alternative reward scale)

The following assets are in scope at the alternative Protocol and Core Carveout reward scale:

• stellar-core — Reference implementation of the Stellar Consensus Protocol
• bytes-lit — Bytes array library
• rs-stellar-strkey — Rust strkeys library
• stellar-cli — Soroban CLI
• rs-stellar-xdr — Rust XDR library
• rs-soroban-env — Soroban contract engine environment
• crate-git-revision — Rust crate git version management library
• wasmi — Wasmi fork
• rs-soroban-sdk — Soroban Rust SDK
• js-stellar-sdk — Stellar JS SDK

Out of scope

• Archived GitHub repositories and projects
• GitHub repository forks
• Repositories that explicitly state they are out of scope
• Vulnerabilities affecting third-party applications that consume Stellar APIs
• Any security issue arising from collusion of node blocking set is out of scope for bug bounty programs.
• Any exploit that requires a quorum of validators.
• For MEV attacks, probabilistic/brute-force transaction ordering approaches (i.e. attacker sends many semantically identical TXs in order for one to execute first) out of scope.
• Any feature behind a BUILD_TESTS flag is out of scope.
• All test files are out of scope.
• Offline commands are out of scope.
• Issues that depend on malicious or incorrect data from external data providers used by tools such as Lab, CLI, or similar interfaces.
• stellar-core's built-in HTTP command and query endpoints are intended for private operator/local infrastructure use only. They are not public network APIs and are not meant to be exposed to untrusted/public internet traffic. Bounty reports requiring direct public exposure of these endpoints are out of scope unless they demonstrate impact under the supported private/local deployment model.

NOTE: For assets identified "In Scope", only code that has been released (present in the release tags) at the time of the vulnerability report is eligible. Vulnerabilities in the previous protocol versions are out of scope. Code residing on development, feature branches and any code tagged or documented as unreleased, experimental, or behind a feature flag not yet enabled on the Stellar public network, is out of scope. If a vulnerability exists on both an in-scope and out-of-scope branch, the report is eligible only if the vulnerable code is reachable in the default branch build.

Eligibility

Generally speaking, any bug that poses a significant vulnerability to the security or integrity of Stellar Development Foundation maintained applications, services, or infrastructure, or to the Stellar protocol or core consensus implementation, could be eligible for a reward. However, it is entirely at our discretion to decide whether a bug is significant enough to qualify.

In general, anything with the potential for financial loss or data breach is considered sufficiently severe, including:

• Implementation bugs that can lead to financial loss
• Access to our production servers
• Remote Code Execution
• Crash bugs in Stellar-RPC or Horizon, for example a bug that can crash the application by sending a special request, not by sending thousands of requests
• Vulnerabilities matching the impact categories listed in the Protocol and Core Carveout severity matrix below

The following reports are submitted very often and will generally be marked as Not Applicable:

• SPF or DMARC issues
• CORS headers on endpoints that are intentionally accessible from other domains
• Issues with third party services we use, such as Mailgun or Segment
• Logout CSRF
• Vulnerabilities in third party libraries without a working exploit against our applications or servers
• Publicly readable AWS S3 buckets containing Stellar ledger history, because this data is public
• Content Delivery Network bypass

In general, the following would not meet the threshold for severity and may be marked as Not Applicable:

• Version disclosure
• Missing security headers
• Cookies without the secure flag
• Recently disclosed 0-day vulnerabilities without demonstrated impact to our environment
• Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on an in-scope Stellar property
• Vulnerabilities that depend on physical access, social engineering, spam, or DDoS
• Vulnerabilities affecting outdated or unpatched browsers
• Vulnerabilities in third party applications that make use of Stellar APIs
• Reports that have not been responsibly investigated and documented
• Bugs already known to us, or already reported by another researcher, where the reward goes to the first valid reporter
• Issues that are not reproducible
• Issues that we cannot reasonably be expected to remediate
• Archived GitHub repositories or projects
• GitHub repository forks
• DoS vectors requiring brute-force paid transaction flooding (economically expensive, out of scope)
• Network settings causing out-of-bounds issues, since settings are manually proposed and evaluated by validators
• Security issues arising from collusion of a node blocking set

Rewards

We reward researchers who find valid security issues with a bounty paid in lumens (XLM), denominated in USD. Payouts are handled by the Stellar team directly.

The reward scale that applies to a report depends on which assets are affected:

• The Standard reward scale applies to all in-scope assets except those listed under the Protocol and Core Carveout.
• The Protocol and Core Carveout reward scale applies to vulnerabilities in stellar-core, stellar-protocol, and the Soroban runtime/host code.

Standard reward scale

The Stellar.org Bug Bounty Panel evaluates award size using technical severity calculated with CVSS v3.1 Base Score together with business impact, such as the affected asset, the number of impacted participants, the sensitivity of exposed data, and the financial or reputational consequences to the network. Reports with higher business impact may receive higher rewards than reports with lower business impact, even when the technical severity is the same. Final awards are determined at the sole discretion of the panel.

• Critical: 0 to 25,000 points
• High: 0 to 15,000 points
• Medium: 0 to 10,000 points
• Low: 0 to 2,000 points
• Note: 0 to 500 points

1 point currently corresponds to 1 USD, payable in lumens (XLM), though this may change without prior notice.

Researchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to its maximum practical impact.

Protocol and Core Carveout reward scale

The following alternative reward scale applies exclusively to vulnerabilities in the carveout scope mentioned above:

• Critical: 0 to 25,000 points
• High: 0 to 15,000
• Medium: 0 to 10,000
• Low: 0 to 1,000

Critical reward calculation for carveout assets

For Critical Blockchain/DLT bugs in carveout assets, the reward amount is 10% of the funds directly affected, capped at the maximum reward of 250,000 points.

Severity classification for carveout assets

For carveout assets, severity is determined using the OWASP risk rating methodology rather than CVSS. To use the calculator:

1. Determine the severity by looking at the Impact Category that best matches the vulnerability in the severity lookup matrix below.
2. Evaluate how easy and likely it is to exploit the vulnerability. Typically, if the exploit needs a malicious tier-1* to pull off the attack, then severity goes down at least one level (for example, High to Medium).

* Tier-1 here refers to the transitive quorum, given the state of the network today. If in the future the quorum changes, this language would need to be re-evaluated.

Severity lookup matrix

Severity, impact and examples

The examples below should be evaluated in the context of the hardware specifications described at https://developers.stellar.org/docs/validators/admin-guide/prerequisites#hardware-requirements.

Reward payment terms

Rewards are denominated in USD-equivalent points and paid in XLM. XLM conversion will be determined under Section 1.6 of SDF’s Bounty Program eligibility guidelines at https://stellar.org/grants-and-funding/bug-bounty, as updated by SDF from time to time. As of the date of this policy, that methodology uses the CF Stellar Lumens-Dollar Settlement Price under ticker XLMUSD_RR, or a comparable provider selected by SDF if unavailable, on the day the award is scheduled to be distributed

To receive a payout, researchers must successfully complete valid KYC before payment is issued.

KYC Requirement

The submission of KYC information is a requirement for payout processing. Stellar will request the following information in order to pay for successful bug submissions:

• Full name
• Date of birth
• Proof of address (either a redacted bank statement with address or a recent utility bill)
• Copy of Passport or other Government issued ID
• Tax form (W-9 / W-8BEN / W-8BEN-E)

Tax information is also required.

Participants must adhere to the Eligibility Criteria stated in this policy.

Submission Requirements

A Proof of Concept (PoC) demonstrating the bug's impact is required for all severities and all in-scope assets, including those in the Protocol and Core Carveout. All reports, regardless of severity, must include:

• A description of the vulnerability and the affected asset
• Step by step reproduction (Proof of Concept), including actual requests, responses, or an exploit script
• A clear impact statement tied to confidentiality, integrity, or availability
• Evidence that the issue is reproducible, such as screenshots, logs, transaction IDs, or a minimal working script
• Affected GitHub Repository URL (required): every report must include the GitHub repository the vulnerability is in, in the form https://github.com/stellar/ (for example, https://github.com/stellar/stellar-core). Enter NA only if the repository field is not applicable or you don't know it.
• For reports against https://github.com/stellar/anchor-platform, follow the report format mentioned at https://github.com/stellar/anchor-platform/blob/develop/SECURITY.md.

Reports submitted without a sufficient PoC will be triaged as Needs More Info and will not be eligible for payout until a sufficient PoC is provided.

Best Practices

• Please use your local instance of Horizon or Stellar-RPC and a separate network, not testnet or pubnet, when researching security bugs where possible. For example, you can use our Docker image. Blockchains are public, and someone may observe your findings and report a bug before you do.
• For issues that depend on a specific runtime or environment, we strongly encourage a containerized Proof of Concept, such as a Dockerfile, when it materially improves reproducibility.

#Prohibited Activities

The following activities are prohibited under this program:

• Testing on mainnet or public testnet; all testing must be performed on local instances
• Phishing or social engineering attacks against SDF employees, contractors, or users
• Denial of service attacks against any SDF-operated or Stellar network infrastructure
• Automated scanning or fuzzing that generates significant traffic against production services
• Testing against third-party systems, applications, or websites (including SSO providers and CDNs)
• Public disclosure of an unpatched vulnerability before receiving express written consent from SDF
• Any activities that violate applicable laws or regulations

Responsible Disclosure

Our development team may take up to 90 days to implement a fix based on the severity of the report. Please allow this process to fully complete before requesting permission to publicly disclose a vulnerability. All public disclosures must be done only at the express consent of SDF.

Bug reports covering previously-discovered bugs are not eligible for a reward within this program. This includes known issues that the project is aware of but has consciously decided not to "fix", necessary code changes, or any implemented operational mitigating procedures that can lessen potential risk. Researchers should check the relevant GitHub repositories' issues marked with a security label to make sure a vulnerability has not been published already.

Report a Bug

• Submit your report at https://hackerone.com/stellar/reports/new
• Include as much detail as possible, including a description of the issue, its potential impact, and clear reproduction steps or a Proof of Concept
• Please allow 3 business days for an initial response before following up

Legal

Participation in this program is subject to the eligibility criteria of this policy as well as the eligibility criteria published at https://stellar.org/grants-and-funding/bug-bounty, the HackerOne platform terms applicable to the Participant’s use of HackerOne, and the SDF Terms of Service available at https://stellar.org/terms-of-service, all of which are incorporated by reference. If there is a conflict, this policy controls with respect to program scope, vulnerability severity classification, report submission requirements, disclosure requirements, and reward amounts; SDF’s Bounty Program eligibility guidelines control with respect to participant eligibility, compliance checks, tax documentation, XLM conversion, and payout eligibility; and the SDF Terms of Service control for all other matters.

You may not participate in this program if you are a resident of, or are located in, a country that appears on any U.S. sanctions list, or if you are identified on the OFAC Specially Designated Nationals and Blocked Persons list.

SDF may modify, suspend, or terminate this program, including any scope, eligibility, severity, reward, or payout term, at any time. Unless SDF states otherwise, changes apply only to submissions made after the updated policy is posted.

Violation of this policy or any of the terms incorporated by reference may result in removal from the program and forfeiture of any bounty.

Stellar Terminology Reference

Stellar's architecture differs from typical PoW/PoS blockchains. The following glossary defines Stellar concepts that are referenced throughout this policy and that researchers from other ecosystems may find useful.