[{"id":3774342,"new_policy":"## Overview\n\nThe 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.\n\nStellar 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.\n\n#Program Transition\n\nEffective 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.\n\n# Primacy of Rules\n\nStellar adheres to the Primacy of Rules. The whole bug bounty program is run strictly under the terms and conditions stated within this page.\n\n# Scope\n\nThis 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).\n\n## In scope — Standard reward scale\n\nOpen-source repositories:\n\n* All open-source projects under the [Stellar GitHub organization](https://github.com/orgs/stellar/repositories), unless a repository explicitly states that it is out of scope or falls under the Protocol and Core Carveout below\n\nOnline services, apps, and websites:\n\n* [https://www.stellar.org](https://www.stellar.org)  \n* [https://www.stellar.org/account-viewer](https://www.stellar.org/account-viewer)  \n* [https://launch.stellar.org](https://launch.stellar.org)  \n* [https://developers.stellar.org](https://developers.stellar.org)  \n* [https://communityfund.stellar.org](https://communityfund.stellar.org)\n\n## In scope — Protocol and Core Carveout (alternative reward scale)\n\nThe following assets are in scope at the alternative Protocol and Core Carveout reward scale:\n\n* [stellar-core](https://github.com/stellar/stellar-core) — Reference implementation of the Stellar Consensus Protocol  \n* [bytes-lit](https://github.com/stellar/bytes-lit) — Bytes array library\n* [rs-stellar-strkey](https://github.com/stellar/rs-stellar-strkey) — Rust strkeys library\n* [stellar-cli](https://github.com/stellar/stellar-cli) — Soroban CLI\n* [rs-stellar-xdr](https://github.com/stellar/rs-stellar-xdr) — Rust XDR library\n* [rs-soroban-env](https://github.com/stellar/rs-soroban-env) — Soroban contract engine environment\n* [crate-git-revision](https://github.com/stellar/crate-git-revision) — Rust crate git version management library\n* [wasmi](https://github.com/stellar/wasmi) — Wasmi fork\n* [rs-soroban-sdk](https://github.com/stellar/rs-soroban-sdk) — Soroban Rust SDK\n* [js-soroban-client](https://github.com/stellar/js-soroban-client) — Soroban JS Client\n\n## Out of scope\n\n* Archived GitHub repositories and projects  \n* GitHub repository forks  \n* Repositories that explicitly state they are out of scope  \n* Vulnerabilities affecting third-party applications that consume Stellar APIs\n* Any security issue arising from collusion of node blocking set is out of scope for bug bounty programs.\n* Any exploit that requires a quorum of validators.\n* 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.\n* Any feature behind a BUILD_TESTS flag is out of scope.\n* All test files are out of scope.\n* Offline commands are out of scope.\n* Issues that depend on malicious or incorrect data from external data providers used by tools such as Lab, CLI, or similar interfaces.\n\nNOTE: 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.\n\n# Eligibility\n\nGenerally 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.\n\nIn general, anything with the potential for financial loss or data breach is considered sufficiently severe, including:\n\n* Implementation bugs that can lead to financial loss  \n* Access to our production servers  \n* Remote Code Execution  \n* 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  \n* Vulnerabilities matching the impact categories listed in the Protocol and Core Carveout severity matrix below\n\nThe following reports are submitted very often and will generally be marked as Not Applicable:\n\n* SPF or DMARC issues  \n* CORS headers on endpoints that are intentionally accessible from other domains  \n* Issues with third party services we use, such as Mailgun or Segment  \n* Logout CSRF  \n* Vulnerabilities in third party libraries without a working exploit against our applications or servers  \n* Publicly readable AWS S3 buckets containing Stellar ledger history, because this data is public  \n* Content Delivery Network bypass\n\nIn general, the following would **not** meet the threshold for severity and may be marked as **Not Applicable**:\n\n* Version disclosure  \n* Missing security headers  \n* Cookies without the secure flag  \n* Recently disclosed 0-day vulnerabilities without demonstrated impact to our environment  \n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on an in-scope Stellar property  \n* Vulnerabilities that depend on physical access, social engineering, spam, or DDoS  \n* Vulnerabilities affecting outdated or unpatched browsers  \n* Vulnerabilities in third party applications that make use of Stellar APIs  \n* Reports that have not been responsibly investigated and documented  \n* Bugs already known to us, or already reported by another researcher, where the reward goes to the first valid reporter  \n* Issues that are not reproducible  \n* Issues that we cannot reasonably be expected to remediate  \n* Archived GitHub repositories or projects  \n* GitHub repository forks  \n* DoS vectors requiring brute-force paid transaction flooding (economically expensive, out of scope)  \n* Network settings causing out-of-bounds issues, since settings are manually proposed and evaluated by validators  \n* Security issues arising from collusion of a node blocking set\n\n# Rewards\n\nWe 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.\n\nThe reward scale that applies to a report depends on which assets are affected:\n\n* The **Standard reward scale** applies to all in-scope assets except those listed under the Protocol and Core Carveout.  \n* The **Protocol and Core Carveout reward scale** applies to vulnerabilities in `stellar-core`, `stellar-protocol`, and the Soroban runtime/host code.\n\n## Standard reward scale\n\nThe 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.\n\n* Critical: 0 to 25,000 points  \n* High: 0 to 15,000 points  \n* Medium: 0 to 10,000 points  \n* Low: 0 to 2,000 points  \n* Note: 0 to 500 points\n\n1 point currently corresponds to 1 USD, payable in lumens (XLM), though this may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to its maximum practical impact.\n\n## Protocol and Core Carveout reward scale\n\nThe following alternative reward scale applies exclusively to vulnerabilities in the carveout scope mentioned above:\n\n* Critical: 0 to 25,000 points  \n* High: 0 to 15,000  \n* Medium: 0 to 10,000  \n* Low: 0 to 1,000\n\n### Critical reward calculation for carveout assets\n\nFor 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.\n\n### Severity classification for carveout assets\n\nFor carveout assets, severity is determined using the OWASP risk rating methodology rather than CVSS. To use the calculator:\n\n1. Determine the severity by looking at the *Impact Category* that best matches the vulnerability in the severity lookup matrix below.  \n2. Evaluate how easy 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).\n\n\\* 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.\n\n#### Severity lookup matrix\n\n| Impact Category | Trivial to exploit | Requires tier-1 access |\n| :---- | :---: | :---: |\n| Direct theft / loss of funds | Critical | Critical |\n| Total network halt | Critical | High \\- Medium (mitigation dependent) |\n| Affects XLM supply integrity (minting, burning) | Critical | High |\n| Fund freeze | Critical | High |\n| Observable non-determinism causing divergence | Critical | High |\n| Fee pool exploits | High | Medium |\n| Soroban runtime bug putting realistic Smart contracts at risk of plausible malfunction | High | \\- |\n| Increase resource consumption that can cause slowdown of 5 seconds or more | Medium | Low |\n| Increase memory consumption more than 20% of the recommended hardware specification | Medium | Low |\n| Soroban simulation library causing Stellar RPC crash | Medium | \\- |\n| MEV / transaction ordering manipulation | Medium | \\- |\n| Bypass Soroban rent fee mechanism paying less than 20% of actual | Medium | Low |\n| Shut down of greater than 30% of watcher nodes (network unaffected) | Medium | Low |\n| Bypass Soroban rent fee mechanism paying between 21% to 99% | Low | Informational |\n| DoS by less than or equal to 30% consumption of CPU/Memory resources | Low | Informational |\n| Increase resource consumption that can cause slowdown of more than 1 second but less than 5 seconds | Low | Informational |\n| Increase memory consumption more than 5% but less than 20% of the recommended hardware specification | Low | Informational |\n| Shut down of 10% to 30% of (network unaffected) | Low | Informational |\n| Minor metering discrepancy that can cause slowdown between 2 and 5 seconds | Low | Informational |\n| Trivial metering discrepancy that can cause slowdown less than 2 seconds | Informational | Informational |\n\n#### Severity, impact and examples\n\nThe 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](https://developers.stellar.org/docs/validators/admin-guide/prerequisites#hardware-requirements).\n\n| Severity | Impact Description | Concrete Example |\n| :---: | :---- | :---- |\n| Critical | Direct theft or irreversible loss of funds excluding fees burned | \\*Payout would be a % of loss of funds |\n| Critical | Total network halt — network cannot confirm new transactions | Example 1: Auth stack exhaustion causing all validator nodes to crash. Example 2: XDR recursion depth limits causing stack overflow. Example 3: Oversized duplicate SCP message crashing a node via flow control invariant abort. \\*Mitigation mechanism determines the severity. If it is easy to mitigate by removing a Tier-1 from another's config then it is medium severity. If a new software package is needed then it is high severity. |\n| Critical | Minting of native asset (XLM) outside of protocol rules | Integer overflow in fee validation enabling creation of XLM from nothing |\n| Critical | Permanent freezing of funds | Bug in Soroban contract storage that makes persistent entries permanently inaccessible |\n| Critical | Observable non-determinism causing divergence | Floating-point or platform-dependent behavior in Soroban host functions producing different ledger hashes across validator architectures (e.g., ARM vs x86) |\n| High | A malicious Tier-1 validator able to halt the entire network | A tier-1 validator crafting malformed SCP messages that cause all other tier-1 nodes to crash |\n| High | Fee pool exploits | A user submits a transaction that drains the Fee Pool thus stealing XLM |\n| High | Soroban runtime bug putting realistic Smart contracts at risk of plausible malfunction | Examples: unauthorized call gets authorized, SCVal stored in storage gets corrupted, error code gets lost, cryptographic function \"validates\" invalid input, wrong contract gets invoked, wrong event emitted. |\n| Medium | Metering discrepancy in Soroban that can lead to resource exhaustion | Soroban host functions undercharging CPU or memory resources by 50 times such that an attacker can produce measurable slowdown |\n| Medium | Increase resource consumption that can cause slowdown of 5 seconds or more | Specially crafted Soroban contract invocation that triggers excessive disk I/O during ledger close, slowing all validators |\n| Medium | Increase memory consumption more than 20% of the recommended hardware specification |  |\n| Medium | Soroban simulation library bug causing Stellar RPC to crash | Bug in Soroban simulation library causing Stellar RPC nodes to crash when running simulation |\n| Medium | MEV attack or any transaction ordering manipulation | Bug where attacker can deterministically cause a transaction to execute before a victim transaction |\n| Low | Shut down of greater than 30% of watcher nodes – network is unaffected and continues to close ledgers | Peer-to-peer flood message causing non-tier-1 watchers to disconnect |\n| Low | DoS by causing less than 30% of CPU/memory resource consumption on nodes outside of the declared limits and without brute force | Specially crafted Soroban contract invocation that triggers moderate disk I/O during ledger close, slowing all validators |\n| Low | Bypass of transaction fee mechanism enabling free or severely underpriced transactions | TxSet baseFee integer overflow bypassing fee validation entirely |\n| Low | Exploit Soroban rent fee mechanism | Any exploit that can get access to free rent for persistent Soroban entries. |\n| Informational | Minor metering discrepancy causing undercounting of Soroban transactions | Undercharging in Soroban host function that cannot be exploited to DoS the network or cause any significant slowdown. |\n| Informational | DoS vector requiring brute-force (paid transaction flooding) | Submitting thousands of max-fee transactions to slow ledger close — economically expensive and out of scope |\n| Informational | Network settings causing out of bounds issues | Settings are manually proposed and thoroughly evaluated by validators so there is no risk of going out of bounds |\n| Informational | New nodes unable to join the network | Corrupt history causing a new node to not be able to join |\n\n## Reward payment terms\n\nRewards 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\n\nTo receive a payout, researchers must successfully complete valid KYC before payment is issued.\n\n# KYC Requirement\n\nThe submission of KYC information is a requirement for payout processing. Stellar will request the following information in order to pay for successful bug submissions:\n\n* Full name  \n* Date of birth  \n* Proof of address (either a redacted bank statement with address or a recent utility bill)  \n* Copy of Passport or other Government issued ID  \n* Tax form (W-9 / W-8BEN / W-8BEN-E)\n\nTax information is also required.\n\nParticipants must adhere to the Eligibility Criteria stated in this policy.\n\n# Submission Requirements\n\nA 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:\n\n* A description of the vulnerability and the affected asset  \n* Step by step reproduction (Proof of Concept), including actual requests, responses, or an exploit script  \n* A clear impact statement tied to confidentiality, integrity, or availability  \n* Evidence that the issue is reproducible, such as screenshots, logs, transaction IDs, or a minimal working script\n\nReports 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.\n\n# Best Practices\n\n* 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.  \n* 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.\n\n#Prohibited Activities\n\nThe following activities are prohibited under this program:\n\n* Testing on mainnet or public testnet; all testing must be performed on local instances  \n* Phishing or social engineering attacks against SDF employees, contractors, or users  \n* Denial of service attacks against any SDF-operated or Stellar network infrastructure  \n* Automated scanning or fuzzing that generates significant traffic against production services  \n* Testing against third-party systems, applications, or websites (including SSO providers and CDNs)  \n* Public disclosure of an unpatched vulnerability before receiving express written consent from SDF  \n* Any activities that violate applicable laws or regulations\n\n# Responsible Disclosure\n\nOur 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.\n\nBug 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.\n\n# Report a Bug\n\n* Submit your report at [https://hackerone.com/stellar/reports/new](https://hackerone.com/stellar/reports/new)  \n* Include as much detail as possible, including a description of the issue, its potential impact, and clear reproduction steps or a Proof of Concept  \n* Please allow 3 business days for an initial response before following up\n\n# Legal\n\nParticipation 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](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](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.\n\nYou 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.\n\nSDF 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.\n\nViolation of this policy or any of the terms incorporated by reference may result in removal from the program and forfeiture of any bounty.\n\n# Stellar Terminology Reference\n\nStellar'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.\n\n| Stellar Term | Definition |\n| :---- | :---- |\n| Stellar Consensus Protocol (SCP) | Proof of Agreement mechanism to apply a set of transactions that go into a block. Validators reach consensus through quorum slices — overlapping sets of trusted validators. See [https://stellar.org/learn/stellar-consensus-protocol](https://stellar.org/learn/stellar-consensus-protocol) and [https://developers.stellar.org/docs/learn/fundamentals/stellar-consensus-protocol](https://developers.stellar.org/docs/learn/fundamentals/stellar-consensus-protocol) |\n| stellar-core | Reference implementation of the Stellar Consensus Protocol (SCP). Maintains the ledger, proposes/votes on transactions via SCP, applies the block, and publishes ledger updates. See [https://github.com/stellar/stellar-core/tree/master/docs](https://github.com/stellar/stellar-core/tree/master/docs) |\n| Soroban runtime | Rust contract-environment interface and host implementation for Soroban. |\n| Tier-1 Validator | Publicly identified validator organizations trusted by most of the network. They carry network safety and liveness. See [https://developers.stellar.org/docs/validators/tier-1-orgs](https://developers.stellar.org/docs/validators/tier-1-orgs) |\n| Quorum Slice Set | The set of validators a node trusts for consensus. Each validator defines its own quorum slice. Quorum intersection across slices ensures network agreement. |\n| Node blocking set | Any set of nodes in a quorum set that prevent a node from reaching agreement. Any security issue arising from collusion of a node blocking set is out of scope for the bug bounty program. |\n| Overlay Network | Peer-to-peer network connecting stellar-core nodes. Handles message broadcast, flow control, and peer management. |\n| Transaction Set | The batch of transactions proposed by a leader node and agreed upon by SCP. Apply order is shuffled to mitigate front-running. |\n| Ledger | Represents the state of the Stellar network at a point in time. It is shared across all stellar-core nodes in the network and contains the list of accounts, account balances, orders on the distributed exchange, smart contract code and data, etc. |\n| Fee Pool | Non-circulating XLM collected from transaction fees. It is not redistributed but may change in the future. |\n| Surge Pricing | When operations exceed capacity (\\~1,000 ops/ledger), or if there is competition between smart contract transactions for a particular resource like CPU instructions, ledger entry accesses (reads and writes), ledger IO (bytes read and bytes written), and the total size of transactions to be applied. See [https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering\\#surge-pricing](https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering#surge-pricing) |\n| Smart contract metering | Resource accounting system that measures and charges for computational resources during smart contract execution. See [https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering](https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering) |\n| Rent | Storing smart contract executable and its corresponding data on chain requires rent to be paid so that these entries are considered live until their Time-to-live (TTL) ledger. See [https://developers.stellar.org/docs/learn/fundamentals/contract-development/storage/state-archival\\#ttl](https://developers.stellar.org/docs/learn/fundamentals/contract-development/storage/state-archival#ttl) |\n| Herder | The SCP driver subclass inside stellar-core that bridges consensus with the overlay and ledger manager. |\n| Catchup / Replay | Process where a node downloads and replays missed ledgers to sync with the network. |\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-05-15T18:31:37.032Z"},{"id":3774065,"new_policy":"## Overview\n\nThe 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.\n\nStellar 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.\n\n#Program Transition\n\nEffective 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.\n\n# Primacy of Rules\n\nStellar adheres to the Primacy of Rules. The whole bug bounty program is run strictly under the terms and conditions stated within this page.\n\n# Scope\n\nThis 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).\n\n## In scope — Standard reward scale\n\nOpen-source repositories:\n\n* All open-source projects under the [Stellar GitHub organization](https://github.com/orgs/stellar/repositories), unless a repository explicitly states that it is out of scope or falls under the Protocol and Core Carveout below\n\nOnline services, apps, and websites:\n\n* [https://www.stellar.org](https://www.stellar.org)  \n* [https://www.stellar.org/account-viewer](https://www.stellar.org/account-viewer)  \n* [https://launch.stellar.org](https://launch.stellar.org)  \n* [https://developers.stellar.org](https://developers.stellar.org)  \n* [https://communityfund.stellar.org](https://communityfund.stellar.org)\n\n## In scope — Protocol and Core Carveout (alternative reward scale)\n\nThe following assets are in scope at the alternative Protocol and Core Carveout reward scale:\n\n* [stellar-core](https://github.com/stellar/stellar-core) — Reference implementation of the Stellar Consensus Protocol  \n* [bytes-lit](https://github.com/stellar/bytes-lit) — Bytes array library\n* [rs-stellar-strkey](https://github.com/stellar/rs-stellar-strkey) — Rust strkeys library\n* [stellar-cli](https://github.com/stellar/stellar-cli) — Soroban CLI\n* [rs-stellar-xdr](https://github.com/stellar/rs-stellar-xdr) — Rust XDR library\n* [rs-soroban-env](https://github.com/stellar/rs-soroban-env) — Soroban contract engine environment\n* [crate-git-revision](https://github.com/stellar/crate-git-revision) — Rust crate git version management library\n* [wasmi](https://github.com/stellar/wasmi) — Wasmi fork\n* [rs-soroban-sdk](https://github.com/stellar/rs-soroban-sdk) — Soroban Rust SDK\n* [js-soroban-client](https://github.com/stellar/js-soroban-client) — Soroban JS Client\n\n## Out of scope\n\n* Archived GitHub repositories and projects  \n* GitHub repository forks  \n* Repositories that explicitly state they are out of scope  \n* Vulnerabilities affecting third-party applications that consume Stellar APIs\n* Any security issue arising from collusion of node blocking set is out of scope for bug bounty programs.\n* Any exploit that requires a quorum of validators.\n* 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.\n* Any feature behind a BUILD_TESTS flag is out of scope.\n* All test files are out of scope.\n* Offline commands are out of scope.\n* Issues that depend on malicious or incorrect data from external data providers used by tools such as Lab, CLI, or similar interfaces.\n\n# Eligibility\n\nGenerally 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.\n\nIn general, anything with the potential for financial loss or data breach is considered sufficiently severe, including:\n\n* Implementation bugs that can lead to financial loss  \n* Access to our production servers  \n* Remote Code Execution  \n* 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  \n* Vulnerabilities matching the impact categories listed in the Protocol and Core Carveout severity matrix below\n\nThe following reports are submitted very often and will generally be marked as Not Applicable:\n\n* SPF or DMARC issues  \n* CORS headers on endpoints that are intentionally accessible from other domains  \n* Issues with third party services we use, such as Mailgun or Segment  \n* Logout CSRF  \n* Vulnerabilities in third party libraries without a working exploit against our applications or servers  \n* Publicly readable AWS S3 buckets containing Stellar ledger history, because this data is public  \n* Content Delivery Network bypass\n\nIn general, the following would **not** meet the threshold for severity and may be marked as **Not Applicable**:\n\n* Version disclosure  \n* Missing security headers  \n* Cookies without the secure flag  \n* Recently disclosed 0-day vulnerabilities without demonstrated impact to our environment  \n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on an in-scope Stellar property  \n* Vulnerabilities that depend on physical access, social engineering, spam, or DDoS  \n* Vulnerabilities affecting outdated or unpatched browsers  \n* Vulnerabilities in third party applications that make use of Stellar APIs  \n* Reports that have not been responsibly investigated and documented  \n* Bugs already known to us, or already reported by another researcher, where the reward goes to the first valid reporter  \n* Issues that are not reproducible  \n* Issues that we cannot reasonably be expected to remediate  \n* Archived GitHub repositories or projects  \n* GitHub repository forks  \n* DoS vectors requiring brute-force paid transaction flooding (economically expensive, out of scope)  \n* Network settings causing out-of-bounds issues, since settings are manually proposed and evaluated by validators  \n* Security issues arising from collusion of a node blocking set\n\n# Rewards\n\nWe 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.\n\nThe reward scale that applies to a report depends on which assets are affected:\n\n* The **Standard reward scale** applies to all in-scope assets except those listed under the Protocol and Core Carveout.  \n* The **Protocol and Core Carveout reward scale** applies to vulnerabilities in `stellar-core`, `stellar-protocol`, and the Soroban runtime/host code.\n\n## Standard reward scale\n\nThe 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.\n\n* Critical: 0 to 25,000 points  \n* High: 0 to 15,000 points  \n* Medium: 0 to 10,000 points  \n* Low: 0 to 2,000 points  \n* Note: 0 to 500 points\n\n1 point currently corresponds to 1 USD, payable in lumens (XLM), though this may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to its maximum practical impact.\n\n## Protocol and Core Carveout reward scale\n\nThe following alternative reward scale applies exclusively to vulnerabilities in the carveout scope mentioned above:\n\n* Critical: 0 to 25,000 points  \n* High: 0 to 15,000  \n* Medium: 0 to 10,000  \n* Low: 0 to 1,000\n\n### Critical reward calculation for carveout assets\n\nFor 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.\n\n### Severity classification for carveout assets\n\nFor carveout assets, severity is determined using the OWASP risk rating methodology rather than CVSS. To use the calculator:\n\n1. Determine the severity by looking at the *Impact Category* that best matches the vulnerability in the severity lookup matrix below.  \n2. Evaluate how easy 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).\n\n\\* 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.\n\n#### Severity lookup matrix\n\n| Impact Category | Trivial to exploit | Requires tier-1 access |\n| :---- | :---: | :---: |\n| Direct theft / loss of funds | Critical | Critical |\n| Total network halt | Critical | High \\- Medium (mitigation dependent) |\n| Affects XLM supply integrity (minting, burning) | Critical | High |\n| Fund freeze | Critical | High |\n| Observable non-determinism causing divergence | Critical | High |\n| Fee pool exploits | High | Medium |\n| Soroban runtime bug putting realistic Smart contracts at risk of plausible malfunction | High | \\- |\n| Increase resource consumption that can cause slowdown of 5 seconds or more | Medium | Low |\n| Increase memory consumption more than 20% of the recommended hardware specification | Medium | Low |\n| Soroban simulation library causing Stellar RPC crash | Medium | \\- |\n| MEV / transaction ordering manipulation | Medium | \\- |\n| Bypass Soroban rent fee mechanism paying less than 20% of actual | Medium | Low |\n| Shut down of greater than 30% of watcher nodes (network unaffected) | Medium | Low |\n| Bypass Soroban rent fee mechanism paying between 21% to 99% | Low | Informational |\n| DoS by less than or equal to 30% consumption of CPU/Memory resources | Low | Informational |\n| Increase resource consumption that can cause slowdown of more than 1 second but less than 5 seconds | Low | Informational |\n| Increase memory consumption more than 5% but less than 20% of the recommended hardware specification | Low | Informational |\n| Shut down of 10% to 30% of (network unaffected) | Low | Informational |\n| Minor metering discrepancy that can cause slowdown between 2 and 5 seconds | Low | Informational |\n| Trivial metering discrepancy that can cause slowdown less than 2 seconds | Informational | Informational |\n\n#### Severity, impact and examples\n\nThe 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](https://developers.stellar.org/docs/validators/admin-guide/prerequisites#hardware-requirements).\n\n| Severity | Impact Description | Concrete Example |\n| :---: | :---- | :---- |\n| Critical | Direct theft or irreversible loss of funds excluding fees burned | \\*Payout would be a % of loss of funds |\n| Critical | Total network halt — network cannot confirm new transactions | Example 1: Auth stack exhaustion causing all validator nodes to crash. Example 2: XDR recursion depth limits causing stack overflow. Example 3: Oversized duplicate SCP message crashing a node via flow control invariant abort. \\*Mitigation mechanism determines the severity. If it is easy to mitigate by removing a Tier-1 from another's config then it is medium severity. If a new software package is needed then it is high severity. |\n| Critical | Minting of native asset (XLM) outside of protocol rules | Integer overflow in fee validation enabling creation of XLM from nothing |\n| Critical | Permanent freezing of funds | Bug in Soroban contract storage that makes persistent entries permanently inaccessible |\n| Critical | Observable non-determinism causing divergence | Floating-point or platform-dependent behavior in Soroban host functions producing different ledger hashes across validator architectures (e.g., ARM vs x86) |\n| High | A malicious Tier-1 validator able to halt the entire network | A tier-1 validator crafting malformed SCP messages that cause all other tier-1 nodes to crash |\n| High | Fee pool exploits | A user submits a transaction that drains the Fee Pool thus stealing XLM |\n| High | Soroban runtime bug putting realistic Smart contracts at risk of plausible malfunction | Examples: unauthorized call gets authorized, SCVal stored in storage gets corrupted, error code gets lost, cryptographic function \"validates\" invalid input, wrong contract gets invoked, wrong event emitted. |\n| Medium | Metering discrepancy in Soroban that can lead to resource exhaustion | Soroban host functions undercharging CPU or memory resources by 50 times such that an attacker can produce measurable slowdown |\n| Medium | Increase resource consumption that can cause slowdown of 5 seconds or more | Specially crafted Soroban contract invocation that triggers excessive disk I/O during ledger close, slowing all validators |\n| Medium | Increase memory consumption more than 20% of the recommended hardware specification |  |\n| Medium | Soroban simulation library bug causing Stellar RPC to crash | Bug in Soroban simulation library causing Stellar RPC nodes to crash when running simulation |\n| Medium | MEV attack or any transaction ordering manipulation | Bug where attacker can deterministically cause a transaction to execute before a victim transaction |\n| Low | Shut down of greater than 30% of watcher nodes – network is unaffected and continues to close ledgers | Peer-to-peer flood message causing non-tier-1 watchers to disconnect |\n| Low | DoS by causing less than 30% of CPU/memory resource consumption on nodes outside of the declared limits and without brute force | Specially crafted Soroban contract invocation that triggers moderate disk I/O during ledger close, slowing all validators |\n| Low | Bypass of transaction fee mechanism enabling free or severely underpriced transactions | TxSet baseFee integer overflow bypassing fee validation entirely |\n| Low | Exploit Soroban rent fee mechanism | Any exploit that can get access to free rent for persistent Soroban entries. |\n| Informational | Minor metering discrepancy causing undercounting of Soroban transactions | Undercharging in Soroban host function that cannot be exploited to DoS the network or cause any significant slowdown. |\n| Informational | DoS vector requiring brute-force (paid transaction flooding) | Submitting thousands of max-fee transactions to slow ledger close — economically expensive and out of scope |\n| Informational | Network settings causing out of bounds issues | Settings are manually proposed and thoroughly evaluated by validators so there is no risk of going out of bounds |\n| Informational | New nodes unable to join the network | Corrupt history causing a new node to not be able to join |\n\n## Reward payment terms\n\nRewards 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\n\nTo receive a payout, researchers must successfully complete valid KYC before payment is issued.\n\n# KYC Requirement\n\nThe submission of KYC information is a requirement for payout processing. Stellar will request the following information in order to pay for successful bug submissions:\n\n* Full name  \n* Date of birth  \n* Proof of address (either a redacted bank statement with address or a recent utility bill)  \n* Copy of Passport or other Government issued ID  \n* Tax form (W-9 / W-8BEN / W-8BEN-E)\n\nTax information is also required.\n\nParticipants must adhere to the Eligibility Criteria stated in this policy.\n\n# Submission Requirements\n\nA 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:\n\n* A description of the vulnerability and the affected asset  \n* Step by step reproduction (Proof of Concept), including actual requests, responses, or an exploit script  \n* A clear impact statement tied to confidentiality, integrity, or availability  \n* Evidence that the issue is reproducible, such as screenshots, logs, transaction IDs, or a minimal working script\n\nReports 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.\n\n# Best Practices\n\n* 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.  \n* 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.\n\n#Prohibited Activities\n\nThe following activities are prohibited under this program:\n\n* Testing on mainnet or public testnet; all testing must be performed on local instances  \n* Phishing or social engineering attacks against SDF employees, contractors, or users  \n* Denial of service attacks against any SDF-operated or Stellar network infrastructure  \n* Automated scanning or fuzzing that generates significant traffic against production services  \n* Testing against third-party systems, applications, or websites (including SSO providers and CDNs)  \n* Public disclosure of an unpatched vulnerability before receiving express written consent from SDF  \n* Any activities that violate applicable laws or regulations\n\n# Responsible Disclosure\n\nOur 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.\n\nBug 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.\n\n# Report a Bug\n\n* Submit your report at [https://hackerone.com/stellar/reports/new](https://hackerone.com/stellar/reports/new)  \n* Include as much detail as possible, including a description of the issue, its potential impact, and clear reproduction steps or a Proof of Concept  \n* Please allow 3 business days for an initial response before following up\n\n# Legal\n\nParticipation 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](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](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.\n\nYou 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.\n\nSDF 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.\n\nViolation of this policy or any of the terms incorporated by reference may result in removal from the program and forfeiture of any bounty.\n\n# Stellar Terminology Reference\n\nStellar'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.\n\n| Stellar Term | Definition |\n| :---- | :---- |\n| Stellar Consensus Protocol (SCP) | Proof of Agreement mechanism to apply a set of transactions that go into a block. Validators reach consensus through quorum slices — overlapping sets of trusted validators. See [https://stellar.org/learn/stellar-consensus-protocol](https://stellar.org/learn/stellar-consensus-protocol) and [https://developers.stellar.org/docs/learn/fundamentals/stellar-consensus-protocol](https://developers.stellar.org/docs/learn/fundamentals/stellar-consensus-protocol) |\n| stellar-core | Reference implementation of the Stellar Consensus Protocol (SCP). Maintains the ledger, proposes/votes on transactions via SCP, applies the block, and publishes ledger updates. See [https://github.com/stellar/stellar-core/tree/master/docs](https://github.com/stellar/stellar-core/tree/master/docs) |\n| Soroban runtime | Rust contract-environment interface and host implementation for Soroban. |\n| Tier-1 Validator | Publicly identified validator organizations trusted by most of the network. They carry network safety and liveness. See [https://developers.stellar.org/docs/validators/tier-1-orgs](https://developers.stellar.org/docs/validators/tier-1-orgs) |\n| Quorum Slice Set | The set of validators a node trusts for consensus. Each validator defines its own quorum slice. Quorum intersection across slices ensures network agreement. |\n| Node blocking set | Any set of nodes in a quorum set that prevent a node from reaching agreement. Any security issue arising from collusion of a node blocking set is out of scope for the bug bounty program. |\n| Overlay Network | Peer-to-peer network connecting stellar-core nodes. Handles message broadcast, flow control, and peer management. |\n| Transaction Set | The batch of transactions proposed by a leader node and agreed upon by SCP. Apply order is shuffled to mitigate front-running. |\n| Ledger | Represents the state of the Stellar network at a point in time. It is shared across all stellar-core nodes in the network and contains the list of accounts, account balances, orders on the distributed exchange, smart contract code and data, etc. |\n| Fee Pool | Non-circulating XLM collected from transaction fees. It is not redistributed but may change in the future. |\n| Surge Pricing | When operations exceed capacity (\\~1,000 ops/ledger), or if there is competition between smart contract transactions for a particular resource like CPU instructions, ledger entry accesses (reads and writes), ledger IO (bytes read and bytes written), and the total size of transactions to be applied. See [https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering\\#surge-pricing](https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering#surge-pricing) |\n| Smart contract metering | Resource accounting system that measures and charges for computational resources during smart contract execution. See [https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering](https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering) |\n| Rent | Storing smart contract executable and its corresponding data on chain requires rent to be paid so that these entries are considered live until their Time-to-live (TTL) ledger. See [https://developers.stellar.org/docs/learn/fundamentals/contract-development/storage/state-archival\\#ttl](https://developers.stellar.org/docs/learn/fundamentals/contract-development/storage/state-archival#ttl) |\n| Herder | The SCP driver subclass inside stellar-core that bridges consensus with the overlay and ledger manager. |\n| Catchup / Replay | Process where a node downloads and replays missed ledgers to sync with the network. |\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-05-12T18:02:05.140Z"},{"id":3773868,"new_policy":"## Overview\n\nThe 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.\n\nStellar 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.\n\n#Program Transition\n\nEffective 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.\n\n# Primacy of Rules\n\nStellar adheres to the Primacy of Rules. The whole bug bounty program is run strictly under the terms and conditions stated within this page.\n\n# Scope\n\nThis 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).\n\n## In scope — Standard reward scale\n\nOpen-source repositories:\n\n* All open-source projects under the [Stellar GitHub organization](https://github.com/orgs/stellar/repositories), unless a repository explicitly states that it is out of scope or falls under the Protocol and Core Carveout below\n\nOnline services, apps, and websites:\n\n* [https://www.stellar.org](https://www.stellar.org)  \n* [https://www.stellar.org/account-viewer](https://www.stellar.org/account-viewer)  \n* [https://launch.stellar.org](https://launch.stellar.org)  \n* [https://developers.stellar.org](https://developers.stellar.org)  \n* [https://communityfund.stellar.org](https://communityfund.stellar.org)\n\n## In scope — Protocol and Core Carveout (alternative reward scale)\n\nThe following assets are in scope at the alternative Protocol and Core Carveout reward scale:\n\n* [stellar-core](https://github.com/stellar/stellar-core) — Reference implementation of the Stellar Consensus Protocol  \n* [bytes-lit](https://github.com/stellar/bytes-lit) — Bytes array library\n* [rs-stellar-strkey](https://github.com/stellar/rs-stellar-strkey) — Rust strkeys library\n* [stellar-cli](https://github.com/stellar/stellar-cli) — Soroban CLI\n* [rs-stellar-xdr](https://github.com/stellar/rs-stellar-xdr) — Rust XDR library\n* [rs-soroban-env](https://github.com/stellar/rs-soroban-env) — Soroban contract engine environment\n* [crate-git-revision](https://github.com/stellar/crate-git-revision) — Rust crate git version management library\n* [wasmi](https://github.com/stellar/wasmi) — Wasmi fork\n* [rs-soroban-sdk](https://github.com/stellar/rs-soroban-sdk) — Soroban Rust SDK\n* [js-soroban-client](https://github.com/stellar/js-soroban-client) — Soroban JS Client\n\n## Out of scope\n\n* Archived GitHub repositories and projects  \n* GitHub repository forks  \n* Repositories that explicitly state they are out of scope  \n* Vulnerabilities affecting third-party applications that consume Stellar APIs\n\n# Eligibility\n\nGenerally 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.\n\nIn general, anything with the potential for financial loss or data breach is considered sufficiently severe, including:\n\n* Implementation bugs that can lead to financial loss  \n* Access to our production servers  \n* Remote Code Execution  \n* 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  \n* Vulnerabilities matching the impact categories listed in the Protocol and Core Carveout severity matrix below\n\nThe following reports are submitted very often and will generally be marked as Not Applicable:\n\n* SPF or DMARC issues  \n* CORS headers on endpoints that are intentionally accessible from other domains  \n* Issues with third party services we use, such as Mailgun or Segment  \n* Logout CSRF  \n* Vulnerabilities in third party libraries without a working exploit against our applications or servers  \n* Publicly readable AWS S3 buckets containing Stellar ledger history, because this data is public  \n* Content Delivery Network bypass\n\nIn general, the following would **not** meet the threshold for severity and may be marked as **Not Applicable**:\n\n* Version disclosure  \n* Missing security headers  \n* Cookies without the secure flag  \n* Recently disclosed 0-day vulnerabilities without demonstrated impact to our environment  \n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on an in-scope Stellar property  \n* Vulnerabilities that depend on physical access, social engineering, spam, or DDoS  \n* Vulnerabilities affecting outdated or unpatched browsers  \n* Vulnerabilities in third party applications that make use of Stellar APIs  \n* Reports that have not been responsibly investigated and documented  \n* Bugs already known to us, or already reported by another researcher, where the reward goes to the first valid reporter  \n* Issues that are not reproducible  \n* Issues that we cannot reasonably be expected to remediate  \n* Archived GitHub repositories or projects  \n* GitHub repository forks  \n* DoS vectors requiring brute-force paid transaction flooding (economically expensive, out of scope)  \n* Network settings causing out-of-bounds issues, since settings are manually proposed and evaluated by validators  \n* Security issues arising from collusion of a node blocking set\n\n# Rewards\n\nWe 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.\n\nThe reward scale that applies to a report depends on which assets are affected:\n\n* The **Standard reward scale** applies to all in-scope assets except those listed under the Protocol and Core Carveout.  \n* The **Protocol and Core Carveout reward scale** applies to vulnerabilities in `stellar-core`, `stellar-protocol`, and the Soroban runtime/host code.\n\n## Standard reward scale\n\nThe 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.\n\n* Critical: 0 to 25,000 points  \n* High: 0 to 15,000 points  \n* Medium: 0 to 10,000 points  \n* Low: 0 to 2,000 points  \n* Note: 0 to 500 points\n\n1 point currently corresponds to 1 USD, payable in lumens (XLM), though this may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to its maximum practical impact.\n\n## Protocol and Core Carveout reward scale\n\nThe following alternative reward scale applies exclusively to vulnerabilities in the carveout scope mentioned above:\n\n* Critical: 0 to 25,000 points  \n* High: 0 to 15,000  \n* Medium: 0 to 10,000  \n* Low: 0 to 1,000\n\n### Critical reward calculation for carveout assets\n\nFor 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.\n\n### Severity classification for carveout assets\n\nFor carveout assets, severity is determined using the OWASP risk rating methodology rather than CVSS. To use the calculator:\n\n1. Determine the severity by looking at the *Impact Category* that best matches the vulnerability in the severity lookup matrix below.  \n2. Evaluate how easy 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).\n\n\\* 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.\n\n#### Severity lookup matrix\n\n| Impact Category | Trivial to exploit | Requires tier-1 access |\n| :---- | :---: | :---: |\n| Direct theft / loss of funds | Critical | Critical |\n| Total network halt | Critical | High \\- Medium (mitigation dependent) |\n| Affects XLM supply integrity (minting, burning) | Critical | High |\n| Fund freeze | Critical | High |\n| Observable non-determinism causing divergence | Critical | High |\n| Fee pool exploits | High | Medium |\n| Soroban runtime bug putting realistic Smart contracts at risk of plausible malfunction | High | \\- |\n| Increase resource consumption that can cause slowdown of 5 seconds or more | Medium | Low |\n| Increase memory consumption more than 20% of the recommended hardware specification | Medium | Low |\n| Soroban simulation library causing Stellar RPC crash | Medium | \\- |\n| MEV / transaction ordering manipulation | Medium | \\- |\n| Bypass Soroban rent fee mechanism paying less than 20% of actual | Medium | Low |\n| Shut down of greater than 30% of watcher nodes (network unaffected) | Medium | Low |\n| Bypass Soroban rent fee mechanism paying between 21% to 99% | Low | Informational |\n| DoS by less than or equal to 30% consumption of CPU/Memory resources | Low | Informational |\n| Increase resource consumption that can cause slowdown of more than 1 second but less than 5 seconds | Low | Informational |\n| Increase memory consumption more than 5% but less than 20% of the recommended hardware specification | Low | Informational |\n| Shut down of 10% to 30% of (network unaffected) | Low | Informational |\n| Minor metering discrepancy that can cause slowdown between 2 and 5 seconds | Low | Informational |\n| Trivial metering discrepancy that can cause slowdown less than 2 seconds | Informational | Informational |\n\n#### Severity, impact and examples\n\nThe 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](https://developers.stellar.org/docs/validators/admin-guide/prerequisites#hardware-requirements).\n\n| Severity | Impact Description | Concrete Example |\n| :---: | :---- | :---- |\n| Critical | Direct theft or irreversible loss of funds excluding fees burned | \\*Payout would be a % of loss of funds |\n| Critical | Total network halt — network cannot confirm new transactions | Example 1: Auth stack exhaustion causing all validator nodes to crash. Example 2: XDR recursion depth limits causing stack overflow. Example 3: Oversized duplicate SCP message crashing a node via flow control invariant abort. \\*Mitigation mechanism determines the severity. If it is easy to mitigate by removing a Tier-1 from another's config then it is medium severity. If a new software package is needed then it is high severity. |\n| Critical | Minting of native asset (XLM) outside of protocol rules | Integer overflow in fee validation enabling creation of XLM from nothing |\n| Critical | Permanent freezing of funds | Bug in Soroban contract storage that makes persistent entries permanently inaccessible |\n| Critical | Observable non-determinism causing divergence | Floating-point or platform-dependent behavior in Soroban host functions producing different ledger hashes across validator architectures (e.g., ARM vs x86) |\n| High | A malicious Tier-1 validator able to halt the entire network | A tier-1 validator crafting malformed SCP messages that cause all other tier-1 nodes to crash |\n| High | Fee pool exploits | A user submits a transaction that drains the Fee Pool thus stealing XLM |\n| High | Soroban runtime bug putting realistic Smart contracts at risk of plausible malfunction | Examples: unauthorized call gets authorized, SCVal stored in storage gets corrupted, error code gets lost, cryptographic function \"validates\" invalid input, wrong contract gets invoked, wrong event emitted. |\n| Medium | Metering discrepancy in Soroban that can lead to resource exhaustion | Soroban host functions undercharging CPU or memory resources by 50 times such that an attacker can produce measurable slowdown |\n| Medium | Increase resource consumption that can cause slowdown of 5 seconds or more | Specially crafted Soroban contract invocation that triggers excessive disk I/O during ledger close, slowing all validators |\n| Medium | Increase memory consumption more than 20% of the recommended hardware specification |  |\n| Medium | Soroban simulation library bug causing Stellar RPC to crash | Bug in Soroban simulation library causing Stellar RPC nodes to crash when running simulation |\n| Medium | MEV attack or any transaction ordering manipulation | Bug where attacker can deterministically cause a transaction to execute before a victim transaction |\n| Low | Shut down of greater than 30% of watcher nodes – network is unaffected and continues to close ledgers | Peer-to-peer flood message causing non-tier-1 watchers to disconnect |\n| Low | DoS by causing less than 30% of CPU/memory resource consumption on nodes outside of the declared limits and without brute force | Specially crafted Soroban contract invocation that triggers moderate disk I/O during ledger close, slowing all validators |\n| Low | Bypass of transaction fee mechanism enabling free or severely underpriced transactions | TxSet baseFee integer overflow bypassing fee validation entirely |\n| Low | Exploit Soroban rent fee mechanism | Any exploit that can get access to free rent for persistent Soroban entries. |\n| Informational | Minor metering discrepancy causing undercounting of Soroban transactions | Undercharging in Soroban host function that cannot be exploited to DoS the network or cause any significant slowdown. |\n| Informational | DoS vector requiring brute-force (paid transaction flooding) | Submitting thousands of max-fee transactions to slow ledger close — economically expensive and out of scope |\n| Informational | Network settings causing out of bounds issues | Settings are manually proposed and thoroughly evaluated by validators so there is no risk of going out of bounds |\n| Informational | New nodes unable to join the network | Corrupt history causing a new node to not be able to join |\n\n## Reward payment terms\n\nRewards 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\n\nTo receive a payout, researchers must successfully complete valid KYC before payment is issued.\n\n# KYC Requirement\n\nThe submission of KYC information is a requirement for payout processing. Stellar will request the following information in order to pay for successful bug submissions:\n\n* Full name  \n* Date of birth  \n* Proof of address (either a redacted bank statement with address or a recent utility bill)  \n* Copy of Passport or other Government issued ID  \n* Tax form (W-9 / W-8BEN / W-8BEN-E)\n\nTax information is also required.\n\nParticipants must adhere to the Eligibility Criteria stated in this policy.\n\n# Submission Requirements\n\nA 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:\n\n* A description of the vulnerability and the affected asset  \n* Step by step reproduction (Proof of Concept), including actual requests, responses, or an exploit script  \n* A clear impact statement tied to confidentiality, integrity, or availability  \n* Evidence that the issue is reproducible, such as screenshots, logs, transaction IDs, or a minimal working script\n\nReports 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.\n\n# Best Practices\n\n* 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.  \n* 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.\n\n#Prohibited Activities\n\nThe following activities are prohibited under this program:\n\n* Testing on mainnet or public testnet; all testing must be performed on local instances  \n* Phishing or social engineering attacks against SDF employees, contractors, or users  \n* Denial of service attacks against any SDF-operated or Stellar network infrastructure  \n* Automated scanning or fuzzing that generates significant traffic against production services  \n* Testing against third-party systems, applications, or websites (including SSO providers and CDNs)  \n* Public disclosure of an unpatched vulnerability before receiving express written consent from SDF  \n* Any activities that violate applicable laws or regulations\n\n# Responsible Disclosure\n\nOur 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.\n\nBug 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.\n\n# Report a Bug\n\n* Submit your report at [https://hackerone.com/stellar/reports/new](https://hackerone.com/stellar/reports/new)  \n* Include as much detail as possible, including a description of the issue, its potential impact, and clear reproduction steps or a Proof of Concept  \n* Please allow 3 business days for an initial response before following up\n\n# Legal\n\nParticipation 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](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](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.\n\nYou 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.\n\nSDF 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.\n\nViolation of this policy or any of the terms incorporated by reference may result in removal from the program and forfeiture of any bounty.\n\n# Stellar Terminology Reference\n\nStellar'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.\n\n| Stellar Term | Definition |\n| :---- | :---- |\n| Stellar Consensus Protocol (SCP) | Proof of Agreement mechanism to apply a set of transactions that go into a block. Validators reach consensus through quorum slices — overlapping sets of trusted validators. See [https://stellar.org/learn/stellar-consensus-protocol](https://stellar.org/learn/stellar-consensus-protocol) and [https://developers.stellar.org/docs/learn/fundamentals/stellar-consensus-protocol](https://developers.stellar.org/docs/learn/fundamentals/stellar-consensus-protocol) |\n| stellar-core | Reference implementation of the Stellar Consensus Protocol (SCP). Maintains the ledger, proposes/votes on transactions via SCP, applies the block, and publishes ledger updates. See [https://github.com/stellar/stellar-core/tree/master/docs](https://github.com/stellar/stellar-core/tree/master/docs) |\n| Soroban runtime | Rust contract-environment interface and host implementation for Soroban. |\n| Tier-1 Validator | Publicly identified validator organizations trusted by most of the network. They carry network safety and liveness. See [https://developers.stellar.org/docs/validators/tier-1-orgs](https://developers.stellar.org/docs/validators/tier-1-orgs) |\n| Quorum Slice Set | The set of validators a node trusts for consensus. Each validator defines its own quorum slice. Quorum intersection across slices ensures network agreement. |\n| Node blocking set | Any set of nodes in a quorum set that prevent a node from reaching agreement. Any security issue arising from collusion of a node blocking set is out of scope for the bug bounty program. |\n| Overlay Network | Peer-to-peer network connecting stellar-core nodes. Handles message broadcast, flow control, and peer management. |\n| Transaction Set | The batch of transactions proposed by a leader node and agreed upon by SCP. Apply order is shuffled to mitigate front-running. |\n| Ledger | Represents the state of the Stellar network at a point in time. It is shared across all stellar-core nodes in the network and contains the list of accounts, account balances, orders on the distributed exchange, smart contract code and data, etc. |\n| Fee Pool | Non-circulating XLM collected from transaction fees. It is not redistributed but may change in the future. |\n| Surge Pricing | When operations exceed capacity (\\~1,000 ops/ledger), or if there is competition between smart contract transactions for a particular resource like CPU instructions, ledger entry accesses (reads and writes), ledger IO (bytes read and bytes written), and the total size of transactions to be applied. See [https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering\\#surge-pricing](https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering#surge-pricing) |\n| Smart contract metering | Resource accounting system that measures and charges for computational resources during smart contract execution. See [https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering](https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering) |\n| Rent | Storing smart contract executable and its corresponding data on chain requires rent to be paid so that these entries are considered live until their Time-to-live (TTL) ledger. See [https://developers.stellar.org/docs/learn/fundamentals/contract-development/storage/state-archival\\#ttl](https://developers.stellar.org/docs/learn/fundamentals/contract-development/storage/state-archival#ttl) |\n| Herder | The SCP driver subclass inside stellar-core that bridges consensus with the overlay and ledger manager. |\n| Catchup / Replay | Process where a node downloads and replays missed ledgers to sync with the network. |\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-05-08T15:18:51.081Z"},{"id":3773817,"new_policy":"## Overview\n\nThe 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.\n\nStellar 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.\n\n#Program Transition\n\nEffective 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.\n\n# Primacy of Rules\n\nStellar adheres to the Primacy of Rules. The whole bug bounty program is run strictly under the terms and conditions stated within this page.\n\n# Scope\n\nThis 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).\n\n## In scope — Standard reward scale\n\nOpen-source repositories:\n\n* All open-source projects under the [Stellar GitHub organization](https://github.com/orgs/stellar/repositories), unless a repository explicitly states that it is out of scope or falls under the Protocol and Core Carveout below\n\nOnline services, apps, and websites:\n\n* [https://www.stellar.org](https://www.stellar.org)  \n* [https://www.stellar.org/account-viewer](https://www.stellar.org/account-viewer)  \n* [https://launch.stellar.org](https://launch.stellar.org)  \n* [https://developers.stellar.org](https://developers.stellar.org)  \n* [https://communityfund.stellar.org](https://communityfund.stellar.org)\n\n## In scope — Protocol and Core Carveout (alternative reward scale)\n\nThe following assets are in scope at the alternative Protocol and Core Carveout reward scale:\n\n* [stellar-core](https://github.com/stellar/stellar-core) — Reference implementation of the Stellar Consensus Protocol  \n* [stellar-protocol](https://github.com/stellar/stellar-protocol) — Stellar protocol specifications  \n* The Soroban runtime and host code — Rust contract-environment interface and host implementation for Soroban\n\n## Out of scope\n\n* Archived GitHub repositories and projects  \n* GitHub repository forks  \n* Repositories that explicitly state they are out of scope  \n* Vulnerabilities affecting third-party applications that consume Stellar APIs\n\n# Eligibility\n\nGenerally 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.\n\nIn general, anything with the potential for financial loss or data breach is considered sufficiently severe, including:\n\n* Implementation bugs that can lead to financial loss  \n* Access to our production servers  \n* Remote Code Execution  \n* 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  \n* Vulnerabilities matching the impact categories listed in the Protocol and Core Carveout severity matrix below\n\nThe following reports are submitted very often and will generally be marked as Not Applicable:\n\n* SPF or DMARC issues  \n* CORS headers on endpoints that are intentionally accessible from other domains  \n* Issues with third party services we use, such as Mailgun or Segment  \n* Logout CSRF  \n* Vulnerabilities in third party libraries without a working exploit against our applications or servers  \n* Publicly readable AWS S3 buckets containing Stellar ledger history, because this data is public  \n* Content Delivery Network bypass\n\nIn general, the following would **not** meet the threshold for severity and may be marked as **Not Applicable**:\n\n* Version disclosure  \n* Missing security headers  \n* Cookies without the secure flag  \n* Recently disclosed 0-day vulnerabilities without demonstrated impact to our environment  \n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on an in-scope Stellar property  \n* Vulnerabilities that depend on physical access, social engineering, spam, or DDoS  \n* Vulnerabilities affecting outdated or unpatched browsers  \n* Vulnerabilities in third party applications that make use of Stellar APIs  \n* Reports that have not been responsibly investigated and documented  \n* Bugs already known to us, or already reported by another researcher, where the reward goes to the first valid reporter  \n* Issues that are not reproducible  \n* Issues that we cannot reasonably be expected to remediate  \n* Archived GitHub repositories or projects  \n* GitHub repository forks  \n* DoS vectors requiring brute-force paid transaction flooding (economically expensive, out of scope)  \n* Network settings causing out-of-bounds issues, since settings are manually proposed and evaluated by validators  \n* Security issues arising from collusion of a node blocking set\n\n# Rewards\n\nWe 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.\n\nThe reward scale that applies to a report depends on which assets are affected:\n\n* The **Standard reward scale** applies to all in-scope assets except those listed under the Protocol and Core Carveout.  \n* The **Protocol and Core Carveout reward scale** applies to vulnerabilities in `stellar-core`, `stellar-protocol`, and the Soroban runtime/host code.\n\n## Standard reward scale\n\nThe 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.\n\n* Critical: 0 to 25,000 points  \n* High: 0 to 15,000 points  \n* Medium: 0 to 10,000 points  \n* Low: 0 to 2,000 points  \n* Note: 0 to 500 points\n\n1 point currently corresponds to 1 USD, payable in lumens (XLM), though this may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to its maximum practical impact.\n\n## Protocol and Core Carveout reward scale\n\nThe following higher reward scale applies exclusively to vulnerabilities in `stellar-core`, `stellar-protocol`, and the Soroban runtime/host code:\n\n* Critical: 0 to 25,000 points  \n* High: 0 to 15,000  \n* Medium: 0 to 10,000  \n* Low: 0 to 1,000\n\n### Critical reward calculation for carveout assets\n\nFor 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.\n\n### Severity classification for carveout assets\n\nFor carveout assets, severity is determined using the OWASP risk rating methodology rather than CVSS. To use the calculator:\n\n1. Determine the severity by looking at the *Impact Category* that best matches the vulnerability in the severity lookup matrix below.  \n2. Evaluate how easy 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).\n\n\\* 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.\n\n#### Severity lookup matrix\n\n| Impact Category | Trivial to exploit | Requires tier-1 access |\n| :---- | :---: | :---: |\n| Direct theft / loss of funds | Critical | Critical |\n| Total network halt | Critical | High \\- Medium (mitigation dependent) |\n| Affects XLM supply integrity (minting, burning) | Critical | High |\n| Fund freeze | Critical | High |\n| Observable non-determinism causing divergence | Critical | High |\n| Fee pool exploits | High | Medium |\n| Soroban runtime bug putting realistic Smart contracts at risk of plausible malfunction | High | \\- |\n| Increase resource consumption that can cause slowdown of 5 seconds or more | Medium | Low |\n| Increase memory consumption more than 20% of the recommended hardware specification | Medium | Low |\n| Soroban simulation library causing Stellar RPC crash | Medium | \\- |\n| MEV / transaction ordering manipulation | Medium | \\- |\n| Bypass Soroban rent fee mechanism paying less than 20% of actual | Medium | Low |\n| Shut down of greater than 30% of watcher nodes (network unaffected) | Medium | Low |\n| Bypass Soroban rent fee mechanism paying between 21% to 99% | Low | Informational |\n| DoS by less than or equal to 30% consumption of CPU/Memory resources | Low | Informational |\n| Increase resource consumption that can cause slowdown of more than 1 second but less than 5 seconds | Low | Informational |\n| Increase memory consumption more than 5% but less than 20% of the recommended hardware specification | Low | Informational |\n| Shut down of 10% to 30% of (network unaffected) | Low | Informational |\n| Minor metering discrepancy that can cause slowdown between 2 and 5 seconds | Low | Informational |\n| Trivial metering discrepancy that can cause slowdown less than 2 seconds | Informational | Informational |\n\n#### Severity, impact and examples\n\nThe 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](https://developers.stellar.org/docs/validators/admin-guide/prerequisites#hardware-requirements).\n\n| Severity | Impact Description | Concrete Example |\n| :---: | :---- | :---- |\n| Critical | Direct theft or irreversible loss of funds excluding fees burned | \\*Payout would be a % of loss of funds |\n| Critical | Total network halt — network cannot confirm new transactions | Example 1: Auth stack exhaustion causing all validator nodes to crash. Example 2: XDR recursion depth limits causing stack overflow. Example 3: Oversized duplicate SCP message crashing a node via flow control invariant abort. \\*Mitigation mechanism determines the severity. If it is easy to mitigate by removing a Tier-1 from another's config then it is medium severity. If a new software package is needed then it is high severity. |\n| Critical | Minting of native asset (XLM) outside of protocol rules | Integer overflow in fee validation enabling creation of XLM from nothing |\n| Critical | Permanent freezing of funds | Bug in Soroban contract storage that makes persistent entries permanently inaccessible |\n| Critical | Observable non-determinism causing divergence | Floating-point or platform-dependent behavior in Soroban host functions producing different ledger hashes across validator architectures (e.g., ARM vs x86) |\n| High | A malicious Tier-1 validator able to halt the entire network | A tier-1 validator crafting malformed SCP messages that cause all other tier-1 nodes to crash |\n| High | Fee pool exploits | A user submits a transaction that drains the Fee Pool thus stealing XLM |\n| High | Soroban runtime bug putting realistic Smart contracts at risk of plausible malfunction | Examples: unauthorized call gets authorized, SCVal stored in storage gets corrupted, error code gets lost, cryptographic function \"validates\" invalid input, wrong contract gets invoked, wrong event emitted. |\n| Medium | Metering discrepancy in Soroban that can lead to resource exhaustion | Soroban host functions undercharging CPU or memory resources by 50 times such that an attacker can produce measurable slowdown |\n| Medium | Increase resource consumption that can cause slowdown of 5 seconds or more | Specially crafted Soroban contract invocation that triggers excessive disk I/O during ledger close, slowing all validators |\n| Medium | Increase memory consumption more than 20% of the recommended hardware specification |  |\n| Medium | Soroban simulation library bug causing Stellar RPC to crash | Bug in Soroban simulation library causing Stellar RPC nodes to crash when running simulation |\n| Medium | MEV attack or any transaction ordering manipulation | Bug where attacker can deterministically cause a transaction to execute before a victim transaction |\n| Low | Shut down of greater than 30% of watcher nodes – network is unaffected and continues to close ledgers | Peer-to-peer flood message causing non-tier-1 watchers to disconnect |\n| Low | DoS by causing less than 30% of CPU/memory resource consumption on nodes outside of the declared limits and without brute force | Specially crafted Soroban contract invocation that triggers moderate disk I/O during ledger close, slowing all validators |\n| Low | Bypass of transaction fee mechanism enabling free or severely underpriced transactions | TxSet baseFee integer overflow bypassing fee validation entirely |\n| Low | Exploit Soroban rent fee mechanism | Any exploit that can get access to free rent for persistent Soroban entries. |\n| Informational | Minor metering discrepancy causing undercounting of Soroban transactions | Undercharging in Soroban host function that cannot be exploited to DoS the network or cause any significant slowdown. |\n| Informational | DoS vector requiring brute-force (paid transaction flooding) | Submitting thousands of max-fee transactions to slow ledger close — economically expensive and out of scope |\n| Informational | Network settings causing out of bounds issues | Settings are manually proposed and thoroughly evaluated by validators so there is no risk of going out of bounds |\n| Informational | New nodes unable to join the network | Corrupt history causing a new node to not be able to join |\n\n## Reward payment terms\n\nRewards 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\n\nTo receive a payout, researchers must successfully complete valid KYC before payment is issued.\n\n# KYC Requirement\n\nThe submission of KYC information is a requirement for payout processing. Stellar will request the following information in order to pay for successful bug submissions:\n\n* Full name  \n* Date of birth  \n* Proof of address (either a redacted bank statement with address or a recent utility bill)  \n* Copy of Passport or other Government issued ID  \n* Tax form (W-9 / W-8BEN / W-8BEN-E)\n\nTax information is also required.\n\nParticipants must adhere to the Eligibility Criteria stated in this policy.\n\n# Submission Requirements\n\nA 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:\n\n* A description of the vulnerability and the affected asset  \n* Step by step reproduction (Proof of Concept), including actual requests, responses, or an exploit script  \n* A clear impact statement tied to confidentiality, integrity, or availability  \n* Evidence that the issue is reproducible, such as screenshots, logs, transaction IDs, or a minimal working script\n\nReports 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.\n\n# Best Practices\n\n* 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.  \n* 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.\n\n#Prohibited Activities\n\nThe following activities are prohibited under this program:\n\n* Testing on mainnet or public testnet; all testing must be performed on local instances  \n* Phishing or social engineering attacks against SDF employees, contractors, or users  \n* Denial of service attacks against any SDF-operated or Stellar network infrastructure  \n* Automated scanning or fuzzing that generates significant traffic against production services  \n* Testing against third-party systems, applications, or websites (including SSO providers and CDNs)  \n* Public disclosure of an unpatched vulnerability before receiving express written consent from SDF  \n* Any activities that violate applicable laws or regulations\n\n# Responsible Disclosure\n\nOur 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.\n\nBug 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.\n\n# Report a Bug\n\n* Submit your report at [https://hackerone.com/stellar/reports/new](https://hackerone.com/stellar/reports/new)  \n* Include as much detail as possible, including a description of the issue, its potential impact, and clear reproduction steps or a Proof of Concept  \n* Please allow 3 business days for an initial response before following up\n\n# Legal\n\nParticipation 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](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](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.\n\nYou 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.\n\nSDF 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.\n\nViolation of this policy or any of the terms incorporated by reference may result in removal from the program and forfeiture of any bounty.\n\n# Stellar Terminology Reference\n\nStellar'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.\n\n| Stellar Term | Definition |\n| :---- | :---- |\n| Stellar Consensus Protocol (SCP) | Proof of Agreement mechanism to apply a set of transactions that go into a block. Validators reach consensus through quorum slices — overlapping sets of trusted validators. See [https://stellar.org/learn/stellar-consensus-protocol](https://stellar.org/learn/stellar-consensus-protocol) and [https://developers.stellar.org/docs/learn/fundamentals/stellar-consensus-protocol](https://developers.stellar.org/docs/learn/fundamentals/stellar-consensus-protocol) |\n| stellar-core | Reference implementation of the Stellar Consensus Protocol (SCP). Maintains the ledger, proposes/votes on transactions via SCP, applies the block, and publishes ledger updates. See [https://github.com/stellar/stellar-core/tree/master/docs](https://github.com/stellar/stellar-core/tree/master/docs) |\n| Soroban runtime | Rust contract-environment interface and host implementation for Soroban. |\n| Tier-1 Validator | Publicly identified validator organizations trusted by most of the network. They carry network safety and liveness. See [https://developers.stellar.org/docs/validators/tier-1-orgs](https://developers.stellar.org/docs/validators/tier-1-orgs) |\n| Quorum Slice Set | The set of validators a node trusts for consensus. Each validator defines its own quorum slice. Quorum intersection across slices ensures network agreement. |\n| Node blocking set | Any set of nodes in a quorum set that prevent a node from reaching agreement. Any security issue arising from collusion of a node blocking set is out of scope for the bug bounty program. |\n| Overlay Network | Peer-to-peer network connecting stellar-core nodes. Handles message broadcast, flow control, and peer management. |\n| Transaction Set | The batch of transactions proposed by a leader node and agreed upon by SCP. Apply order is shuffled to mitigate front-running. |\n| Ledger | Represents the state of the Stellar network at a point in time. It is shared across all stellar-core nodes in the network and contains the list of accounts, account balances, orders on the distributed exchange, smart contract code and data, etc. |\n| Fee Pool | Non-circulating XLM collected from transaction fees. It is not redistributed but may change in the future. |\n| Surge Pricing | When operations exceed capacity (\\~1,000 ops/ledger), or if there is competition between smart contract transactions for a particular resource like CPU instructions, ledger entry accesses (reads and writes), ledger IO (bytes read and bytes written), and the total size of transactions to be applied. See [https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering\\#surge-pricing](https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering#surge-pricing) |\n| Smart contract metering | Resource accounting system that measures and charges for computational resources during smart contract execution. See [https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering](https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering) |\n| Rent | Storing smart contract executable and its corresponding data on chain requires rent to be paid so that these entries are considered live until their Time-to-live (TTL) ledger. See [https://developers.stellar.org/docs/learn/fundamentals/contract-development/storage/state-archival\\#ttl](https://developers.stellar.org/docs/learn/fundamentals/contract-development/storage/state-archival#ttl) |\n| Herder | The SCP driver subclass inside stellar-core that bridges consensus with the overlay and ledger manager. |\n| Catchup / Replay | Process where a node downloads and replays missed ledgers to sync with the network. |\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-05-07T14:10:49.088Z"},{"id":3773814,"new_policy":"## Overview\n\nThe 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.\n\nStellar 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.\n\n#Program Transition\n\nEffective 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.\n\n# Primacy of Rules\n\nStellar adheres to the Primacy of Rules. The whole bug bounty program is run strictly under the terms and conditions stated within this page.\n\n# Scope\n\nThis 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).\n\n## In scope — Standard reward scale\n\nOpen-source repositories:\n\n* All open-source projects under the [Stellar GitHub organization](https://github.com/orgs/stellar/repositories), unless a repository explicitly states that it is out of scope or falls under the Protocol and Core Carveout below\n\nOnline services, apps, and websites:\n\n* [https://www.stellar.org](https://www.stellar.org)  \n* [https://www.stellar.org/account-viewer](https://www.stellar.org/account-viewer)  \n* [https://launch.stellar.org](https://launch.stellar.org)  \n* [https://api.stellar.org](https://api.stellar.org)  \n* [https://developers.stellar.org](https://developers.stellar.org)  \n* [https://communityfund.stellar.org](https://communityfund.stellar.org)\n\n## In scope — Protocol and Core Carveout (alternative reward scale)\n\nThe following assets are in scope at the alternative Protocol and Core Carveout reward scale:\n\n* [stellar-core](https://github.com/stellar/stellar-core) — Reference implementation of the Stellar Consensus Protocol  \n* [stellar-protocol](https://github.com/stellar/stellar-protocol) — Stellar protocol specifications  \n* The Soroban runtime and host code — Rust contract-environment interface and host implementation for Soroban\n\n## Out of scope\n\n* Archived GitHub repositories and projects  \n* GitHub repository forks  \n* Repositories that explicitly state they are out of scope  \n* Vulnerabilities affecting third-party applications that consume Stellar APIs\n\n# Eligibility\n\nGenerally 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.\n\nIn general, anything with the potential for financial loss or data breach is considered sufficiently severe, including:\n\n* Implementation bugs that can lead to financial loss  \n* Access to our production servers  \n* Remote Code Execution  \n* 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  \n* Vulnerabilities matching the impact categories listed in the Protocol and Core Carveout severity matrix below\n\nThe following reports are submitted very often and will generally be marked as Not Applicable:\n\n* SPF or DMARC issues  \n* CORS headers on endpoints that are intentionally accessible from other domains  \n* Issues with third party services we use, such as Mailgun or Segment  \n* Logout CSRF  \n* Vulnerabilities in third party libraries without a working exploit against our applications or servers  \n* Publicly readable AWS S3 buckets containing Stellar ledger history, because this data is public  \n* Content Delivery Network bypass\n\nIn general, the following would **not** meet the threshold for severity and may be marked as **Not Applicable**:\n\n* Version disclosure  \n* Missing security headers  \n* Cookies without the secure flag  \n* Recently disclosed 0-day vulnerabilities without demonstrated impact to our environment  \n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on an in-scope Stellar property  \n* Vulnerabilities that depend on physical access, social engineering, spam, or DDoS  \n* Vulnerabilities affecting outdated or unpatched browsers  \n* Vulnerabilities in third party applications that make use of Stellar APIs  \n* Reports that have not been responsibly investigated and documented  \n* Bugs already known to us, or already reported by another researcher, where the reward goes to the first valid reporter  \n* Issues that are not reproducible  \n* Issues that we cannot reasonably be expected to remediate  \n* Archived GitHub repositories or projects  \n* GitHub repository forks  \n* DoS vectors requiring brute-force paid transaction flooding (economically expensive, out of scope)  \n* Network settings causing out-of-bounds issues, since settings are manually proposed and evaluated by validators  \n* Security issues arising from collusion of a node blocking set\n\n# Rewards\n\nWe 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.\n\nThe reward scale that applies to a report depends on which assets are affected:\n\n* The **Standard reward scale** applies to all in-scope assets except those listed under the Protocol and Core Carveout.  \n* The **Protocol and Core Carveout reward scale** applies to vulnerabilities in `stellar-core`, `stellar-protocol`, and the Soroban runtime/host code.\n\n## Standard reward scale\n\nThe 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.\n\n* Critical: 0 to 25,000 points  \n* High: 0 to 15,000 points  \n* Medium: 0 to 10,000 points  \n* Low: 0 to 2,000 points  \n* Note: 0 to 500 points\n\n1 point currently corresponds to 1 USD, payable in lumens (XLM), though this may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to its maximum practical impact.\n\n## Protocol and Core Carveout reward scale\n\nThe following higher reward scale applies exclusively to vulnerabilities in `stellar-core`, `stellar-protocol`, and the Soroban runtime/host code:\n\n* Critical: 0 to 25,000 points  \n* High: 0 to 15,000  \n* Medium: 0 to 10,000  \n* Low: 0 to 1,000\n\n### Critical reward calculation for carveout assets\n\nFor 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.\n\n### Severity classification for carveout assets\n\nFor carveout assets, severity is determined using the OWASP risk rating methodology rather than CVSS. To use the calculator:\n\n1. Determine the severity by looking at the *Impact Category* that best matches the vulnerability in the severity lookup matrix below.  \n2. Evaluate how easy 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).\n\n\\* 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.\n\n#### Severity lookup matrix\n\n| Impact Category | Trivial to exploit | Requires tier-1 access |\n| :---- | :---: | :---: |\n| Direct theft / loss of funds | Critical | Critical |\n| Total network halt | Critical | High \\- Medium (mitigation dependent) |\n| Affects XLM supply integrity (minting, burning) | Critical | High |\n| Fund freeze | Critical | High |\n| Observable non-determinism causing divergence | Critical | High |\n| Fee pool exploits | High | Medium |\n| Soroban runtime bug putting realistic Smart contracts at risk of plausible malfunction | High | \\- |\n| Increase resource consumption that can cause slowdown of 5 seconds or more | Medium | Low |\n| Increase memory consumption more than 20% of the recommended hardware specification | Medium | Low |\n| Soroban simulation library causing Stellar RPC crash | Medium | \\- |\n| MEV / transaction ordering manipulation | Medium | \\- |\n| Bypass Soroban rent fee mechanism paying less than 20% of actual | Medium | Low |\n| Shut down of greater than 30% of watcher nodes (network unaffected) | Medium | Low |\n| Bypass Soroban rent fee mechanism paying between 21% to 99% | Low | Informational |\n| DoS by less than or equal to 30% consumption of CPU/Memory resources | Low | Informational |\n| Increase resource consumption that can cause slowdown of more than 1 second but less than 5 seconds | Low | Informational |\n| Increase memory consumption more than 5% but less than 20% of the recommended hardware specification | Low | Informational |\n| Shut down of 10% to 30% of (network unaffected) | Low | Informational |\n| Minor metering discrepancy that can cause slowdown between 2 and 5 seconds | Low | Informational |\n| Trivial metering discrepancy that can cause slowdown less than 2 seconds | Informational | Informational |\n\n#### Severity, impact and examples\n\nThe 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](https://developers.stellar.org/docs/validators/admin-guide/prerequisites#hardware-requirements).\n\n| Severity | Impact Description | Concrete Example |\n| :---: | :---- | :---- |\n| Critical | Direct theft or irreversible loss of funds excluding fees burned | \\*Payout would be a % of loss of funds |\n| Critical | Total network halt — network cannot confirm new transactions | Example 1: Auth stack exhaustion causing all validator nodes to crash. Example 2: XDR recursion depth limits causing stack overflow. Example 3: Oversized duplicate SCP message crashing a node via flow control invariant abort. \\*Mitigation mechanism determines the severity. If it is easy to mitigate by removing a Tier-1 from another's config then it is medium severity. If a new software package is needed then it is high severity. |\n| Critical | Minting of native asset (XLM) outside of protocol rules | Integer overflow in fee validation enabling creation of XLM from nothing |\n| Critical | Permanent freezing of funds | Bug in Soroban contract storage that makes persistent entries permanently inaccessible |\n| Critical | Observable non-determinism causing divergence | Floating-point or platform-dependent behavior in Soroban host functions producing different ledger hashes across validator architectures (e.g., ARM vs x86) |\n| High | A malicious Tier-1 validator able to halt the entire network | A tier-1 validator crafting malformed SCP messages that cause all other tier-1 nodes to crash |\n| High | Fee pool exploits | A user submits a transaction that drains the Fee Pool thus stealing XLM |\n| High | Soroban runtime bug putting realistic Smart contracts at risk of plausible malfunction | Examples: unauthorized call gets authorized, SCVal stored in storage gets corrupted, error code gets lost, cryptographic function \"validates\" invalid input, wrong contract gets invoked, wrong event emitted. |\n| Medium | Metering discrepancy in Soroban that can lead to resource exhaustion | Soroban host functions undercharging CPU or memory resources by 50 times such that an attacker can produce measurable slowdown |\n| Medium | Increase resource consumption that can cause slowdown of 5 seconds or more | Specially crafted Soroban contract invocation that triggers excessive disk I/O during ledger close, slowing all validators |\n| Medium | Increase memory consumption more than 20% of the recommended hardware specification |  |\n| Medium | Soroban simulation library bug causing Stellar RPC to crash | Bug in Soroban simulation library causing Stellar RPC nodes to crash when running simulation |\n| Medium | MEV attack or any transaction ordering manipulation | Bug where attacker can deterministically cause a transaction to execute before a victim transaction |\n| Low | Shut down of greater than 30% of watcher nodes – network is unaffected and continues to close ledgers | Peer-to-peer flood message causing non-tier-1 watchers to disconnect |\n| Low | DoS by causing less than 30% of CPU/memory resource consumption on nodes outside of the declared limits and without brute force | Specially crafted Soroban contract invocation that triggers moderate disk I/O during ledger close, slowing all validators |\n| Low | Bypass of transaction fee mechanism enabling free or severely underpriced transactions | TxSet baseFee integer overflow bypassing fee validation entirely |\n| Low | Exploit Soroban rent fee mechanism | Any exploit that can get access to free rent for persistent Soroban entries. |\n| Informational | Minor metering discrepancy causing undercounting of Soroban transactions | Undercharging in Soroban host function that cannot be exploited to DoS the network or cause any significant slowdown. |\n| Informational | DoS vector requiring brute-force (paid transaction flooding) | Submitting thousands of max-fee transactions to slow ledger close — economically expensive and out of scope |\n| Informational | Network settings causing out of bounds issues | Settings are manually proposed and thoroughly evaluated by validators so there is no risk of going out of bounds |\n| Informational | New nodes unable to join the network | Corrupt history causing a new node to not be able to join |\n\n## Reward payment terms\n\nRewards 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\n\nTo receive a payout, researchers must successfully complete valid KYC before payment is issued.\n\n# KYC Requirement\n\nThe submission of KYC information is a requirement for payout processing. Stellar will request the following information in order to pay for successful bug submissions:\n\n* Full name  \n* Date of birth  \n* Proof of address (either a redacted bank statement with address or a recent utility bill)  \n* Copy of Passport or other Government issued ID  \n* Tax form (W-9 / W-8BEN / W-8BEN-E)\n\nTax information is also required.\n\nParticipants must adhere to the Eligibility Criteria stated in this policy.\n\n# Submission Requirements\n\nA 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:\n\n* A description of the vulnerability and the affected asset  \n* Step by step reproduction (Proof of Concept), including actual requests, responses, or an exploit script  \n* A clear impact statement tied to confidentiality, integrity, or availability  \n* Evidence that the issue is reproducible, such as screenshots, logs, transaction IDs, or a minimal working script\n\nReports 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.\n\n# Best Practices\n\n* 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.  \n* 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.\n\n#Prohibited Activities\n\nThe following activities are prohibited under this program:\n\n* Testing on mainnet or public testnet; all testing must be performed on local instances  \n* Phishing or social engineering attacks against SDF employees, contractors, or users  \n* Denial of service attacks against any SDF-operated or Stellar network infrastructure  \n* Automated scanning or fuzzing that generates significant traffic against production services  \n* Testing against third-party systems, applications, or websites (including SSO providers and CDNs)  \n* Public disclosure of an unpatched vulnerability before receiving express written consent from SDF  \n* Any activities that violate applicable laws or regulations\n\n# Responsible Disclosure\n\nOur 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.\n\nBug 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.\n\n# Report a Bug\n\n* Submit your report at [https://hackerone.com/stellar/reports/new](https://hackerone.com/stellar/reports/new)  \n* Include as much detail as possible, including a description of the issue, its potential impact, and clear reproduction steps or a Proof of Concept  \n* Please allow 3 business days for an initial response before following up\n\n# Legal\n\nParticipation 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](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](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.\n\nYou 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.\n\nSDF 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.\n\nViolation of this policy or any of the terms incorporated by reference may result in removal from the program and forfeiture of any bounty.\n\n# Stellar Terminology Reference\n\nStellar'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.\n\n| Stellar Term | Definition |\n| :---- | :---- |\n| Stellar Consensus Protocol (SCP) | Proof of Agreement mechanism to apply a set of transactions that go into a block. Validators reach consensus through quorum slices — overlapping sets of trusted validators. See [https://stellar.org/learn/stellar-consensus-protocol](https://stellar.org/learn/stellar-consensus-protocol) and [https://developers.stellar.org/docs/learn/fundamentals/stellar-consensus-protocol](https://developers.stellar.org/docs/learn/fundamentals/stellar-consensus-protocol) |\n| stellar-core | Reference implementation of the Stellar Consensus Protocol (SCP). Maintains the ledger, proposes/votes on transactions via SCP, applies the block, and publishes ledger updates. See [https://github.com/stellar/stellar-core/tree/master/docs](https://github.com/stellar/stellar-core/tree/master/docs) |\n| Soroban runtime | Rust contract-environment interface and host implementation for Soroban. |\n| Tier-1 Validator | Publicly identified validator organizations trusted by most of the network. They carry network safety and liveness. See [https://developers.stellar.org/docs/validators/tier-1-orgs](https://developers.stellar.org/docs/validators/tier-1-orgs) |\n| Quorum Slice Set | The set of validators a node trusts for consensus. Each validator defines its own quorum slice. Quorum intersection across slices ensures network agreement. |\n| Node blocking set | Any set of nodes in a quorum set that prevent a node from reaching agreement. Any security issue arising from collusion of a node blocking set is out of scope for the bug bounty program. |\n| Overlay Network | Peer-to-peer network connecting stellar-core nodes. Handles message broadcast, flow control, and peer management. |\n| Transaction Set | The batch of transactions proposed by a leader node and agreed upon by SCP. Apply order is shuffled to mitigate front-running. |\n| Ledger | Represents the state of the Stellar network at a point in time. It is shared across all stellar-core nodes in the network and contains the list of accounts, account balances, orders on the distributed exchange, smart contract code and data, etc. |\n| Fee Pool | Non-circulating XLM collected from transaction fees. It is not redistributed but may change in the future. |\n| Surge Pricing | When operations exceed capacity (\\~1,000 ops/ledger), or if there is competition between smart contract transactions for a particular resource like CPU instructions, ledger entry accesses (reads and writes), ledger IO (bytes read and bytes written), and the total size of transactions to be applied. See [https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering\\#surge-pricing](https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering#surge-pricing) |\n| Smart contract metering | Resource accounting system that measures and charges for computational resources during smart contract execution. See [https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering](https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering) |\n| Rent | Storing smart contract executable and its corresponding data on chain requires rent to be paid so that these entries are considered live until their Time-to-live (TTL) ledger. See [https://developers.stellar.org/docs/learn/fundamentals/contract-development/storage/state-archival\\#ttl](https://developers.stellar.org/docs/learn/fundamentals/contract-development/storage/state-archival#ttl) |\n| Herder | The SCP driver subclass inside stellar-core that bridges consensus with the overlay and ledger manager. |\n| Catchup / Replay | Process where a node downloads and replays missed ledgers to sync with the network. |\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-05-07T13:37:42.228Z"},{"id":3771441,"new_policy":"The Stellar Bug Bounty Program provides bounties for vulnerabilities and exploits discovered in Stellar Development Foundation maintained repositories, services, and infrastructure. 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.\n\n# Responsible Disclosure\n\nOur 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 publicly disclosing a vulnerability.\n\n# Rewards\n\nWe reward researchers who find valid security issues with a bounty paid in lumens (XLM). 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.\n\n* Critical: 0 to 25 000 points\n* High: 0 to 15 000 points\n* Medium: 0 to 10 000 points\n* Low: 0 to 2 000 points\n* Note: 0 to 500 points\n\n1 point currently corresponds to 1 USD, payable in lumens (XLM), though this may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to its maximum practical impact.\n\nTo receive a payout, researchers must successfully complete valid KYC before payment is issued.\n\n# Eligibility\n\nGenerally speaking, any bug that poses a significant vulnerability to the security or integrity of Stellar Development Foundation maintained applications, services, or infrastructure could be eligible for a reward. However, it is entirely at our discretion to decide whether a bug is significant enough to qualify.\n\nIn general, anything with the potential for financial loss or data breach is considered sufficiently severe, including:\n\n* Implementation bugs that can lead to financial loss\n* Access to our production servers\n* Remote Code Execution\n* 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\n\nThe following reports are submitted very often and will generally be marked as **Not Applicable**:\n\n* SPF or DMARC issues\n* CORS headers on endpoints that are intentionally accessible from other domains\n* Issues with third party services we use, such as Mailgun or Segment\n* Logout CSRF\n* Vulnerabilities in third party libraries without a working exploit against our applications or servers\n* Publicly readable AWS S3 buckets containing Stellar ledger history, because this data is public\n* Content Delivery Network bypass\n\nIn general, the following would not meet the threshold for severity and may be marked as **Not Applicable**:\n\n* Version disclosure\n* Missing security headers\n* Cookies without the `secure` flag\n* Recently disclosed 0-day vulnerabilities without demonstrated impact to our environment\n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on an in-scope Stellar property\n* Vulnerabilities that depend on physical access, social engineering, spam, or DDoS\n* Vulnerabilities affecting outdated or unpatched browsers\n* Vulnerabilities in third party applications that make use of Stellar APIs\n* Reports that have not been responsibly investigated and documented\n* Bugs already known to us, or already reported by another researcher, where the reward goes to the first valid reporter\n* Issues that are not reproducible\n* Issues that we cannot reasonably be expected to remediate\n* Archived GitHub repositories or projects\n* GitHub repository forks\n\n# Scope\n\nThis HackerOne program covers SDF maintained open-source repositories, services, applications, and websites.\n\n## In scope\n\nOpen-source repositories:\n* All open-source projects under the [Stellar GitHub organization](https://github.com/orgs/stellar/repositories), unless a repository explicitly states that it is out of scope or is covered by a separate security program\n\nOnline services, apps, and websites:\n* [https://www.stellar.org](https://www.stellar.org)\n* [https://www.stellar.org/account-viewer](https://www.stellar.org/account-viewer)\n* [https://launch.stellar.org](https://launch.stellar.org)\n* [https://api.stellar.org](https://api.stellar.org)\n* [https://developers.stellar.org](https://developers.stellar.org)\n* [https://communityfund.stellar.org](https://communityfund.stellar.org)\n\n## Out of scope\n\n* Archived GitHub repositories and projects\n* GitHub repository forks\n* Repositories that explicitly state they are out of scope\n* Vulnerabilities affecting the Stellar protocol\n* Repositories, services, or assets covered by the separate Immunefi program\n* Any repositories or assets explicitly listed as out of scope in the Immunefi program, including:\n  * [stellar-core](https://github.com/stellar/stellar-core)\n  * [stellar-protocol](https://github.com/stellar/stellar-protocol)\n\n# Best Practices\n\n* 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.\n* 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.\n\n# Submission Requirements\n\nAll reports, regardless of severity, must include:\n\n* A description of the vulnerability and the affected asset\n* Step by step reproduction, also known as a Proof of Concept (PoC), including actual requests, responses, or an exploit script\n* A clear impact statement tied to confidentiality, integrity, or availability\n* Evidence that the issue is reproducible, such as screenshots, logs, transaction IDs, or a minimal working script\n\nReports 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.\n\n# Report a Bug\n\n* Submit your report at [https://hackerone.com/stellar/reports/new](https://hackerone.com/stellar/reports/new)\n* Include as much detail as possible, including a description of the issue, its potential impact, and clear reproduction steps or a Proof of Concept\n* Please allow 3 business days for an initial response before following up\n\n# Legal\n\nYou 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.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-03-20T17:26:28.419Z"},{"id":3769949,"new_policy":"The Stellar Bug Bounty Program provides bounties for vulnerabilities and exploits discovered in the Stellar protocol or any of the code in our repos. We recognize the importance of our community and security researchers in helping identify bugs and issues. We encourage responsible disclosure of security vulnerabilities via our bug bounty program described on this page.\n\n# Responsible Disclosure\nOur development team has up to 90 days to implement a fix based on the severity of the report. Please allow for this process to fully complete before you publicly disclose the vulnerability.\n\n# Rewards\nWe are rewarding researchers that find bugs with a bounty of our digital currency, lumens (XLM). The Stellar.org Bug Bounty Panel will evaluate award sizes according to technical severity calculated using CVSS v3.0 Base Score, plus business impact (e.g. - what asset is affected, how many participants in the Stellar network are impacted, what data is at risk, or what the financial/reputational consequences to the network are). Reports with high business impact will get higher rewards than reports with lower business impact (even for the same technical severity calculated using CVSS v3.0 Base Score). However, final awards are determined at the sole discretion of the panel:\n\n* Critical: up to 25 000 points\n* High: up to 15 000 points\n* Medium: up to 10 000 points\n* Low: up to 2 000 points\n* Note: up to 500 points\n\n1 point currently corresponds to 1 USD (payable in lumens (XLM), something which may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to maximum effect.\n\n# Eligibility\nGenerally speaking, any bug that poses a significant vulnerability to the security or integrity of the Stellar Network could be eligible for reward. However, it’s entirely at our discretion to decide whether a bug is significant enough to be eligible for reward.\n\nIn general, anything which has the potential for financial loss or data breach is of sufficient severity, including:\n\n* Implementation bugs that can lead to financial loss\n* Access to our production servers\n* Remote Code Execution\n* Protocol bugs\n* Crash bug in Stellar-RPC or Horizon (ex. a bug that can crash the app by sending a special request, not by sending thousands requests).\n\nThe following reports are reported very often and will be marked as **Not Applicable**:\n\n* SPF/DMARC records.\n* CORS headers on endpoints meant to be accessible from other domains.\n* Issues with other services we use Mailgun/Segment/etc.\n* Logout CSRF.\n* Vulnerabilities in 3rd party libraries without working exploit against our apps/servers.\n* Readable AWS S3 buckets with Stellar ledger history - this is public.\n* Wordpress admins usernames disclosure.\n* Content Delivery Network bypass\n\nIn general, the following would not meet the threshold for severity (and can be marked **Not Applicable**):\n\n* Version disclosure.\n* Lack of security headers.\n* Cookies without `secure` flag.\n* Recently disclosed 0-day vulnerabilities\n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on the main website.\n* Vulnerabilities contingent on physical attack, social engineering, spamming, DDOS attack, etc.\n* Vulnerabilities affecting outdated or unpatched browsers.\n* Vulnerabilities in third party applications that make use of Stellar’s API.\n* Bugs that have not been responsibly investigated and reported.\n* Bugs already known to us, or already reported by someone else (reward goes to first reporter).\n* Issues that aren't reproducible.\n* Issues that we can't reasonably be expected to do anything about.\n* Archived Github repositories/projects\n\n# Scope\nOur open source WEB2 projects:\n* [Horizon](https://github.com/stellar/horizon)\n* [Stellar-RPC](https://github.com/stellar/stellar-rpc)\n* All WEB2 open-source projects under [Stellar.org organization](https://github.com/orgs/stellar/repositories)\n\nSDKs:\n* [Go SDK](https://github.com/stellar/go)\n* [JS SDK](https://github.com/stellar/js-stellar-sdk)\n\nOur online services, apps and websites:\n* https://www.stellar.org\n* https://www.stellar.org/account-viewer\n* https://launch.stellar.org\n* https://api.stellar.org\n* https://developers.stellar.org\n* https://communityfund.stellar.org\n\n# Best practices\n* Please use your local instance of Horizon/ Stellar-RPC and a separate network (not test/public network) when searching for security bugs (ex. you can use our docker image). Remember that blockchains are public and someone may see your findings and report a bug before you.\n* Step by step report (or an exploit script) is more than welcomed. It will allow us to understand and fix the issue faster and you will get your rewards more quickly.\n\n# Report a bug\n* Submit your bug at https://hackerone.com/stellar/reports/new\n* Try to include as much information in your report as you can, including a description of the bug, its potential -impact, and steps for reproducing it or proof of concept.\n* Please allow 3 business days for us to respond before sending another email.\n\n# Legal\nYou may not participate in this program if you are a resident or individual located within a country appearing on any U.S. sanctions lists.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-02-19T22:17:22.140Z"},{"id":3768903,"new_policy":"The Stellar Bug Bounty Program provides bounties for vulnerabilities and exploits discovered in the Stellar protocol or any of the code in our repos. We recognize the importance of our community and security researchers in helping identify bugs and issues. We encourage responsible disclosure of security vulnerabilities via our bug bounty program described on this page.\n\n# Responsible Disclosure\nOur development team has up to 90 days to implement a fix based on the severity of the report. Please allow for this process to fully complete before you publicly disclose the vulnerability.\n\n# Rewards\nWe are rewarding researchers that find bugs with a bounty of our digital currency, lumens (XLM). The amount of the award depends on the degree of severity of the vulnerability reported.\n\nThe Stellar.org Bug Bounty Panel will evaluate award sizes according to severity calculated according to the [OWASP](https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology) risk rating model based on Impact and Likelihood. However, final awards are determined at the sole discretion of the panel:\n\n* Critical: up to 25 000 points\n* High: up to 15 000 points\n* Medium: up to 10 000 points\n* Low: up to 2 000 points\n* Note: up to 500 points\n\n1 point currently corresponds to 1 USD (payable in lumens (XLM), something which may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to maximum effect.\n\n# Eligibility\nGenerally speaking, any bug that poses a significant vulnerability to the security or integrity of the Stellar Network could be eligible for reward. However, it’s entirely at our discretion to decide whether a bug is significant enough to be eligible for reward.\n\nIn general, anything which has the potential for financial loss or data breach is of sufficient severity, including:\n\n* Implementation bugs that can lead to financial loss\n* Access to our production servers\n* Remote Code Execution\n* Protocol bugs\n* Crash bug in Stellar-RPC or Horizon (ex. a bug that can crash the app by sending a special request, not by sending thousands requests).\n\nThe following reports are reported very often and will be marked as **Not Applicable**:\n\n* SPF/DMARC records.\n* CORS headers on endpoints meant to be accessible from other domains.\n* Issues with other services we use Mailgun/Segment/etc.\n* Logout CSRF.\n* Vulnerabilities in 3rd party libraries without working exploit against our apps/servers.\n* Readable AWS S3 buckets with Stellar ledger history - this is public.\n* Wordpress admins usernames disclosure.\n* Content Delivery Network bypass\n\nIn general, the following would not meet the threshold for severity (and can be marked **Not Applicable**):\n\n* Version disclosure.\n* Lack of security headers.\n* Cookies without `secure` flag.\n* Recently disclosed 0-day vulnerabilities\n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on the main website.\n* Vulnerabilities contingent on physical attack, social engineering, spamming, DDOS attack, etc.\n* Vulnerabilities affecting outdated or unpatched browsers.\n* Vulnerabilities in third party applications that make use of Stellar’s API.\n* Bugs that have not been responsibly investigated and reported.\n* Bugs already known to us, or already reported by someone else (reward goes to first reporter).\n* Issues that aren't reproducible.\n* Issues that we can't reasonably be expected to do anything about.\n* Archived Github repositories/projects\n\n# Severity\nThe severity of a bug, i.e. how many participants in the Stellar network are affected, is taken into consideration when deciding the bounty payout amount. For example, an exploit that relies on an implementation bug in stellar-core affects the network as a whole and very deeply. There are no alternate implementations of stellar-core and so a payout that affects stellar-core would pay out higher than for example, an XSS bug.\n\n# Scope\nOur open source WEB2 projects:\n* [Horizon](https://github.com/stellar/horizon)\n* [Stellar-RPC](https://github.com/stellar/stellar-rpc)\n* All WEB2 open-source projects under [Stellar.org organization](https://github.com/orgs/stellar/repositories)\n\nSDKs:\n* [Go SDK](https://github.com/stellar/go)\n* [JS SDK](https://github.com/stellar/js-stellar-sdk)\n\nOur online services, apps and websites:\n* https://www.stellar.org\n* https://www.stellar.org/account-viewer\n* https://launch.stellar.org\n* https://api.stellar.org\n* https://developers.stellar.org\n* https://communityfund.stellar.org\n\n# Best practices\n* Please use your local instance of Horizon/ Stellar-RPC and a separate network (not test/public network) when searching for security bugs (ex. you can use our docker image). Remember that blockchains are public and someone may see your findings and report a bug before you.\n* Step by step report (or an exploit script) is more than welcomed. It will allow us to understand and fix the issue faster and you will get your rewards more quickly.\n\n# Report a bug\n* Submit your bug at https://hackerone.com/stellar/reports/new\n* Try to include as much information in your report as you can, including a description of the bug, its potential -impact, and steps for reproducing it or proof of concept.\n* Please allow 3 business days for us to respond before sending another email.\n\n# Legal\nYou may not participate in this program if you are a resident or individual located within a country appearing on any U.S. sanctions lists.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-01-28T18:45:18.808Z"},{"id":3749710,"new_policy":"The Stellar Bug Bounty Program provides bounties for vulnerabilities and exploits discovered in the Stellar protocol or any of the code in our repos. We recognize the importance of our community and security researchers in helping identify bugs and issues. We encourage responsible disclosure of security vulnerabilities via our bug bounty program described on this page.\n\n# Responsible Disclosure\nOur development team has up to 90 days to implement a fix based on the severity of the report. Please allow for this process to fully complete before you publicly disclose the vulnerability.\n\n# Rewards\nWe are rewarding researchers that find bugs with a bounty of our digital currency, lumens (XLM). The amount of the award depends on the degree of severity of the vulnerability reported.\n\nThe Stellar.org Bug Bounty Panel will evaluate award sizes according to severity calculated according to the [OWASP](https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology) risk rating model based on Impact and Likelihood. However, final awards are determined at the sole discretion of the panel:\n\n* Critical: up to 25 000 points\n* High: up to 15 000 points\n* Medium: up to 10 000 points\n* Low: up to 2 000 points\n* Note: up to 500 points\n\n1 point currently corresponds to 1 USD (payable in lumens (XLM), something which may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to maximum effect.\n\n# Eligibility\nGenerally speaking, any bug that poses a significant vulnerability to the security or integrity of the Stellar Network could be eligible for reward. However, it’s entirely at our discretion to decide whether a bug is significant enough to be eligible for reward.\n\nIn general, anything which has the potential for financial loss or data breach is of sufficient severity, including:\n\n* Implementation bugs that can lead to financial loss\n* Access to our production servers\n* Remote Code Execution\n* Protocol bugs\n* Crash bug in Stellar-RPC or Horizon (ex. a bug that can crash the app by sending a special request, not by sending thousands requests).\n\nThe following reports are reported very often and will be marked as **Not Applicable**:\n\n* SPF/DMARC records.\n* CORS headers on endpoints meant to be accessible from other domains.\n* Issues with other services we use Mailgun/Segment/etc.\n* Logout CSRF.\n* Vulnerabilities in 3rd party libraries without working exploit against our apps/servers.\n* Readable AWS S3 buckets with Stellar ledger history - this is public.\n* Wordpress admins usernames disclosure.\n* Content Delivery Network bypass\n\nIn general, the following would not meet the threshold for severity (and can be marked **Not Applicable**):\n\n* Version disclosure.\n* Lack of security headers.\n* Cookies without `secure` flag.\n* Recently disclosed 0-day vulnerabilities\n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on the main website.\n* Vulnerabilities contingent on physical attack, social engineering, spamming, DDOS attack, etc.\n* Vulnerabilities affecting outdated or unpatched browsers.\n* Vulnerabilities in third party applications that make use of Stellar’s API.\n* Bugs that have not been responsibly investigated and reported.\n* Bugs already known to us, or already reported by someone else (reward goes to first reporter).\n* Issues that aren't reproducible.\n* Issues that we can't reasonably be expected to do anything about.\n* Archived Github repositories/projects\n\n# Severity\nThe severity of a bug, i.e. how many participants in the Stellar network are affected, is taken into consideration when deciding the bounty payout amount. For example, an exploit that relies on an implementation bug in stellar-core affects the network as a whole and very deeply. There are no alternate implementations of stellar-core and so a payout that affects stellar-core would pay out higher than for example, an XSS bug.\n\n# Scope\nOur open source WEB2 projects:\n* [Horizon](https://github.com/stellar/horizon)\n* [Stellar-RPC](https://github.com/stellar/stellar-rpc)\n* All WEB2 open-source projects under [Stellar.org organization](https://github.com/orgs/stellar/repositories)\n\nSDKs:\n* [Go SDK](https://github.com/stellar/go)\n* [Java SDK](https://github.com/stellar/java-stellar-sdk)\n* [JS SDK](https://github.com/stellar/js-stellar-sdk)\n\nOur online services, apps and websites:\n* https://www.stellar.org\n* https://www.stellar.org/account-viewer\n* https://launch.stellar.org\n* https://api.stellar.org\n* https://developers.stellar.org\n* https://communityfund.stellar.org\n\n# Best practices\n* Please use your local instance of Horizon/ Stellar-RPC and a separate network (not test/public network) when searching for security bugs (ex. you can use our docker image). Remember that blockchains are public and someone may see your findings and report a bug before you.\n* Step by step report (or an exploit script) is more than welcomed. It will allow us to understand and fix the issue faster and you will get your rewards more quickly.\n\n# Report a bug\n* Submit your bug at https://hackerone.com/stellar/reports/new\n* Try to include as much information in your report as you can, including a description of the bug, its potential -impact, and steps for reproducing it or proof of concept.\n* Please allow 3 business days for us to respond before sending another email.\n\n# Legal\nYou may not participate in this program if you are a resident or individual located within a country appearing on any U.S. sanctions lists.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-02-06T20:15:39.623Z"},{"id":3735876,"new_policy":"The Stellar Bug Bounty Program provides bounties for vulnerabilities and exploits discovered in the Stellar protocol or any of the code in our repos. We recognize the importance of our community and security researchers in helping identify bugs and issues. We encourage responsible disclosure of security vulnerabilities via our bug bounty program described on this page.\n\n# Responsible Disclosure\nOur development team has up to 90 days to implement a fix based on the severity of the report. Please allow for this process to fully complete before you publicly disclose the vulnerability.\n\n# Rewards\nWe are rewarding researchers that find bugs with a bounty of our digital currency, lumens (XLM). The amount of the award depends on the degree of severity of the vulnerability reported.\n\nThe Stellar.org Bug Bounty Panel will evaluate award sizes according to severity calculated according to the [OWASP](https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology) risk rating model based on Impact and Likelihood. However, final awards are determined at the sole discretion of the panel:\n\n* Critical: up to 25 000 points\n* High: up to 15 000 points\n* Medium: up to 10 000 points\n* Low: up to 2 000 points\n* Note: up to 500 points\n\n1 point currently corresponds to 1 USD (payable in lumens (XLM), something which may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to maximum effect.\n\n# Eligibility\nGenerally speaking, any bug that poses a significant vulnerability to the security or integrity of the Stellar Network could be eligible for reward. However, it’s entirely at our discretion to decide whether a bug is significant enough to be eligible for reward.\n\nIn general, anything which has the potential for financial loss or data breach is of sufficient severity, including:\n\n* Implementation bugs that can lead to financial loss\n* Access to our production servers\n* Remote Code Execution\n* Protocol bugs\n* Crash bug in Stellar-core or Horizon (ex. a bug that can crash the app by sending a special request, not by sending thousands requests).\n\nThe following reports are reported very often and will be marked as **Not Applicable**:\n\n* SPF/DMARC records.\n* CORS headers on endpoints meant to be accessible from other domains.\n* Issues with other services we use Mailgun/Segment/etc.\n* Logout CSRF.\n* Vulnerabilities in 3rd party libraries without working exploit against our apps/servers.\n* Readable AWS S3 buckets with Stellar ledger history - this is public.\n* Wordpress admins usernames disclosure.\n* Content Delivery Network bypass\n\nIn general, the following would not meet the threshold for severity (and can be marked **Not Applicable**):\n\n* Version disclosure.\n* Lack of security headers.\n* Cookies without `secure` flag.\n* Recently disclosed 0-day vulnerabilities\n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on the main website.\n* Vulnerabilities contingent on physical attack, social engineering, spamming, DDOS attack, etc.\n* Vulnerabilities affecting outdated or unpatched browsers.\n* Vulnerabilities in third party applications that make use of Stellar’s API.\n* Bugs that have not been responsibly investigated and reported.\n* Bugs already known to us, or already reported by someone else (reward goes to first reporter).\n* Issues that aren't reproducible.\n* Issues that we can't reasonably be expected to do anything about.\n* Archived Github repositories/projects\n\n# Severity\nThe severity of a bug, i.e. how many participants in the Stellar network are affected, is taken into consideration when deciding the bounty payout amount. For example, an exploit that relies on an implementation bug in stellar-core affects the network as a whole and very deeply. There are no alternate implementations of stellar-core and so a payout that affects stellar-core would pay out higher than for example, an XSS bug.\n\n# Scope\nOur open source projects:\n* [Stellar-core](https://github.com/stellar/stellar-core)\n* [Horizon](https://github.com/stellar/horizon)\n* [Bridge and compliance server](https://github.com/stellar/bridge-server)\n* All our open-source projects under [Stellar.org organization](https://github.com/orgs/stellar/repositories)\n\nSDKs:\n* [Go SDK](https://github.com/stellar/go)\n* [Java SDK](https://github.com/stellar/java-stellar-sdk)\n* [JS SDK](https://github.com/stellar/js-stellar-sdk)\n\nOur online services, apps and websites:\n* https://www.stellar.org\n* https://www.stellar.org/account-viewer\n* https://launch.stellar.org\n* https://api.stellar.org\n* https://invite.stellar.org\n* https://soroban.stellar.org\n* https://developers.stellar.org\n* https://communityfund.stellar.org\n\n# Best practices\n* Please use your local instance of Stellar-core / Horizon and a separate network (not test/public network) when searching for security bugs (ex. you can use our docker image). Remember that blockchains are public and someone may see your findings and report a bug before you.\n* Step by step report (or an exploit script) is more than welcomed. It will allow us to understand and fix the issue faster and you will get your rewards more quickly.\n\n# Report a bug\n* Submit your bug at https://hackerone.com/stellar/reports/new\n* Try to include as much information in your report as you can, including a description of the bug, its potential -impact, and steps for reproducing it or proof of concept.\n* Please allow 3 business days for us to respond before sending another email.\n\n# Legal\nYou may not participate in this program if you are a resident or individual located within a country appearing on any U.S. sanctions lists.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-08-12T19:36:50.724Z"},{"id":3728994,"new_policy":"The Stellar Bug Bounty Program provides bounties for vulnerabilities and exploits discovered in the Stellar protocol or any of the code in our repos. We recognize the importance of our community and security researchers in helping identify bugs and issues. We encourage responsible disclosure of security vulnerabilities via our bug bounty program described on this page.\n\n# Responsible Disclosure\nOur development team has up to 90 days to implement a fix based on the severity of the report. Please allow for this process to fully complete before you publicly disclose the vulnerability.\n\n# Rewards\nWe are rewarding researchers that find bugs with a bounty of our digital currency, lumens (XLM). The amount of the award depends on the degree of severity of the vulnerability reported.\n\nThe Stellar.org Bug Bounty Panel will evaluate award sizes according to severity calculated according to the [OWASP](https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology) risk rating model based on Impact and Likelihood. However, final awards are determined at the sole discretion of the panel:\n\n* Critical: up to 25 000 points\n* High: up to 15 000 points\n* Medium: up to 10 000 points\n* Low: up to 2 000 points\n* Note: up to 500 points\n\n1 point currently corresponds to 1 USD (payable in lumens (XLM), something which may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to maximum effect.\n\n# Eligibility\nGenerally speaking, any bug that poses a significant vulnerability to the security or integrity of the Stellar Network could be eligible for reward. However, it’s entirely at our discretion to decide whether a bug is significant enough to be eligible for reward.\n\nIn general, anything which has the potential for financial loss or data breach is of sufficient severity, including:\n\n* Implementation bugs that can lead to financial loss\n* Access to our production servers\n* Remote Code Execution\n* Protocol bugs\n* Crash bug in Stellar-core or Horizon (ex. a bug that can crash the app by sending a special request, not by sending thousands requests).\n\nThe following reports are reported very often and will be marked as **Not Applicable**:\n\n* SPF/DMARC records.\n* CORS headers on endpoints meant to be accessible from other domains.\n* Issues with other services we use Mailgun/Segment/etc.\n* Logout CSRF.\n* Vulnerabilities in 3rd party libraries without working exploit against our apps/servers.\n* Readable AWS S3 buckets with Stellar ledger history - this is public.\n* Wordpress admins usernames disclosure.\n* Content Delivery Network bypass\n\nIn general, the following would not meet the threshold for severity (and can be marked **Not Applicable**):\n\n* Version disclosure.\n* Lack of security headers.\n* Cookies without `secure` flag.\n* Recently disclosed 0-day vulnerabilities\n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on the main website.\n* Vulnerabilities contingent on physical attack, social engineering, spamming, DDOS attack, etc.\n* Vulnerabilities affecting outdated or unpatched browsers.\n* Vulnerabilities in third party applications that make use of Stellar’s API.\n* Bugs that have not been responsibly investigated and reported.\n* Bugs already known to us, or already reported by someone else (reward goes to first reporter).\n* Issues that aren't reproducible.\n* Issues that we can't reasonably be expected to do anything about.\n\n# Severity\nThe severity of a bug, i.e. how many participants in the Stellar network are affected, is taken into consideration when deciding the bounty payout amount. For example, an exploit that relies on an implementation bug in stellar-core affects the network as a whole and very deeply. There are no alternate implementations of stellar-core and so a payout that affects stellar-core would pay out higher than for example, an XSS bug.\n\n# Scope\nOur open source projects:\n* [Stellar-core](https://github.com/stellar/stellar-core)\n* [Horizon](https://github.com/stellar/horizon)\n* [Bridge and compliance server](https://github.com/stellar/bridge-server)\n* All our open-source projects under [Stellar.org organization](https://github.com/orgs/stellar/repositories)\n\nSDKs:\n* [Go SDK](https://github.com/stellar/go)\n* [Java SDK](https://github.com/stellar/java-stellar-sdk)\n* [JS SDK](https://github.com/stellar/js-stellar-sdk)\n\nOur online services, apps and websites:\n* https://www.stellar.org\n* https://www.stellar.org/account-viewer\n* https://launch.stellar.org\n* https://api.stellar.org\n* https://invite.stellar.org\n* https://soroban.stellar.org\n* https://developers.stellar.org\n* https://communityfund.stellar.org\n\n# Best practices\n* Please use your local instance of Stellar-core / Horizon and a separate network (not test/public network) when searching for security bugs (ex. you can use our docker image). Remember that blockchains are public and someone may see your findings and report a bug before you.\n* Step by step report (or an exploit script) is more than welcomed. It will allow us to understand and fix the issue faster and you will get your rewards more quickly.\n\n# Report a bug\n* Submit your bug at https://hackerone.com/stellar/reports/new\n* Try to include as much information in your report as you can, including a description of the bug, its potential -impact, and steps for reproducing it or proof of concept.\n* Please allow 3 business days for us to respond before sending another email.\n\n# Legal\nYou may not participate in this program if you are a resident or individual located within a country appearing on any U.S. sanctions lists.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-06-07T16:35:19.280Z"},{"id":3710110,"new_policy":"The Stellar Bug Bounty Program provides bounties for vulnerabilities and exploits discovered in the Stellar protocol or any of the code in our repos. We recognize the importance of our community and security researchers in helping identify bugs and issues. We encourage responsible disclosure of security vulnerabilities via our bug bounty program described on this page.\n\n# Responsible Disclosure\nOur development team has up to 90 days to implement a fix based on the severity of the report. Please allow for this process to fully complete before you publicly disclose the vulnerability.\n\n# Rewards\nWe are rewarding researchers that find bugs with a bounty of our digital currency, lumens (XLM). The amount of the award depends on the degree of severity of the vulnerability reported.\n\nThe Stellar.org Bug Bounty Panel will evaluate award sizes according to severity calculated according to the [OWASP](https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology) risk rating model based on Impact and Likelihood. However, final awards are determined at the sole discretion of the panel:\n\n* Critical: up to 25 000 points\n* High: up to 15 000 points\n* Medium: up to 10 000 points\n* Low: up to 2 000 points\n* Note: up to 500 points\n\n1 point currently corresponds to 1 USD (payable in lumens (XLM), something which may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to maximum effect.\n\n# Eligibility\nGenerally speaking, any bug that poses a significant vulnerability to the security or integrity of the Stellar Network could be eligible for reward. However, it’s entirely at our discretion to decide whether a bug is significant enough to be eligible for reward.\n\nIn general, anything which has the potential for financial loss or data breach is of sufficient severity, including:\n\n* Implementation bugs that can lead to financial loss\n* Access to our production servers\n* Remote Code Execution\n* Protocol bugs\n* Crash bug in Stellar-core or Horizon (ex. a bug that can crash the app by sending a special request, not by sending thousands requests).\n\nThe following reports are reported very often and will be marked as **Not Applicable**:\n\n* SPF/DMARC records.\n* CORS headers on endpoints meant to be accessible from other domains.\n* Issues with other services we use Mailgun/Segment/etc.\n* Logout CSRF.\n* Vulnerabilities in 3rd party libraries without working exploit against our apps/servers.\n* Readable AWS S3 buckets with Stellar ledger history - this is public.\n* Wordpress admins usernames disclosure.\n* Content Delivery Network bypass\n\nIn general, the following would not meet the threshold for severity (and can be marked **Not Applicable**):\n\n* Version disclosure.\n* Lack of security headers.\n* Cookies without `secure` flag.\n* Recently disclosed 0-day vulnerabilities\n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on the main website.\n* Vulnerabilities contingent on physical attack, social engineering, spamming, DDOS attack, etc.\n* Vulnerabilities affecting outdated or unpatched browsers.\n* Vulnerabilities in third party applications that make use of Stellar’s API.\n* Bugs that have not been responsibly investigated and reported.\n* Bugs already known to us, or already reported by someone else (reward goes to first reporter).\n* Issues that aren't reproducible.\n* Issues that we can't reasonably be expected to do anything about.\n\n# Severity\nThe severity of a bug, i.e. how many participants in the Stellar network are affected, is taken into consideration when deciding the bounty payout amount. For example, an exploit that relies on an implementation bug in stellar-core affects the network as a whole and very deeply. There are no alternate implementations of stellar-core and so a payout that affects stellar-core would pay out higher than for example, an XSS bug.\n\n# Scope\nOur open source projects:\n* [Stellar-core](https://github.com/stellar/stellar-core)\n* [Horizon](https://github.com/stellar/horizon)\n* [Bridge and compliance server](https://github.com/stellar/bridge-server)\n* All our open-source projects under [Stellar.org organization](https://github.com/orgs/stellar/repositories)\n\nSDKs:\n* [Go SDK](https://github.com/stellar/go)\n* [Java SDK](https://github.com/stellar/java-stellar-sdk)\n* [JS SDK](https://github.com/stellar/js-stellar-sdk)\n\nOur online services, apps and websites:\n* https://www.stellar.org\n* https://www.stellar.org/account-viewer\n* https://launch.stellar.org\n* https://api.stellar.org\n* https://invite.stellar.org\n* https://soroban.stellar.org\n\n# Best practices\n* Please use your local instance of Stellar-core / Horizon and a separate network (not test/public network) when searching for security bugs (ex. you can use our docker image). Remember that blockchains are public and someone may see your findings and report a bug before you.\n* Step by step report (or an exploit script) is more than welcomed. It will allow us to understand and fix the issue faster and you will get your rewards more quickly.\n\n# Report a bug\n* Submit your bug at https://hackerone.com/stellar/reports/new\n* Try to include as much information in your report as you can, including a description of the bug, its potential -impact, and steps for reproducing it or proof of concept.\n* Please allow 3 business days for us to respond before sending another email.\n\n# Legal\nYou may not participate in this program if you are a resident or individual located within a country appearing on any U.S. sanctions lists.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-01-02T21:30:03.266Z"},{"id":3689169,"new_policy":"*We are excited to announce a new program with higher rewards dedicated to the source code of Soroban, our smart contract platform! Head over to [https://hackerone.com/soroban?type=team](https://hackerone.com/soroban?type=team) to access it*\n\nThe Stellar Bug Bounty Program provides bounties for vulnerabilities and exploits discovered in the Stellar protocol or any of the code in our repos. We recognize the importance of our community and security researchers in helping identify bugs and issues. We encourage responsible disclosure of security vulnerabilities via our bug bounty program described on this page.\n\n# Responsible Disclosure\nOur development team has up to 90 days to implement a fix based on the severity of the report. Please allow for this process to fully complete before you publicly disclose the vulnerability.\n\n# Rewards\nWe are rewarding researchers that find bugs with a bounty of our digital currency, lumens (XLM). The amount of the award depends on the degree of severity of the vulnerability reported.\n\nThe Stellar.org Bug Bounty Panel will evaluate award sizes according to severity calculated according to the [OWASP](https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology) risk rating model based on Impact and Likelihood. However, final awards are determined at the sole discretion of the panel:\n\n* Critical: up to 25 000 points\n* High: up to 15 000 points\n* Medium: up to 10 000 points\n* Low: up to 2 000 points\n* Note: up to 500 points\n\n1 point currently corresponds to 1 USD (payable in lumens (XLM), something which may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to maximum effect.\n\n# Eligibility\nGenerally speaking, any bug that poses a significant vulnerability to the security or integrity of the Stellar Network could be eligible for reward. However, it’s entirely at our discretion to decide whether a bug is significant enough to be eligible for reward.\n\nIn general, anything which has the potential for financial loss or data breach is of sufficient severity, including:\n\n* Implementation bugs that can lead to financial loss\n* Access to our production servers\n* Remote Code Execution\n* Protocol bugs\n* Crash bug in Stellar-core or Horizon (ex. a bug that can crash the app by sending a special request, not by sending thousands requests).\n\nThe following reports are reported very often and will be marked as **Not Applicable**:\n\n* SPF/DMARC records.\n* CORS headers on endpoints meant to be accessible from other domains.\n* Issues with other services we use Mailgun/Segment/etc.\n* Logout CSRF.\n* Vulnerabilities in 3rd party libraries without working exploit against our apps/servers.\n* Readable AWS S3 buckets with Stellar ledger history - this is public.\n* Wordpress admins usernames disclosure.\n* Content Delivery Network bypass\n\nIn general, the following would not meet the threshold for severity (and can be marked **Not Applicable**):\n\n* Version disclosure.\n* Lack of security headers.\n* Cookies without `secure` flag.\n* Recently disclosed 0-day vulnerabilities\n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on the main website.\n* Vulnerabilities contingent on physical attack, social engineering, spamming, DDOS attack, etc.\n* Vulnerabilities affecting outdated or unpatched browsers.\n* Vulnerabilities in third party applications that make use of Stellar’s API.\n* Bugs that have not been responsibly investigated and reported.\n* Bugs already known to us, or already reported by someone else (reward goes to first reporter).\n* Issues that aren't reproducible.\n* Issues that we can't reasonably be expected to do anything about.\n\n# Severity\nThe severity of a bug, i.e. how many participants in the Stellar network are affected, is taken into consideration when deciding the bounty payout amount. For example, an exploit that relies on an implementation bug in stellar-core affects the network as a whole and very deeply. There are no alternate implementations of stellar-core and so a payout that affects stellar-core would pay out higher than for example, an XSS bug.\n\n# Scope\nOur open source projects:\n* [Stellar-core](https://github.com/stellar/stellar-core)\n* [Horizon](https://github.com/stellar/horizon)\n* [Bridge and compliance server](https://github.com/stellar/bridge-server)\n* All our open-source projects under [Stellar.org organization](https://github.com/orgs/stellar/repositories)\n\nSDKs:\n* [Go SDK](https://github.com/stellar/go)\n* [Java SDK](https://github.com/stellar/java-stellar-sdk)\n* [JS SDK](https://github.com/stellar/js-stellar-sdk)\n\nOur online services, apps and websites:\n* https://www.stellar.org\n* https://www.stellar.org/account-viewer\n* https://launch.stellar.org\n* https://api.stellar.org\n* https://invite.stellar.org\n* https://soroban.stellar.org\n\n# Best practices\n* Please use your local instance of Stellar-core / Horizon and a separate network (not test/public network) when searching for security bugs (ex. you can use our docker image). Remember that blockchains are public and someone may see your findings and report a bug before you.\n* Step by step report (or an exploit script) is more than welcomed. It will allow us to understand and fix the issue faster and you will get your rewards more quickly.\n\n# Report a bug\n* Submit your bug at https://hackerone.com/stellar/reports/new\n* Try to include as much information in your report as you can, including a description of the bug, its potential -impact, and steps for reproducing it or proof of concept.\n* Please allow 3 business days for us to respond before sending another email.\n\n# Legal\nYou may not participate in this program if you are a resident or individual located within a country appearing on any U.S. sanctions lists.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-06-12T04:59:13.249Z"},{"id":3681595,"new_policy":"The Stellar Bug Bounty Program provides bounties for vulnerabilities and exploits discovered in the Stellar protocol or any of the code in our repos. We recognize the importance of our community and security researchers in helping identify bugs and issues. We encourage responsible disclosure of security vulnerabilities via our bug bounty program described on this page.\n\n# Responsible Disclosure\nOur development team has up to 90 days to implement a fix based on the severity of the report. Please allow for this process to fully complete before you publicly disclose the vulnerability.\n\n# Rewards\nWe are rewarding researchers that find bugs with a bounty of our digital currency, lumens (XLM). The amount of the award depends on the degree of severity of the vulnerability reported.\n\nThe Stellar.org Bug Bounty Panel will evaluate award sizes according to severity calculated according to the [OWASP](https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology) risk rating model based on Impact and Likelihood. However, final awards are determined at the sole discretion of the panel:\n\n* Critical: up to 25 000 points\n* High: up to 15 000 points\n* Medium: up to 10 000 points\n* Low: up to 2 000 points\n* Note: up to 500 points\n\n1 point currently corresponds to 1 USD (payable in lumens (XLM), something which may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to maximum effect.\n\n# Eligibility\nGenerally speaking, any bug that poses a significant vulnerability to the security or integrity of the Stellar Network could be eligible for reward. However, it’s entirely at our discretion to decide whether a bug is significant enough to be eligible for reward.\n\nIn general, anything which has the potential for financial loss or data breach is of sufficient severity, including:\n\n* Implementation bugs that can lead to financial loss\n* Access to our production servers\n* Remote Code Execution\n* Protocol bugs\n* Crash bug in Stellar-core or Horizon (ex. a bug that can crash the app by sending a special request, not by sending thousands requests).\n\nThe following reports are reported very often and will be marked as **Not Applicable**:\n\n* SPF/DMARC records.\n* CORS headers on endpoints meant to be accessible from other domains.\n* Issues with other services we use Mailgun/Segment/etc.\n* Logout CSRF.\n* Vulnerabilities in 3rd party libraries without working exploit against our apps/servers.\n* Readable AWS S3 buckets with Stellar ledger history - this is public.\n* Wordpress admins usernames disclosure.\n* Content Delivery Network bypass\n\nIn general, the following would not meet the threshold for severity (and can be marked **Not Applicable**):\n\n* Version disclosure.\n* Lack of security headers.\n* Cookies without `secure` flag.\n* Recently disclosed 0-day vulnerabilities\n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on the main website.\n* Vulnerabilities contingent on physical attack, social engineering, spamming, DDOS attack, etc.\n* Vulnerabilities affecting outdated or unpatched browsers.\n* Vulnerabilities in third party applications that make use of Stellar’s API.\n* Bugs that have not been responsibly investigated and reported.\n* Bugs already known to us, or already reported by someone else (reward goes to first reporter).\n* Issues that aren't reproducible.\n* Issues that we can't reasonably be expected to do anything about.\n\n# Severity\nThe severity of a bug, i.e. how many participants in the Stellar network are affected, is taken into consideration when deciding the bounty payout amount. For example, an exploit that relies on an implementation bug in stellar-core affects the network as a whole and very deeply. There are no alternate implementations of stellar-core and so a payout that affects stellar-core would pay out higher than for example, an XSS bug.\n\n# Scope\nOur open source projects:\n* [Stellar-core](https://github.com/stellar/stellar-core)\n* [Horizon](https://github.com/stellar/horizon)\n* [Bridge and compliance server](https://github.com/stellar/bridge-server)\n\nSDKs:\n* [Go SDK](https://github.com/stellar/go)\n* [Java SDK](https://github.com/stellar/java-stellar-sdk)\n* [JS SDK](https://github.com/stellar/js-stellar-sdk)\n\nOur online services, apps and websites:\n* https://www.stellar.org\n* https://www.stellar.org/account-viewer/\n* https://launch.stellar.org/\n* https://api.stellar.org\n* https://invite.stellar.org\n\n# Best practices\n* Please use your local instance of Stellar-core / Horizon and a separate network (not test/public network) when searching for security bugs (ex. you can use our docker image). Remember that blockchains are public and someone may see your findings and report a bug before you.\n* Step by step report (or an exploit script) is more than welcomed. It will allow us to understand and fix the issue faster and you will get your rewards more quickly.\n\n# Report a bug\n* Submit your bug at https://hackerone.com/stellar/reports/new\n* Try to include as much information in your report as you can, including a description of the bug, its potential -impact, and steps for reproducing it or proof of concept.\n* Please allow 3 business days for us to respond before sending another email.\n\n#Legal\nYou may not participate in this program if you are a resident or individual located within a country appearing on any U.S. sanctions lists.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-01-03T12:15:16.891Z"},{"id":3557113,"new_policy":"The Stellar Bug Bounty Program provides bounties for vulnerabilities and exploits discovered in the Stellar protocol or any of the code in our repos. We recognize the importance of our community and security researchers in helping identify bugs and issues. We encourage responsible disclosure of security vulnerabilities via our bug bounty program described on this page.\n\n# Responsible Disclosure\nOur development team has up to 90 days to implement a fix based on the severity of the report. Please allow for this process to fully complete before you publicly disclose the vulnerability.\n\n# Rewards\nWe are rewarding researchers that find bugs with a bounty of our digital currency, lumens (XLM). The amount of the award depends on the degree of severity of the vulnerability reported.\n\nThe Stellar.org Bug Bounty Panel will evaluate award sizes according to severity calculated according to the [OWASP](https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology) risk rating model based on Impact and Likelihood. However, final awards are determined at the sole discretion of the panel:\n\n* Critical: up to 25 000 points\n* High: up to 15 000 points\n* Medium: up to 10 000 points\n* Low: up to 2 000 points\n* Note: up to 500 points\n\n1 point currently corresponds to 1 USD (payable in lumens (XLM), something which may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to maximum effect.\n\n# Eligibility\nGenerally speaking, any bug that poses a significant vulnerability to the security or integrity of the Stellar Network could be eligible for reward. However, it’s entirely at our discretion to decide whether a bug is significant enough to be eligible for reward.\n\nIn general, anything which has the potential for financial loss or data breach is of sufficient severity, including:\n\n* Implementation bugs that can lead to financial loss\n* Access to our production servers\n* Remote Code Execution\n* Protocol bugs\n* Crash bug in Stellar-core or Horizon (ex. a bug that can crash the app by sending a special request, not by sending thousands requests).\n\nThe following reports are reported very often and will be marked as **Not Applicable**:\n\n* SPF/DMARC records.\n* CORS headers on endpoints meant to be accessible from other domains.\n* Issues with other services we use Mailgun/Segment/etc.\n* Logout CSRF.\n* Vulnerabilities in 3rd party libraries without working exploit against our apps/servers.\n* Readable AWS S3 buckets with Stellar ledger history - this is public.\n* Wordpress admins usernames disclosure.\n\nIn general, the following would not meet the threshold for severity (and can be marked **Not Applicable**):\n\n* Version disclosure.\n* Lack of security headers.\n* Cookies without `secure` flag.\n* Recently disclosed 0-day vulnerabilities\n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on the main website.\n* Vulnerabilities contingent on physical attack, social engineering, spamming, DDOS attack, etc.\n* Vulnerabilities affecting outdated or unpatched browsers.\n* Vulnerabilities in third party applications that make use of Stellar’s API.\n* Bugs that have not been responsibly investigated and reported.\n* Bugs already known to us, or already reported by someone else (reward goes to first reporter).\n* Issues that aren't reproducible.\n* Issues that we can't reasonably be expected to do anything about.\n\n# Severity\nThe severity of a bug, i.e. how many participants in the Stellar network are affected, is taken into consideration when deciding the bounty payout amount. For example, an exploit that relies on an implementation bug in stellar-core affects the network as a whole and very deeply. There are no alternate implementations of stellar-core and so a payout that affects stellar-core would pay out higher than for example, an XSS bug.\n\n# Scope\nOur open source projects:\n* [Stellar-core](https://github.com/stellar/stellar-core)\n* [Horizon](https://github.com/stellar/horizon)\n* [Bridge and compliance server](https://github.com/stellar/bridge-server)\n\nSDKs:\n* [Go SDK](https://github.com/stellar/go)\n* [Java SDK](https://github.com/stellar/java-stellar-sdk)\n* [JS SDK](https://github.com/stellar/js-stellar-sdk)\n\nOur online services, apps and websites:\n* https://www.stellar.org\n* https://www.stellar.org/account-viewer/\n* https://launch.stellar.org/\n* https://api.stellar.org\n* https://invite.stellar.org\n\n# Best practices\n* Please use your local instance of Stellar-core / Horizon and a separate network (not test/public network) when searching for security bugs (ex. you can use our docker image). Remember that blockchains are public and someone may see your findings and report a bug before you.\n* Step by step report (or an exploit script) is more than welcomed. It will allow us to understand and fix the issue faster and you will get your rewards more quickly.\n\n# Report a bug\n* Submit your bug at https://hackerone.com/stellar/reports/new\n* Try to include as much information in your report as you can, including a description of the bug, its potential -impact, and steps for reproducing it or proof of concept.\n* Please allow 3 business days for us to respond before sending another email.\n\n#Legal\nYou may not participate in this program if you are a resident or individual located within a country appearing on any U.S. sanctions lists.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-07-07T18:14:26.341Z"},{"id":3557112,"new_policy":"The Stellar Bug Bounty Program provides bounties for vulnerabilities and exploits discovered in the Stellar protocol or any of the code in our repos. We recognize the importance of our community and security researchers in helping identify bugs and issues. We encourage responsible disclosure of security vulnerabilities via our bug bounty program described on this page.\n\n# Responsible Disclosure\nOur development team has up to 90 days to implement a fix based on the severity of the report. Please allow for this process to fully complete before you publicly disclose the vulnerability.\n\n# Rewards\nWe are rewarding researchers that find bugs with a bounty of our digital currency, lumens (XLM). The amount of the award depends on the degree of severity of the vulnerability reported.\n\nThe Stellar.org Bug Bounty Panel will evaluate award sizes according to severity calculated according to the [OWASP](https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology) risk rating model based on Impact and Likelihood. However, final awards are determined at the sole discretion of the panel:\n\n* Critical: up to 25 000 points\n* High: up to 15 000 points\n* Medium: up to 10 000 points\n* Low: up to 2 000 points\n* Note: up to 500 points\n\n1 point currently corresponds to 1 USD (payable in lumens (XLM), something which may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to maximum effect.\n\n# Eligibility\nGenerally speaking, any bug that poses a significant vulnerability to the security or integrity of the Stellar Network could be eligible for reward. However, it’s entirely at our discretion to decide whether a bug is significant enough to be eligible for reward.\n\nIn general, anything which has the potential for financial loss or data breach is of sufficient severity, including:\n\n* Implementation bugs that can lead to financial loss\n* Access to our production servers\n* Remote Code Execution\n* Protocol bugs\n* Crash bug in Stellar-core or Horizon (ex. a bug that can crash the app by sending a special request, not by sending thousands requests).\n\nIn general, the following would not meet the threshold for severity (and can be marked **Not Applicable**):\n\n* Version disclosure.\n* Lack of security headers.\n* Cookies without `secure` flag.\n* Recently disclosed 0-day vulnerabilities\n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on the main website.\n* Vulnerabilities contingent on physical attack, social engineering, spamming, DDOS attack, etc.\n* Vulnerabilities affecting outdated or unpatched browsers.\n* Vulnerabilities in third party applications that make use of Stellar’s API.\n* Bugs that have not been responsibly investigated and reported.\n* Bugs already known to us, or already reported by someone else (reward goes to first reporter).\n* Issues that aren't reproducible.\n* Issues that we can't reasonably be expected to do anything about.\n\nThe following reports are reported very often and will be marked as **Not Applicable**:\n* SPF/DMARC records.\n* CORS headers on endpoints meant to be accessible from other domains.\n* Issues with other services we use Mailgun/Segment/etc.\n* Logout CSRF.\n* Vulnerabilities in 3rd party libraries without working exploit against our apps/servers.\n* Readable AWS S3 buckets with Stellar ledger history - this is public.\n* Wordpress admins usernames disclosure.\n\n# Severity\nThe severity of a bug, i.e. how many participants in the Stellar network are affected, is taken into consideration when deciding the bounty payout amount. For example, an exploit that relies on an implementation bug in stellar-core affects the network as a whole and very deeply. There are no alternate implementations of stellar-core and so a payout that affects stellar-core would pay out higher than for example, an XSS bug.\n\n# Scope\nOur open source projects:\n* [Stellar-core](https://github.com/stellar/stellar-core)\n* [Horizon](https://github.com/stellar/horizon)\n* [Bridge and compliance server](https://github.com/stellar/bridge-server)\n\nSDKs:\n* [Go SDK](https://github.com/stellar/go)\n* [Java SDK](https://github.com/stellar/java-stellar-sdk)\n* [JS SDK](https://github.com/stellar/js-stellar-sdk)\n\nOur online services, apps and websites:\n* https://www.stellar.org\n* https://www.stellar.org/account-viewer/\n* https://launch.stellar.org/\n* https://api.stellar.org\n* https://invite.stellar.org\n\n# Best practices\n* Please use your local instance of Stellar-core / Horizon and a separate network (not test/public network) when searching for security bugs (ex. you can use our docker image). Remember that blockchains are public and someone may see your findings and report a bug before you.\n* Step by step report (or an exploit script) is more than welcomed. It will allow us to understand and fix the issue faster and you will get your rewards more quickly.\n\n# Report a bug\n* Submit your bug at https://hackerone.com/stellar/reports/new\n* Try to include as much information in your report as you can, including a description of the bug, its potential -impact, and steps for reproducing it or proof of concept.\n* Please allow 3 business days for us to respond before sending another email.\n\n#Legal\nYou may not participate in this program if you are a resident or individual located within a country appearing on any U.S. sanctions lists.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-07-07T18:13:37.453Z"},{"id":3557111,"new_policy":"The Stellar Bug Bounty Program provides bounties for vulnerabilities and exploits discovered in the Stellar protocol or any of the code in our repos. We recognize the importance of our community and security researchers in helping identify bugs and issues. We encourage responsible disclosure of security vulnerabilities via our bug bounty program described on this page.\n\n# Responsible Disclosure\nOur development team has up to 90 days to implement a fix based on the severity of the report. Please allow for this process to fully complete before you publicly disclose the vulnerability.\n\n# Rewards\nWe are rewarding researchers that find bugs with a bounty of our digital currency, lumens (XLM). The amount of the award depends on the degree of severity of the vulnerability reported.\n\nThe Stellar.org Bug Bounty Panel will evaluate award sizes according to severity calculated according to the [OWASP](https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology) risk rating model based on Impact and Likelihood. However, final awards are determined at the sole discretion of the panel:\n\n* Critical: up to 25 000 points\n* High: up to 15 000 points\n* Medium: up to 10 000 points\n* Low: up to 2 000 points\n* Note: up to 500 points\n\n1 point currently corresponds to 1 USD (payable in lumens (XLM), something which may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to maximum effect.\n\n# Eligibility\nGenerally speaking, any bug that poses a significant vulnerability to the security or integrity of the Stellar Network could be eligible for reward. However, it’s entirely at our discretion to decide whether a bug is significant enough to be eligible for reward.\n\nIn general, anything which has the potential for financial loss or data breach is of sufficient severity, including:\n\n* Implementation bugs that can lead to financial loss\n* Access to our production servers\n* Remote Code Execution\n* Protocol bugs\n* Crash bug in Stellar-core or Horizon (ex. a bug that can crash the app by sending a special request, not by sending thousands requests).\n\nIn general, the following would not meet the threshold for severity:\n\n* Version disclosure.\n* Lack of security headers.\n* Cookies without `secure` flag.\n* Recently disclosed 0-day vulnerabilities\n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on the main website.\n* Vulnerabilities contingent on physical attack, social engineering, spamming, DDOS attack, etc.\n* Vulnerabilities affecting outdated or unpatched browsers.\n* Vulnerabilities in third party applications that make use of Stellar’s API.\n* Bugs that have not been responsibly investigated and reported.\n* Bugs already known to us, or already reported by someone else (reward goes to first reporter).\n* Issues that aren't reproducible.\n* Issues that we can't reasonably be expected to do anything about.\n\nThe following reports with be marked as **Not Applicable**:\n* SPF/DMARC records.\n* CORS headers on endpoints meant to be accessible from other domains.\n* Issues with other services we use Mailgun/Segment/etc.\n* Logout CSRF.\n* Vulnerabilities in 3rd party libraries without working exploit against our apps/servers.\n* Readable AWS S3 buckets with Stellar ledger history - this is public.\n* Wordpress admins usernames disclosure.\n\n# Severity\nThe severity of a bug, i.e. how many participants in the Stellar network are affected, is taken into consideration when deciding the bounty payout amount. For example, an exploit that relies on an implementation bug in stellar-core affects the network as a whole and very deeply. There are no alternate implementations of stellar-core and so a payout that affects stellar-core would pay out higher than for example, an XSS bug.\n\n# Scope\nOur open source projects:\n* [Stellar-core](https://github.com/stellar/stellar-core)\n* [Horizon](https://github.com/stellar/horizon)\n* [Bridge and compliance server](https://github.com/stellar/bridge-server)\n\nSDKs:\n* [Go SDK](https://github.com/stellar/go)\n* [Java SDK](https://github.com/stellar/java-stellar-sdk)\n* [JS SDK](https://github.com/stellar/js-stellar-sdk)\n\nOur online services, apps and websites:\n* https://www.stellar.org\n* https://www.stellar.org/account-viewer/\n* https://launch.stellar.org/\n* https://api.stellar.org\n* https://invite.stellar.org\n\n# Best practices\n* Please use your local instance of Stellar-core / Horizon and a separate network (not test/public network) when searching for security bugs (ex. you can use our docker image). Remember that blockchains are public and someone may see your findings and report a bug before you.\n* Step by step report (or an exploit script) is more than welcomed. It will allow us to understand and fix the issue faster and you will get your rewards more quickly.\n\n# Report a bug\n* Submit your bug at https://hackerone.com/stellar/reports/new\n* Try to include as much information in your report as you can, including a description of the bug, its potential -impact, and steps for reproducing it or proof of concept.\n* Please allow 3 business days for us to respond before sending another email.\n\n#Legal\nYou may not participate in this program if you are a resident or individual located within a country appearing on any U.S. sanctions lists.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-07-07T18:12:53.288Z"},{"id":3555626,"new_policy":"The Stellar Bug Bounty Program provides bounties for vulnerabilities and exploits discovered in the Stellar protocol or any of the code in our repos. We recognize the importance of our community and security researchers in helping identify bugs and issues. We encourage responsible disclosure of security vulnerabilities via our bug bounty program described on this page.\n\n# Responsible Disclosure\nOur development team has up to 90 days to implement a fix based on the severity of the report. Please allow for this process to fully complete before you publicly disclose the vulnerability.\n\n# Rewards\nWe are rewarding researchers that find bugs with a bounty of our digital currency, lumens (XLM). The amount of the award depends on the degree of severity of the vulnerability reported.\n\nThe Stellar.org Bug Bounty Panel will evaluate award sizes according to severity calculated according to the [OWASP](https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology) risk rating model based on Impact and Likelihood. However, final awards are determined at the sole discretion of the panel:\n\n* Critical: up to 25 000 points\n* High: up to 15 000 points\n* Medium: up to 10 000 points\n* Low: up to 2 000 points\n* Note: up to 500 points\n\n1 point currently corresponds to 1 USD (payable in lumens (XLM), something which may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to maximum effect.\n\n# Eligibility\nGenerally speaking, any bug that poses a significant vulnerability to the security or integrity of the Stellar Network could be eligible for reward. However, it’s entirely at our discretion to decide whether a bug is significant enough to be eligible for reward.\n\nIn general, anything which has the potential for financial loss or data breach is of sufficient severity, including:\n\n* Implementation bugs that can lead to financial loss\n* Access to our production servers\n* Remote Code Execution\n* Protocol bugs\n* Crash bug in Stellar-core or Horizon (ex. a bug that can crash the app by sending a special request, not by sending thousands requests).\n\nIn general, the following would not meet the threshold for severity:\n\n* Version disclosure.\n* Lack of security headers.\n* Cookies without `secure` flag.\n* Recently disclosed 0-day vulnerabilities\n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on the main website.\n* Vulnerabilities contingent on physical attack, social engineering, spamming, DDOS attack, etc.\n* Vulnerabilities affecting outdated or unpatched browsers.\n* Vulnerabilities in third party applications that make use of Stellar’s API.\n* Bugs that have not been responsibly investigated and reported.\n* Bugs already known to us, or already reported by someone else (reward goes to first reporter).\n* Issues that aren't reproducible.\n* Issues that we can't reasonably be expected to do anything about.\n\n# Severity\nThe severity of a bug, i.e. how many participants in the Stellar network are affected, is taken into consideration when deciding the bounty payout amount. For example, an exploit that relies on an implementation bug in stellar-core affects the network as a whole and very deeply. There are no alternate implementations of stellar-core and so a payout that affects stellar-core would pay out higher than for example, an XSS bug.\n\n# Scope\nOur open source projects:\n* [Stellar-core](https://github.com/stellar/stellar-core)\n* [Horizon](https://github.com/stellar/horizon)\n* [Bridge and compliance server](https://github.com/stellar/bridge-server)\n\nSDKs:\n* [Go SDK](https://github.com/stellar/go)\n* [Java SDK](https://github.com/stellar/java-stellar-sdk)\n* [JS SDK](https://github.com/stellar/js-stellar-sdk)\n\nOur online services, apps and websites:\n* https://www.stellar.org\n* https://www.stellar.org/account-viewer/\n* https://launch.stellar.org/\n* https://api.stellar.org\n* https://invite.stellar.org\n\n# Best practices\n* Please use your local instance of Stellar-core / Horizon and a separate network (not test/public network) when searching for security bugs (ex. you can use our docker image). Remember that blockchains are public and someone may see your findings and report a bug before you.\n* Step by step report (or an exploit script) is more than welcomed. It will allow us to understand and fix the issue faster and you will get your rewards more quickly.\n\n# Report a bug\n* Submit your bug at https://hackerone.com/stellar/reports/new\n* Try to include as much information in your report as you can, including a description of the bug, its potential -impact, and steps for reproducing it or proof of concept.\n* Please allow 3 business days for us to respond before sending another email.\n\n#Legal\nYou may not participate in this program if you are a resident or individual located within a country appearing on any U.S. sanctions lists.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-06-13T14:17:15.685Z"},{"id":3555570,"new_policy":"The Stellar Bug Bounty Program provides bounties for vulnerabilities and exploits discovered in the Stellar protocol or any of the code in our repos. We recognize the importance of our community and security researchers in helping identify bugs and issues. We encourage responsible disclosure of security vulnerabilities via our bug bounty program described on this page.\n\n# Responsible Disclosure\nOur development team has up to 90 days to implement a fix based on the severity of the report. Please allow for this process to fully complete before you publicly disclose the vulnerability.\n\n# Rewards\nWe are rewarding researchers that find bugs with a bounty of our digital currency, lumens (XLM). The amount of the award depends on the degree of severity of the vulnerability reported.\n\nThe Stellar.org Bug Bounty Panel will evaluate award sizes according to severity calculated according to the [OWASP](https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology) risk rating model based on Impact and Likelihood. However, final awards are determined at the sole discretion of the panel:\n\n* Critical: up to 25 000 points\n* High: up to 15 000 points\n* Medium: up to 10 000 points\n* Low: up to 2 000 points\n* Note: up to 500 points\n\n1 point currently corresponds to 1 USD (payable in lumens (XLM), something which may change without prior notice.\n\nResearchers are more likely to earn a larger reward by demonstrating how a vulnerability can be exploited to maximum effect.\n\n# Eligibility\nGenerally speaking, any bug that poses a significant vulnerability to the security or integrity of the Stellar Network could be eligible for reward. However, it’s entirely at our discretion to decide whether a bug is significant enough to be eligible for reward.\n\nIn general, anything which has the potential for financial loss or data breach is of sufficient severity, including:\n\n* Implementation bugs that can lead to financial loss\n* Access to our production servers\n* Remote Code Execution\n* Protocol bugs\n* Crash bug in Stellar-core or Horizon (ex. a bug that can crash the app by sending a special request, not by sending thousands requests).\n\nIn general, the following would not meet the threshold for severity:\n\n* Recently disclosed 0-day vulnerabilities\n* Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on the main website.\n* Vulnerabilities contingent on physical attack, social engineering, spamming, DDOS attack, etc.\n* Vulnerabilities affecting outdated or unpatched browsers.\n* Vulnerabilities in third party applications that make use of Stellar’s API.\n* Bugs that have not been responsibly investigated and reported.\n* Bugs already known to us, or already reported by someone else (reward goes to first reporter).\n* Issues that aren't reproducible.\n* Issues that we can't reasonably be expected to do anything about.\n\n# Severity\nThe severity of a bug, i.e. how many participants in the Stellar network are affected, is taken into consideration when deciding the bounty payout amount. For example, an exploit that relies on an implementation bug in stellar-core affects the network as a whole and very deeply. There are no alternate implementations of stellar-core and so a payout that affects stellar-core would pay out higher than for example, an XSS bug.\n\n# Scope\nOur open source projects:\n* [Stellar-core](https://github.com/stellar/stellar-core)\n* [Horizon](https://github.com/stellar/horizon)\n* [Bridge and compliance server](https://github.com/stellar/bridge-server)\n\nSDKs:\n* [Go SDK](https://github.com/stellar/go)\n* [Java SDK](https://github.com/stellar/java-stellar-sdk)\n* [JS SDK](https://github.com/stellar/js-stellar-sdk)\n\nOur online services, apps and websites:\n* https://www.stellar.org\n* https://www.stellar.org/account-viewer/\n* https://launch.stellar.org/\n* https://api.stellar.org\n* https://invite.stellar.org\n\n# Best practices\n* Please use your local instance of Stellar-core / Horizon and a separate network (not test/public network) when searching for security bugs (ex. you can use our docker image). Remember that blockchains are public and someone may see your findings and report a bug before you.\n* Step by step report (or an exploit script) is more than welcomed. It will allow us to understand and fix the issue faster and you will get your rewards more quickly.\n\n# Report a bug\n* Submit your bug at https://hackerone.com/stellar/reports/new\n* Try to include as much information in your report as you can, including a description of the bug, its potential -impact, and steps for reproducing it or proof of concept.\n* Please allow 3 business days for us to respond before sending another email.\n\n#Legal\nYou may not participate in this program if you are a resident or individual located within a country appearing on any U.S. sanctions lists.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-06-12T17:49:12.325Z"}]