Skip to content
bugbounty.fyi
Get paid to secure open source 475 paid open-source programs on Sorona, up to $1M Perk Low bugs: $100 or 1 mo Claude Max

Also on Patchstack. All 476 paid open-source programs

Try

Highest paying Newly launched Paid without KYC Full safe harbor
All results

About this site

NATS

By sorona.xyz Bug bounty on Sorona nats.io

Accepting reports open-source
Go to program Website
Top reward
$1,500
Top severity paid
Critical
Assets in scope
14
Public CVEs
36
Last change
No changes yet

At a glance

What to know before you start testing.

Pays from $1,500
for critical bugs.
Report on Sorona
Submit through the program page.
Partial safe harbor
Some legal protection; read the terms.
Publish after a fix
Coordinate the timing with the company.

Rewards

What Sorona lists as the payout for each severity.

Severity Reward
Critical $1,500+
High $700+
Medium $300+
Low $100 $100 / 1 month Claude Max
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

14 assets you may test, 6 excluded.

Web 1

  • https://nats.io

Products and areas 13

  • Authentication across tokens, username and password, NKeys, JWT-based users and mutual TLS, plus the certificate-to-identity mapping
  • Cluster routes, gateways, leafnodes and superclusters, and the trust each establishes between servers
  • JetStream end to end: streams, consumers, the key-value and object stores, the JetStream API subjects and the permission checks on each
  • Queue groups, subject mapping, subject transforms and the wildcard matching behind all of them
  • The accounts model in full: subject-level publish and subscribe permissions, allow and deny lists, response permissions, and imports and exports between accounts
  • The advisory policy asks for private reports at [email protected] with GitHub Security Advisories used for publication, and declares no boundary narrower than the NATS server
  • The client protocol parser, the connection handshake and everything the server accepts before a client is authenticated
  • The embedded server library that other Go programs link and run in-process
  • The monitoring HTTP endpoints and what an unauthenticated caller can read from them
  • The MQTT and WebSocket gateways the server implements, each with its own protocol handling and its own authentication mapping
  • The operator and account JWT chain, the account resolver that fetches JWTs, signature verification on them and the revocation lists they carry
  • The system account and the $SYS subjects that expose server, connection and client state
  • TLS configuration on every listener, including certificate verification and the handshake with peer servers
Out of scope (6)
  • A deployment deliberately run with no authentication, which the documentation describes as a development configuration
  • Client libraries maintained in their own repositories
  • NATS-adjacent tooling outside nats-io/nats-server, unless the defect is in the server itself
  • Resource consumption within limits an operator configured
  • Synadia Cloud and other hosted deployments at the infrastructure level
  • The applications publishing and subscribing

Rules

What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy. "We" in these lines means Sorona, not this site.

While testing

  • Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly.
  • Report privately to the address on the policy page , per the NATS project security advisory policy. Advisories are published on GitHub after a fix
  • Give the full server configuration or the operator, account and user JWTs that reproduce it. Everything severe here turns on how a credential resolved to permissions
  • Say whether the deployment used static configuration accounts or the decentralised JWT model with an account resolver. Those are different trust chains with different code
  • Name the topology. A single server, a cluster, a leafnode and a supercluster gateway each establish trust differently and a finding on one may not exist on the others
  • State whether JetStream was enabled, since that adds persistence, a separate API and its own permission checks on top of core subjects

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-2023-46129 High 7.5 31 Oct 2023
CVE-2022-26652 Medium 6.5 10 Mar 2022
CVE-2022-24450 High 8.8 8 Feb 2022
CVE-2021-3127 High 7.5 16 Mar 2021

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 This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 26 Last 12 months 36 Lifetime Access control 40 % Auth bypass 25 % Info disclosure 20 % Parsing/validation 15 % Latest advisories Loading the feed Overview NATS is the messaging fabric inside a lot of cloud-native, IoT and edge systems. A single Go binary makes it trivial to embed, and JetStream adds persistence, so it ends up carrying control-plane commands and application data across trust boundaries in the same deployment. Its accounts and subject permissions are the entire tenancy model, so a permission-evaluation defect lets one tenant subscribe to another's subjects and read everything published there. The project states in writing that there is no bug bounty for either NATS or Synadia. sorona.xyz pays you directly on qualified, reproduced findings. In scope The advisory policy asks for private reports at [email protected] with GitHub Security Advisories used for publication, and declares no boundary narrower than the NATS server The client protocol parser, the connection handshake and everything the server accepts before a client is authenticated Authentication across tokens, username and password, NKeys, JWT-based users and mutual TLS, plus the certificate-to-identity mapping The accounts model in full: subject-level publish and subscribe permissions, allow and deny lists, response permissions, and imports and exports between accounts The operator and account JWT chain, the account resolver that fetches JWTs, signature verification on them and the revocation lists they carry JetStream end to end: streams, consumers, the key-value and object stores, the JetStream API subjects and the permission checks on each Cluster routes, gateways, leafnodes and superclusters, and the trust each establishes between servers The system account and the $SYS subjects that expose server, connection and client state TLS configuration on every listener, including certificate verification and the handshake with peer servers The MQTT and WebSocket gateways the server implements, each with its own protocol handling and its own authentication mapping Queue groups, subject mapping, subject transforms and the wildcard matching behind all of them The monitoring HTTP endpoints and what an unauthenticated caller can read from them The embedded server library that other Go programs link and run in-process Out of scope Synadia Cloud and other hosted deployments at the infrastructure level Client libraries maintained in their own repositories NATS-adjacent tooling outside nats-io/nats-server , unless the defect is in the server itself A deployment deliberately run with no authentication, which the documentation describes as a development configuration The applications publishing and subscribing Resource consumption within limits an operator configured Most-valued findings Account isolation failures, any path where a client publishes to or subscribes on a subject its permissions do not grant. Crossing an account boundary through an import, an export or a subject mapping is the highest-value shape here JWT and NKey verification defects in the operator and account chain, where a forged, expired or revoked credential is accepted. That chain is the whole decentralised trust model Leafnode and gateway trust defects letting one cluster inject messages into another or subscribe across the boundary, since edge deployments connect untrusted networks this way JetStream permission checks on streams, consumers and the key-value store, which hold data at rest rather than only in flight The system account and $SYS subjects reachable by an ordinary user, exposing every connection and its credentials metadata Wildcard and subject matching that resolves wider than the permission reads, which silently grants access nobody wrote down Protocol parser defects reachable before authentication completes, given the listener accepts bytes from anything on the network The monitoring endpoints leaking connection detail, account names or configuration to an unauthenticated caller Anything in the embedded server library reachable from the host program, since a defect there lands inside another application's process Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report privately to [email protected] , per the NATS project security advisory policy. Advisories are published on GitHub after a fix The project states there is no bug bounty system in place for either Synadia or NATS. There is nothing to negotiate at any severity Give the full server configuration or the operator, account and user JWTs that reproduce it. Everything severe here turns on how a credential resolved to permissions Say whether the deployment used static configuration accounts or the decentralised JWT model with an account resolver. Those are different trust chains with different code Name the topology. A single server, a cluster, a leafnode and a supercluster gateway each establish trust differently and a finding on one may not exist on the others State whether JetStream was enabled, since that adds persistence, a separate API and its own permission checks on top of core subjects Disclosure Coordinated privately through the security address under the NATS project security advisory policy, published as an advisory and a GitHub Security Advisory once a fixed release is out. Because the server is embedded as a library in other Go programs as well as run standalone, coordination runs to that release rather than to a day count you choose. 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