Skip to content

Anchor

Bug bounty on Sorona anchor-lang.com

Accepting reports KYC to get paid open-source
Top reward
Not published
Top severity paid
Not published
Assets in scope
9
Public CVEs
3
Last change
No changes yet

At a glance

What to know before you start testing.

Pays cash
Amounts are not published; ask before you invest time.
Partial safe harbor
Some legal protection; read the terms.
Replies within 3 days
As the policy promises.
Paid by SOL to stake accounts with a lockup
Proof of identity needed to get paid.
Publish after a fix
Coordinate the timing with the company.

Rewards

What Sorona lists as the payout for each severity.

Sorona does not publish a reward table for this program.

Pays cash
Yes the Critical band is 118 to 1,176 SOL, Medium 59 to 294, Low 1 to 59
Response
Within 3 days the policy commits to a response typically within 72 hours
Safe harbor
Partial Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.

Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original

Scope

9 assets you may test, 8 excluded.

Web 1

  • https://www.anchor-lang.com

Products and areas 8

  • anchor-spl, the wrappers around SPL Token, Associated Token and Metaplex accounts that most Anchor programs use instead of writing those checks themselves
  • IDL generation and the on-chain IDL account, together with the Borsh serialisation and deserialisation used on both sides of the boundary
  • The anchor CLI and avm: build, verifiable build, test, deploy and upgrade, the tooling standing between reviewed source and the bytes that land on chain
  • The anchor-lang runtime crate and its account-validation layer: #[account], #[derive(Accounts)], constraint expressions, the discriminator mechanism, AccountLoader and the zero-copy paths
  • The procedural macros behind #[program], including instruction dispatch and whatever the derive macros actually expand to underneath the source a developer reads
  • The program grades the whole of that surface: bypassing a fundamental Anchor check is Critical, denial of service is Medium, and everything remaining in the repository is Low
  • The repository is the boundary the program draws: anything whose source code exists in coral-xyz/anchor is in, and anything whose source does not is out
  • The Rust and TypeScript clients, anchor-client and @coral-xyz/anchor, covering coders, event parsing and transaction construction
Out of scope (8)
  • Any encrypted credentials, auth tokens or similar checked into the repository
  • Anything whose source code does not exist in the repository, including web properties not explicitly listed on the program page
  • Attacks that require social engineering
  • Awards to anyone who has not completed KYC and signed the Solana Foundation participation agreement
  • Bugs in dependencies, which the policy says to take upstream
  • Findings already rewarded under a protocol's own bounty, which the policy will not pay a second time
  • Undeveloped automated tooling results such as raw scanner output, though a finding carried through to a developed proof of concept is accepted
  • Vulnerability classes that are user error rather than library defects. The rubric asks whether the bug was public knowledge previously, which can make it a hazard for users of Anchor rather than an issue within Anchor.

Rules

What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.

While testing

  • Submit through sorona.xyz first.
  • Participants must complete KYC and sign the Solana Foundation participation agreement at solana.org/kyc before any award can be paid
  • Awards are paid in SOL to stake accounts with a lockup expiring twelve months from the date of delivery
  • A developed proof of concept is required; undeveloped automated tooling results are not accepted
  • No double-dipping: a finding already rewarded under a protocol's own bounty is not paid again here
  • Duplicate reports are split by a published formula rather than being winner-take-all
  • Bugs in dependencies belong upstream with that project

Not accepted

  • Bugs in dependencies
  • Any encrypted credentials, auth tokens or similar checked into the repository
  • Attacks that require social engineering
  • Undeveloped automated tooling results such as raw scanner output
  • Anything whose source code does not exist in the repository
  • Vulnerability classes that are user error rather than library defects
  • Findings already rewarded under a protocol's own bounty

Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original

Changes

Tracked since 11 Nov 2026. Last checked 1 hour ago.

No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.

Public CVEs

Published vulnerabilities in this vendor's products, from the NVD.

Search NVD
CVESeverityPublished
CVE-2026-45137 High 8.2 27 May 2026

Original policy

Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.

Skip to content What this pays sorona.xyz pays 1.25× the program's reward, up to +$1,000 per finding, plus a complexity bonus of up to $1,000 for especially complex or well-chained bugs. Finding │ Program pays │ Through sorona.xyz Paid in SOL to stake accounts with a lockup expiring 12 months from delivery: the Critical band is 118 to 1,176 SOL, Medium 59 to 294, Low 1 to 59, with no USD equivalent published │ No published figure │ No published figure Submit a vulnerability CVE history 3 Last 12 months 3 Lifetime Access control 40 % Parsing/validation 25 % Memory safety 20 % Denial of service 10 % Latest advisories Loading the feed Overview Anchor is to Solana what OpenZeppelin and Hardhat together are to Ethereum: the large majority of Solana programs in production are written with it, and its #[derive(Accounts)] constraint system is the layer that actually enforces account ownership, signer checks and type discrimination: things that on Solana are the developer's responsibility rather than the runtime's. That inversion is what makes an Anchor defect so consequential: the Solana runtime does not check what Anchor checks, so a bypass of an Anchor constraint is an unauthorised-account bug in every program that relied on that constraint, simultaneously, across DeFi protocols, NFT marketplaces and staking programs. The framework's own eligibility rubric acknowledges it, asking whether a bug affects multiple contracts because a more widespread bug is generally indicative of a fundamental issue with the library. The Solana Foundation pays for reports here, but there is no publishable ceiling and none is quoted on this page: awards are denominated in SOL; the Critical band runs 118 to 1,176 SOL, and paid to stake accounts with a lockup expiring twelve months from the date of delivery, so what the award is worth in dollars is not something anyone can state at the moment you report it. Participation is conditioned on completing KYC and signing a participation agreement, so file with the Solana Foundation directly. sorona.xyz adds 1.25× on top of whatever the Foundation awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. In scope The repository is the boundary the program draws: anything whose source code exists in coral-xyz/anchor is in, and anything whose source does not is out The anchor-lang runtime crate and its account-validation layer: #[account] , #[derive(Accounts)] , constraint expressions, the discriminator mechanism, AccountLoader and the zero-copy paths The procedural macros behind #[program] , including instruction dispatch and whatever the derive macros actually expand to underneath the source a developer reads anchor-spl , the wrappers around SPL Token, Associated Token and Metaplex accounts that most Anchor programs use instead of writing those checks themselves IDL generation and the on-chain IDL account, together with the Borsh serialisation and deserialisation used on both sides of the boundary The Rust and TypeScript clients, anchor-client and @coral-xyz/anchor , covering coders, event parsing and transaction construction The anchor CLI and avm : build, verifiable build, test, deploy and upgrade, the tooling standing between reviewed source and the bytes that land on chain The program grades the whole of that surface: bypassing a fundamental Anchor check is Critical, denial of service is Medium, and everything remaining in the repository is Low Out of scope Bugs in dependencies, which the policy says to take upstream Any encrypted credentials, auth tokens or similar checked into the repository Attacks that require social engineering Undeveloped automated tooling results such as raw scanner output, though a finding carried through to a developed proof of concept is accepted Anything whose source code does not exist in the repository, including web properties not explicitly listed on the program page Vulnerability classes that are user error rather than library defects. The rubric asks whether the bug was public knowledge previously, which can make it a hazard for users of Anchor rather than an issue within Anchor. Findings already rewarded under a protocol's own bounty, which the policy will not pay a second time Awards to anyone who has not completed KYC and signed the Solana Foundation participation agreement Most-valued findings A bypass of a fundamental Anchor check, meaning account ownership, the discriminator, or memory safety. That is the program's named Critical class, and because Solana's runtime re-checks none of it, a live unauthorised-account bug in every program that trusted the constraint. Constraint expressions in #[derive(Accounts)] that can be made to pass when they should fail, particularly where the macro expands to something other than what the source reads as; access control is 40% of the expected distribution here Anything the rubric would call widespread, since the eligibility questions explicitly weight a bug affecting multiple contracts as evidence of a fundamental issue with the library rather than an isolated slip Deserialisation flaws in IDL generation or client-side decoding, where attacker-shaped account data is turned back into typed Rust or TypeScript on the other side of the boundary Denial of service against Anchor programs, the named Medium class, where a program can be made unusable by anyone who can submit an instruction Defects in the Anchor CLI and deployment tooling, which sit between a developer's reviewed source and the bytes that actually land on chain Program rules Submit through sorona.xyz first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards. Participants must complete KYC and sign the Solana Foundation participation agreement at solana.org/kyc before any award can be paid Awards are paid in SOL to stake accounts with a lockup expiring twelve months from the date of delivery, so what you are owed and what it will be worth are separate questions A developed proof of concept is required; undeveloped automated tooling results are not accepted, though a scanner finding with a working PoC is No double-dipping: a finding already rewarded under a protocol's own bounty is not paid again here Duplicate reports are split by a published formula rather than being winner-take-all Bugs in dependencies belong upstream with that project, and a previously public issue may be a vulnerability class for users of Anchor rather than a defect within Anchor itself Disclosure Coordinated through [email protected] and GitHub draft security advisories, run by the OtterSec incident-response groups; the policy commits to a response typically within 72 hours and to rolling weekly bounty awards. Because participation is conditioned on KYC and a signed agreement, file with the Solana Foundation directly rather than relying on a third party to do it for you, and hold the detail until the advisory publishes. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability