Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/smallstep/certificates >= 0.24.0, < 0.30.0
Fixed in
0.30.0· Vendor fix available
Issue
An attacker can trigger an index out-of-bounds panic in Step CA by sending a crafted attestation key (AK) certificate with an empty Extended Key Usage (EKU) extension during TPM device attestation. Details When processing a device-attest-01 ACME challenge using TPM attestation, Step CA validates that the AK certificate contains the tcg-kp-AIKCertificate Extended Key Usage OID. During this validation, the EKU extension value is decoded from its ASN.1 representation and the first element is checked. A crafted certificate could include an EKU extension that decodes to an empty sequence, causing the code to panic when accessing the first element of the empty slice. This vulnerability is only reachable when a device-attest-01 ACME challenge with TPM attestation is configured. Deployments not using TPM device attestation are not affected. Mitigations If you are unable to upgrade to v0.30.0 or newer, the attack can be mitigated by disabling or removing any ACME provisioners that use…
Recommended action: Upgrade to 0.30.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An attacker can force a Step CA SCEP provisioner to create certificates without completing certain protocol authorization checks. Details SCEP requests carry a message type. On receipt of a SCEP request, Step CA starts processing it by parsing its contents. Message types that were considered valid, but not explicitly supported in Step CA, would result in getting parsed successfully. While processing the parsed SCEP message, authorization logic would be skipped for the non-supported message types. As a result, the request would be treated as authorized, bypassing the authorization checks normally enforced as part of the SCEP protocol and its implementation in Step CA. Authorization webhooks and regular CA policies, such as allowed names and restrictions on certificate validity periods, remain in place. Mitigations If you are unable to upgrade to v0.30.0 or newer, the attack can be mitigated by (temporarily) disabling or removing SCEP provisioners, or restricting access to SCEP…
Recommended action: Upgrade to 0.30.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A security fix is now available for Step CA that resolves a vulnerability affecting deployments configured with ACME and/or SCEP provisioners. All operators running these provisioners should upgrade to the latest release (v0.29.0) immediately. The issue was discovered and disclosed by a research team during a security review. There is no evidence of active exploitation. To limit exploitation risk during a coordinated disclosure window, we are withholding detailed technical information for now. A full write-up will be published in several weeks. --- Embargo List If your organization runs Step CA in production and would like advance, embargoed notification of future security updates, visit https://u.step.sm/disclosure to request inclusion on our embargo list. --- Acknowledgements This issue was identified and reported by Stephen Kubik of the Cisco Advanced Security Initiatives Group (ASIG) --- Stay safe, and thank you for helping us keep the ecosystem secure.
Recommended action: Upgrade to 0.29.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An authorized attacker can bypass authorization checks and revoke any SSH certificate issued by Step CA by using a valid revocation token. Details Step CA users can obtain SSH certificates from a few provisioners. The SSHPOP provisioner allows revocation of the SSH certificate (preventing future certificate renewals) using a token. Due to a missing validity check, this token could be used to revoke any SSH certificate issued by the CA. To create a token, an attacker must have access to the CA endpoint and a valid SSH certificate, meaning they were already authorized to obtain an SSH certificate. The attacker must also know the serial number of the certificate they want to revoke. Impact There is no way to mitigate this attack. It is recommended to update to v0.29.0 or newer. Fix In v0.29.0, the token validation logic was strengthened to bind each token to a specific SSH certificate serial number. Acknowledgements This issue was identified and reported by Gabriel Departout and…
Recommended action: Upgrade to 0.29.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.