- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 13
- Public CVEs
- 20
- 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.
- Replies within 3 days
- As the policy promises.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- Response
-
Within 3 days
The published process acknowledges within three working days
- 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
13 assets you may test, 6 excluded.
Web 1
- https://etcd.io
Products and areas 12
- etcdctl and etcdutl, the tools that read, write, snapshot and repair a cluster's data
- The authentication subsystem end to end: users, roles, key-range permissions, the simple and JWT token providers, and the enable and disable transitions
- The bbolt storage backend as etcd uses it, plus the MVCC layer, compaction and defragmentation
- The gateway and proxy modes the project ships
- The gRPC gateway that exposes the same API over HTTP and JSON, along with the endpoints it derives
- The metrics, health and debug endpoints the server exposes, and what an unauthenticated caller can read from them
- The published process asks for any undisclosed vulnerability privately at [email protected] and declares no boundary narrower than the etcd tree itself. Everything below sits inside that
- The Raft implementation and the peer protocol behind it, including membership reconfiguration and the promotion of learners to voting members
- The v3 client API over gRPC in full, covering the key-value, watch, lease, lock and election services
- The write-ahead log, snapshot creation and snapshot restore, all of which parse files a node accepts from another node or from an operator
- TLS handling on both the client and peer listeners, including client certificate authentication and the mapping from a certificate common name to an etcd identity
- Watch and lease handling, where a stream established once continues to deliver key events over time
Out of scope (6)
- An etcd deliberately run without authentication or TLS, which is a deployment decision rather than an etcd defect
- bbolt, gRPC and the Go standard library as upstream projects, unless etcd's own use of them is what makes the defect reachable
- Kubernetes itself, which has its own project and its own paid programme
- Reports filed as public GitHub issues, which take the finding outside the coordinated process
- Resource consumption from writes an authorised client is permitted to make
- Third-party etcd operators, Helm charts and packaged distributions
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 , which reaches the etcd Product Security Committee. The published process acknowledges within three working days
-
Do not file this at the Kubernetes HackerOne programme. That programme pays, and its announcement names etcd as an out-of-scope dependency that should go to the appropriate party instead
-
Say whether the target is an in-cluster etcd behind the Kubernetes API server or a standalone deployment. The reachable surface differs enormously between the two
-
Give the etcd version, the client and peer TLS configuration and whether the auth subsystem was enabled. Most severe findings here turn on the identity check rather than on the storage layer
-
Hold detail until that release is out.
Not accepted
-
Kubernetes itself, which has its own project and its own paid programme
-
An etcd deliberately run without authentication or TLS, which is a deployment decision rather than an etcd defect
-
bbolt, gRPC and the Go standard library as upstream projects, unless etcd's own use of them is what makes the defect reachable
-
Third-party etcd operators, Helm charts and packaged distributions
-
Reports filed as public GitHub issues, which take the finding outside the coordinated process
-
Resource consumption from writes an authorised client is permitted to make
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.
| CVE | Summary | Severity | Published |
|---|---|---|---|
| CVE-2026-59818 | etcd is a distributed key-value store for the data of a distributed system. Prior to 3.5.32 and 3.6.13, when etcd is configured with --listen-client-http-urls to split HTTP and gRPC client endpoints onto separate listeners, the --client-crl-file Certificate Revocation List is not enforced on the gRPC listener, allowing a client with a revoked certificate to authenticate successfully over gRPC. Thi | Medium 6.5 | 8 Jul 2026 |
| CVE-2026-44283 | etcd is a distributed key-value store for the data of a distributed system. Prior to 3.4.44, 3.5.30, and 3.6.11, a vulnerability in etcd allows read access via PrevKv, or lease attachment in Put requests within transaction operations, to bypass RBAC authorization checks. An authenticated user without sufficient read or lease-related permissions may be able to access unauthorized data or attach lea | – | 14 May 2026 |
| CVE-2026-33343 | etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.4.42, 3.5.28, and 3.6.9, an authenticated user with RBAC restricted permissions on key ranges can use nested transactions to bypass all key-level authorization. This allows any authenticated user with direct access to etcd to effectively ignore all key range restrictions, accessing the entire etcd data | – | 26 Mar 2026 |
| CVE-2026-33413 | etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.4.42, 3.5.28, and 3.6.9, unauthorized users may bypass authentication or authorization checks and call certain etcd functions in clusters that expose the gRPC API to untrusted or partially trusted clients. In unpatched etcd clusters with etcd auth enabled, unauthorized users are able to call MemberList | High 8.8 | 26 Mar 2026 |
| CVE-2022-34038 | Etcd v3.5.4 allows remote attackers to cause a denial of service via function PageWriter.write in pagewriter.go. NOTE: the vendor's position is that this is not a vulnerability. | High 7.5 | 22 Aug 2023 |
| CVE-2023-32082 | etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.4.26 and 3.5.9, the LeaseTimeToLive API allows access to key names (not value) associated to a lease when `Keys` parameter is true, even a user doesn't have read permission to the keys. The impact is limited to a cluster which enables auth (RBAC). Versions 3.4.26 and 3.5.9 fix this issue. There are no k | Low 3.1 | 11 May 2023 |
| CVE-2021-28235 | Authentication vulnerability found in Etcd-io v.3.4.10 allows remote attackers to escalate privileges via the debug function. | Critical 9.8 | 4 Apr 2023 |
| CVE-2020-15112 | In etcd before versions 3.3.23 and 3.4.10, it is possible to have an entry index greater then the number of entries in the ReadAll method in wal/wal.go. This could cause issues when WAL entries are being read during consensus as an arbitrary etcd consensus participant could go down from a runtime panic when reading the entry. | Medium 6.5 | 5 Aug 2020 |
| CVE-2020-15113 | In etcd before versions 3.3.23 and 3.4.10, certain directory paths are created (etcd data directory and the directory path when provided to automatically generate self-signed certificates for TLS connections with clients) with restricted access permissions (700) by using the os.MkdirAll. This function does not perform any permission checks when a given directory path exists already. A possible wor | Medium 5.7 | 5 Aug 2020 |
| CVE-2020-15106 | In etcd before versions 3.3.23 and 3.4.10, a large slice causes panic in decodeRecord method. The size of a record is stored in the length field of a WAL file and no additional validation is done on this data. Therefore, it is possible to forge an extremely large frame size that can unintentionally panic at the expense of any RAFT participant trying to decode the WAL. | Medium 6.5 | 5 Aug 2020 |
| CVE-2018-16886 | etcd versions 3.2.x before 3.2.26 and 3.3.x before 3.3.11 are vulnerable to an improper authentication issue when role-based access control (RBAC) is used and client-cert-auth is enabled. If an etcd client server TLS certificate contains a Common Name (CN) which matches a valid RBAC username, a remote attacker may authenticate as that user with any valid (trusted) client certificate in a REST API | High 8.1 | 14 Jan 2019 |
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 6 Last 12 months 20 Lifetime Access control 40 % Auth bypass 25 % Consensus/state integrity 20 % Info disclosure 15 % Latest advisories Loading the feed Overview etcd is the datastore behind the Kubernetes control plane. Every object in a cluster lives in it: Secrets, ServiceAccount tokens, RBAC rules, the lot. It also runs standalone under CoreDNS and a range of other distributed systems. Read access to etcd is read access to every credential the cluster holds, so a defect in its authentication or its transport is a cluster takeover rather than a database bug. The paid Kubernetes bug bounty names etcd as out of scope and sends reporters elsewhere, and etcd operates no programme of its own. sorona.xyz pays you directly on qualified, reproduced findings. In scope The published process asks for any undisclosed vulnerability privately at [email protected] and declares no boundary narrower than the etcd tree itself. Everything below sits inside that The v3 client API over gRPC in full, covering the key-value, watch, lease, lock and election services The gRPC gateway that exposes the same API over HTTP and JSON, along with the endpoints it derives The authentication subsystem end to end: users, roles, key-range permissions, the simple and JWT token providers, and the enable and disable transitions TLS handling on both the client and peer listeners, including client certificate authentication and the mapping from a certificate common name to an etcd identity The Raft implementation and the peer protocol behind it, including membership reconfiguration and the promotion of learners to voting members The write-ahead log, snapshot creation and snapshot restore, all of which parse files a node accepts from another node or from an operator The bbolt storage backend as etcd uses it, plus the MVCC layer, compaction and defragmentation Watch and lease handling, where a stream established once continues to deliver key events over time etcdctl and etcdutl , the tools that read, write, snapshot and repair a cluster's data The metrics, health and debug endpoints the server exposes, and what an unauthenticated caller can read from them The gateway and proxy modes the project ships Out of scope Kubernetes itself, which has its own project and its own paid programme An etcd deliberately run without authentication or TLS, which is a deployment decision rather than an etcd defect bbolt, gRPC and the Go standard library as upstream projects, unless etcd's own use of them is what makes the defect reachable Third-party etcd operators, Helm charts and packaged distributions Reports filed as public GitHub issues, which take the finding outside the coordinated process Resource consumption from writes an authorised client is permitted to make Most-valued findings Authentication bypass on the v3 API. An unauthenticated read of the key space is a read of every Kubernetes Secret and ServiceAccount token in the cluster Permission evaluation defects where a role grants access to a key range wider than the range it was written for, including prefix and interval handling Certificate-based identity defects, where the common name or SAN a peer or client presents maps to an etcd identity it should not receive Raft and peer protocol handling that lets a node inject, reorder or roll back committed state, since consistency here is what the whole control plane assumes Membership reconfiguration paths that admit a node into the cluster without the authorisation the operator intended Watch and lease paths that continue to deliver key material after the permission granting them was revoked Write-ahead log and snapshot parsing, since a node accepts these from restore and from other members Metrics, health and debug endpoints that expose key names, cluster topology or token material to an unauthenticated caller 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] , which reaches the etcd Product Security Committee. The published process acknowledges within three working days Do not file this at the Kubernetes HackerOne programme. That programme pays, and its announcement names etcd as an out-of-scope dependency that should go to the appropriate party instead The process is documented in security/README.md and security-release-process.md in the etcd repository, and disclosure typically follows about a week after the report Say whether the target is an in-cluster etcd behind the Kubernetes API server or a standalone deployment. The reachable surface differs enormously between the two Give the etcd version, the client and peer TLS configuration and whether the auth subsystem was enabled. Most severe findings here turn on the identity check rather than on the storage layer Nothing is paid at any severity and there are no reward terms to accept Disclosure Coordinated privately with the Product Security Committee, which acknowledges within three working days and drives a fix through the etcd security release process before publishing. Because etcd ships inside Kubernetes distributions, the practical embargo runs to the coordinated patch release rather than to a date you set. Hold detail until that release is out. 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