- Top reward
- $3,125
- Top severity paid
- High
- Assets in scope
- 7
- Public CVEs
- 1
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays up to $3,125
- for high bugs, from $125.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Replies within 1 day
- 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 |
|---|---|---|
| High |
|
$3,125 |
| Medium |
|
$625 |
| Low |
|
$125 |
- Response
-
Within 1 days
1 business day First response
- 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
7 assets you may test, 7 excluded.
Web 1
- https://github.com/kubernetes/kube-state-metrics
Products and areas 6
- Both HTTP servers the binary runs: the unauthenticated /metrics endpoint and the separate self-telemetry port, along with their TLS settings and request handlers
- Sharding, including the auto-sharding path where the pod reads its own StatefulSet, plus the CLI flags and configuration file that drive the whole process
- The custom-resource-state configuration and the --metric-labels-allowlist and --metric-annotations-allowlist flags, the paths that let an operator opt arbitrary object fields into metrics
- The Kubernetes client and informer layer, and the cluster-wide list and watch the exporter holds over nearly every object type
- The kubernetes/kube-state-metrics repository, which the program lists as a bounty-eligible source-code asset up to critical severity under the instruction "Add-on agent to generate and expose cluster-level metrics", priced at Tier 2: $100 at Low rising to $5,000 at Critical
- The metric generators for every object type the exporter reflects, which is effectively the whole built-in Kubernetes API surface: Pods, Deployments, Nodes, Services, Secrets, ConfigMaps, ServiceAccounts and the rest
Out of scope (7)
- Deprecated components, which are not supported targets
- Insecure configurations, notably an operator who deliberately allow-listed sensitive labels
- Intentionally disclosed information, which for this project is most of what it emits
- Kubernetes on Windows or other non-Linux platforms
- Prometheus, Grafana and the rest of the downstream stack, which are separate projects with no bounty at all
- Releases outside the three most recent, which the Kubernetes program does not treat as supported
- The absence of authentication on /metrics as a finding in itself, since that is the documented deployment model. A report has to show something reaching the endpoint that was never meant to be there
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.
-
Intentionally disclosed information is out of scope
-
Findings that depend on an operator deliberately allow-listing sensitive labels are treated as insecure configuration rather than a vulnerability
-
Non-Linux platforms and deprecated components are not supported targets
-
The public disclosure date is negotiated with the Kubernetes Security Response Committee rather than set by you
Not accepted
-
Intentionally disclosed information
-
Insecure configurations
-
The absence of authentication on /metrics as a finding in itself
-
Kubernetes on Windows or other non-Linux platforms
-
Deprecated components
-
Releases outside the three most recent
-
Prometheus, Grafana and the rest of the downstream stack
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 10 minutes 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.
Sorona credits this project with 1 CVEs. The individual records appear here after the next sync.
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 Critical (Tier 2 asset) │ $5,000 │ $6,000 High │ $2,500 │ $3,125 Medium │ $500 │ $625 Low │ $100 │ $125 Submit a vulnerability CVE history 0 Last 12 months 1 Lifetime Info disclosure 55 % Access control 20 % Denial of service 13 % Parsing/validation 10 % Latest advisories Loading the feed Overview kube-state-metrics is the component that makes Kubernetes observable, and it is installed by default in essentially every Prometheus-based monitoring stack: kube-prometheus-stack, the Prometheus Operator, Grafana Cloud's Kubernetes integration, Datadog's and New Relic's Kubernetes bundles, and every managed provider's monitoring add-on. If a cluster has dashboards showing pod and deployment state, this binary is running in it. Its privilege position is the whole story, because it holds cluster-wide list and watch on effectively every object type, including Secrets metadata, and publishes what it sees on an unauthenticated HTTP endpoint that in the standard deployment is reachable by anything on the pod network. That combination makes it the most attractive info-disclosure target in a default monitoring installation: no credentials needed, a network position any compromised pod already has, and a component whose job is to describe the entire cluster. CVE-2019-10223 proved the thesis when an experimental feature reflected Secret contents straight into the metrics endpoint. The CNCF pays it on the Kubernetes program at HackerOne as a Tier 2 asset, $100 at Low rising to $5,000 at Critical, and sorona.xyz adds 1.25× on top of whatever the CNCF awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. Response times 1 business day First response 10 business days Triage 10 business days Bounty In scope The kubernetes/kube-state-metrics repository, which the program lists as a bounty-eligible source-code asset up to critical severity under the instruction "Add-on agent to generate and expose cluster-level metrics", priced at Tier 2: $100 at Low rising to $5,000 at Critical The metric generators for every object type the exporter reflects, which is effectively the whole built-in Kubernetes API surface: Pods, Deployments, Nodes, Services, Secrets, ConfigMaps, ServiceAccounts and the rest The custom-resource-state configuration and the --metric-labels-allowlist and --metric-annotations-allowlist flags, the paths that let an operator opt arbitrary object fields into metrics Both HTTP servers the binary runs: the unauthenticated /metrics endpoint and the separate self-telemetry port, along with their TLS settings and request handlers The Kubernetes client and informer layer, and the cluster-wide list and watch the exporter holds over nearly every object type Sharding, including the auto-sharding path where the pod reads its own StatefulSet, plus the CLI flags and configuration file that drive the whole process Out of scope Intentionally disclosed information, which for this project is most of what it emits Insecure configurations, notably an operator who deliberately allow-listed sensitive labels The absence of authentication on /metrics as a finding in itself, since that is the documented deployment model. A report has to show something reaching the endpoint that was never meant to be there Kubernetes on Windows or other non-Linux platforms Deprecated components, which are not supported targets Releases outside the three most recent, which the Kubernetes program does not treat as supported Prometheus, Grafana and the rest of the downstream stack, which are separate projects with no bounty at all Most-valued findings Secret or credential material reaching the unauthenticated /metrics endpoint, the CVE-2019-10223 shape and by a wide margin the highest-value class here A metric generator that leaks the contents of a ConfigMap, ServiceAccount token or annotation that was never meant to become a metric value A custom-resource-state or label-allowlist path that lets someone who can write an object choose what gets published cluster-wide Anything that widens the exporter's effective read beyond its intended object set, turning its cluster-wide list and watch into a general read primitive A crafted object that stalls or crashes the collection loop, blinding monitoring for the whole cluster 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. Intentionally disclosed information is out of scope, and for this project that is most of what it emits, so the argument is always whether the exposed field was ever meant to be a metric Findings that depend on an operator deliberately allow-listing sensitive labels are treated as insecure configuration rather than a vulnerability Non-Linux platforms and deprecated components are not supported targets The asset sits at Tier 2, so the reachable ladder runs $100 to $5,000 The public disclosure date is negotiated with the Kubernetes Security Response Committee rather than set by you Program stats 141 Reports resolved $112k Bounties paid 60% Response efficiency Disclosure Coordinated through the Kubernetes Security Response Committee, which negotiates a public disclosure date with the reporter and prefers full disclosure as soon as user mitigation is available. For an exporter that leaks, mitigation normally means a release plus guidance for operators to rotate whatever was exposed, and sorona.xyz holds your finding until that agreed date. 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