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

cert-manager

Bug bounty on Sorona cert-manager.io

Accepting reports open-source
Go to program Website
Top reward
$1,500
Top severity paid
Critical
Assets in scope
14
Public CVEs
2
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 Reward
Critical $1,500+
High $700+
Medium $300+
Low $100 $100 / 1 month Claude Max
Response
Within 3 days The policy targets a response within about 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

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, 5 excluded.

Web 1

  • https://cert-manager.io

Products and areas 13

  • Secret handling end to end: creation, ownership, the reference model between namespaces, and the garbage collection behaviour
  • The ACME implementation in full, covering account registration, order and authorization handling, and the Challenge and Order resources the controller creates and consumes
  • The admission webhooks and the CRD validation they perform, where a malformed or crafted resource reaches the controller
  • The CA and SelfSigned issuers and their handling of signing key material held in secrets
  • The controller reconciliation loops for Certificate, CertificateRequest, Issuer and ClusterIssuer, along with the state transitions between them
  • The DNS01 solvers and every provider integration shipped in the organisation, together with the credentials they read from cluster secrets
  • The HTTP01 solver, including the temporary Ingress or Gateway resources and the pods it creates in a cluster to answer a challenge
  • The Issuer policy surface: the solver selectors, the allowed domain configuration, and every rule that decides whether a given request may be fulfilled
  • The Kubernetes API interactions themselves, covering watch handling, cache behaviour and the resilience of the controller to hostile resource content
  • The policy declares its covered repositories explicitly: everything under the cert-manager GitHub organisation. That declaration is the scope, and the components below sit inside it
  • The RBAC and service account model the project ships, where an over-broad default role is a real finding
  • The sub-projects under the same organisation, including the CSI driver, trust-manager, approver-policy and the istio-csr integration
  • The Vault and Venafi issuer integrations and the credentials and tokens they hold
Out of scope (5)
  • A cluster operator's deliberate configuration choice, such as granting a namespace permission to create a ClusterIssuer
  • Attacks that assume cluster-admin, since that privilege already reaches every secret cert-manager touches
  • Copy-pasted scanner output and dependency-tree findings with no demonstrated impact, which the policy rules out by name
  • Defects in Kubernetes itself, in an ingress controller, or in a CA operating on the other side of ACME
  • Third-party issuer implementations maintained outside the cert-manager organisation

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.
  • Report privately to the address on the policy page , the intake the org-level policy publishes, or through GitHub private vulnerability reporting on the main repository
  • Copy-pasted scanner output is excluded by name. Show a reproduction against a running cluster, not a dependency-tree report
  • State the RBAC context.
  • Name the Issuer type and the solver.
  • Hold the detail until the advisory is public.

Not accepted

  • Copy-pasted scanner output and dependency-tree findings with no demonstrated impact
  • A cluster operator's deliberate configuration choice
  • Defects in Kubernetes itself, in an ingress controller, or in a CA operating on the other side of ACME
  • Third-party issuer implementations maintained outside the cert-manager organisation
  • Attacks that assume cluster-admin

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-25518 Medium 5.9 4 Feb 2026
CVE-2024-36537 High 7.2 24 Jul 2024

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 2 Last 12 months Authorization / policy bypass 45 % Denial of service 25 % Key material exposure 20 % Input validation 10 % Latest advisories Loading the feed Overview cert-manager is the controller that issues X.509 certificates inside Kubernetes, and in most clusters it is the only thing doing that job. It holds CA signing keys and ACME account keys in cluster secrets and decides which workload may obtain a certificate for which name. CVE-2026-62290 is the reference point: ACME Challenge resources created directly bypassed the DNS01 solver policy on the Issuer, so the guardrail on who may request what stopped applying. It is a CNCF graduated project with a mature written policy and no reward attached to it. sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy declares its covered repositories explicitly: everything under the cert-manager GitHub organisation. That declaration is the scope, and the components below sit inside it The controller reconciliation loops for Certificate, CertificateRequest, Issuer and ClusterIssuer, along with the state transitions between them The ACME implementation in full, covering account registration, order and authorization handling, and the Challenge and Order resources the controller creates and consumes The HTTP01 solver, including the temporary Ingress or Gateway resources and the pods it creates in a cluster to answer a challenge The DNS01 solvers and every provider integration shipped in the organisation, together with the credentials they read from cluster secrets The Issuer policy surface: the solver selectors, the allowed domain configuration, and every rule that decides whether a given request may be fulfilled The CA and SelfSigned issuers and their handling of signing key material held in secrets The Vault and Venafi issuer integrations and the credentials and tokens they hold The admission webhooks and the CRD validation they perform, where a malformed or crafted resource reaches the controller Secret handling end to end: creation, ownership, the reference model between namespaces, and the garbage collection behaviour The RBAC and service account model the project ships, where an over-broad default role is a real finding The sub-projects under the same organisation, including the CSI driver, trust-manager, approver-policy and the istio-csr integration The Kubernetes API interactions themselves, covering watch handling, cache behaviour and the resilience of the controller to hostile resource content Out of scope Copy-pasted scanner output and dependency-tree findings with no demonstrated impact, which the policy rules out by name A cluster operator's deliberate configuration choice, such as granting a namespace permission to create a ClusterIssuer Defects in Kubernetes itself, in an ingress controller, or in a CA operating on the other side of ACME Third-party issuer implementations maintained outside the cert-manager organisation Attacks that assume cluster-admin, since that privilege already reaches every secret cert-manager touches Most-valued findings Anything that lets a certificate be issued for a name the requester is not authorised to hold. CVE-2026-62290 reached exactly that by creating ACME Challenge resources directly, which bypassed the DNS01 solver policy configured on the Issuer Cross-namespace and cross-tenant boundary failures, where a workload in one namespace obtains a certificate, a secret or an issuer reference belonging to another Exposure of CA signing keys, ACME account keys or DNS provider credentials, all of which live in cluster secrets that cert-manager reads on every reconcile Controller denial of service reachable from data the controller does not control, the shape CVE-2026-25518 took with a crafted DNS response. A stalled controller means expired certificates across every workload Admission webhook bypasses, or crafted custom resources that survive validation and reach the reconcile loop in a state it does not expect Privilege escalation through the RBAC the project ships, particularly any path where creating a namespaced resource yields cluster-wide effect Defects in the solver pods and temporary Ingress or Gateway resources the HTTP01 path creates, since those are attacker-reachable from outside the cluster by design 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] , the intake the org-level policy publishes, or through GitHub private vulnerability reporting on the main repository The policy covers every repository under the cert-manager GitHub organisation, so a finding in a sub-project such as the CSI driver, trust-manager or the approver-policy controller is in scope on the same terms Copy-pasted scanner output is excluded by name. Show a reproduction against a running cluster, not a dependency-tree report State the RBAC context. Almost every finding here turns on what a given service account or namespace user may already do, and a report without that is not reproducible Name the Issuer type and the solver. ACME with HTTP01, ACME with DNS01, the CA issuer and the Vault issuer are separate trust models The policy targets a response within about three working days and offers no reward, so there is nothing to negotiate on payment Disclosure Coordinated privately with the cert-manager security team, who target a response within roughly three working days and publish a GitHub Security Advisory alongside a patched release. The 2026 record shows advisories going out individually rather than in batches. Cluster operators upgrade a certificate controller cautiously because a bad rollout stops renewals across every workload, so the practical exposure window runs well past the release date. Hold the detail until the advisory is public. 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