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

step-ca

By sorona.xyz Bug bounty on Sorona smallstep.com

Accepting reports open-source
Go to program Website
Top reward
$1,500
Top severity paid
Critical
Assets in scope
14
Public CVEs
4
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://smallstep.com/docs/step-ca

Products and areas 13

  • Certificate templates, the claims a provisioner enforces and the constraints it applies to a request's subject, SANs, key usages and validity
  • Every provisioner type: JWK, OIDC, AWS, GCP and Azure instance identity, X5C, SSHPOP, K8sSA, ACME, SCEP and Nebula
  • Renewal and rekey, including the mutual TLS authenticated renewal endpoint where the presented certificate is the credential
  • Revocation end to end: the revocation endpoints, the CRL, the OCSP responder and the SSH revocation list
  • The ACME server and every challenge type it implements: http-01, dns-01, tls-alpn-01 and device-attest-01, along with account handling, order state and the authorization objects behind them
  • The admin API, the provisioner and admin management endpoints, and registration authority mode where step-ca fronts another CA
  • The bootstrap and trust establishment flow, including how a client first learns and pins the CA's root
  • The CA's own key handling and every KMS integration, covering PKCS#11 modules, YubiKey and the cloud KMS backends
  • The database backends storing issued certificates, provisioner state and revocation records
  • The published policy asks for reports at [email protected] and appreciates responsible disclosure without offering a reward. It declares no boundary narrower than step-ca itself
  • The SCEP server, its challenge handling, the enrolment and renewal operations and the PKCS#7 and PKCS#10 processing beneath them
  • The SSH certificate authority: host and user certificate issuance, principal handling, extensions, critical options and the SSH-specific provisioner paths
  • The step CLI where it interacts with the CA, and the ACME and SCEP client behaviour the project ships
Out of scope (6)
  • A provisioner an operator configured with deliberately loose constraints
  • Hardware security modules and cloud KMS backends themselves, which belong to their vendors
  • Local key material on a machine an attacker already controls
  • The applications and operating systems that decide whether to trust the CA's root, which is a deployment decision
  • The DNS and HTTP infrastructure a challenge is validated against, unless step-ca's validation of it is what fails
  • Third-party ACME and SCEP clients

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 , the address the GitHub security policy publishes.
  • The embargoed pre-notification list at u.step.sm/disclosure exists so production operators hear about a fix early. It is not a reporting channel
  • Name the provisioner type and its configuration.
  • Say which protocol the finding runs over.
  • Give the certificate that came out, in full, alongside the request that produced it.

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-40097 Low 3.7 10 Apr 2026
CVE-2026-30836 Critical 10.0 19 Mar 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 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 4 Last 12 months 4 Lifetime Authorization bypass 45 % Certificate constraints 25 % Revocation handling 20 % Info disclosure 10 % Latest advisories Loading the feed Overview step-ca is the private certificate authority a great many DevOps and internal PKI setups run, issuing X.509 and SSH certificates automatically over ACME and SCEP. It is the trust anchor: whatever it signs, every machine configured against it accepts without further question. GHSA-h8cp-697h-8c8p is the reference point, an authorization bypass in the ACME and SCEP paths, meaning a certificate issued to a party that never proved it should have one. Smallstep's security policy asks for reports at a security address, thanks reporters for disclosing responsibly and offers nothing beyond that. sorona.xyz pays you directly on qualified, reproduced findings. In scope The published policy asks for reports at [email protected] and appreciates responsible disclosure without offering a reward. It declares no boundary narrower than step-ca itself The ACME server and every challenge type it implements: http-01, dns-01, tls-alpn-01 and device-attest-01, along with account handling, order state and the authorization objects behind them The SCEP server, its challenge handling, the enrolment and renewal operations and the PKCS#7 and PKCS#10 processing beneath them Every provisioner type: JWK, OIDC, AWS, GCP and Azure instance identity, X5C, SSHPOP, K8sSA, ACME, SCEP and Nebula Certificate templates, the claims a provisioner enforces and the constraints it applies to a request's subject, SANs, key usages and validity The SSH certificate authority: host and user certificate issuance, principal handling, extensions, critical options and the SSH-specific provisioner paths Renewal and rekey, including the mutual TLS authenticated renewal endpoint where the presented certificate is the credential Revocation end to end: the revocation endpoints, the CRL, the OCSP responder and the SSH revocation list The CA's own key handling and every KMS integration, covering PKCS#11 modules, YubiKey and the cloud KMS backends The admin API, the provisioner and admin management endpoints, and registration authority mode where step-ca fronts another CA The database backends storing issued certificates, provisioner state and revocation records The bootstrap and trust establishment flow, including how a client first learns and pins the CA's root The step CLI where it interacts with the CA, and the ACME and SCEP client behaviour the project ships Out of scope The applications and operating systems that decide whether to trust the CA's root, which is a deployment decision Hardware security modules and cloud KMS backends themselves, which belong to their vendors A provisioner an operator configured with deliberately loose constraints Local key material on a machine an attacker already controls Third-party ACME and SCEP clients The DNS and HTTP infrastructure a challenge is validated against, unless step-ca's validation of it is what fails Most-valued findings Any path issuing a certificate to a requester whose authorization did not cover the identity requested. That is the GHSA-h8cp-697h-8c8p shape across both the ACME and SCEP paths and it is the highest-severity class this project has ACME challenge validation, where accepting a challenge that was not actually satisfied is issuance to an unverified party for a name they do not control SCEP enrolment and challenge handling, the area CVE-2026-30836 sits in and a protocol whose age shows in its authentication model Provisioner claim and template enforcement producing a certificate with SANs, principals, key usages or validity the provisioner should have refused Revocation handling, since a certificate that stays valid after revocation is the failure GHSA-j7c9-79x7-8hpr describes on the SSH side, and the same question applies to the CRL and OCSP paths SSH certificate issuance and principal handling, where a host or user certificate names a principal the requester was not entitled to, which is direct access to the machines trusting that CA Renewal and rekey paths letting an expiring, revoked or constrained identity refresh itself into something broader CA key handling across the KMS integrations, including anything that signs with a key the operator believed was not usable that way The admin API and registration authority mode, where control of provisioner configuration is control of issuance for the whole estate 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 address the GitHub security policy publishes. Advisories are published as GHSAs on smallstep/certificates Nothing is paid at any severity. The policy says only that the project appreciates any effort to discover and disclose security vulnerabilities responsibly The embargoed pre-notification list at u.step.sm/disclosure exists so production operators hear about a fix early. It is not a reporting channel Name the provisioner type and its configuration. Every issuance decision in step-ca runs through a provisioner and a finding is only meaningful against a specific one Say which protocol the finding runs over. ACME, SCEP, the JWK enrolment path and the SSH endpoints each have their own authorization code Give the certificate that came out, in full, alongside the request that produced it. The gap between the two is the finding Disclosure Coordinated privately with Smallstep through the security address, with an embargoed pre-notification to production operators on the published disclosure list before a GitHub Security Advisory and a fixed release go out. Because step-ca issues the trust anchors other systems rely on, the 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