CVE-2026-30836: 
NixOS vulnerability analysis and mitigation

CVE-2026-30836 is a critical authorization bypass vulnerability in Smallstep's Step CA (certificate authority software) that allows unauthenticated attackers to issue certificates via the SCEP provisioner by exploiting unsupported SCEP message types (specifically UpdateReq, MessageType=18). It affects all versions of github.com/smallstep/certificates prior to v0.30.0, including release candidates rc1 through rc6. The vulnerability was published on March 19, 2026, with a CVSS v3.1 base score of 10.0 (Critical) (Github Advisory, Smallstep Advisory). It was discovered and reported by Prasanth Sundararajan (Smallstep Advisory).

The root cause is improper authentication and missing validation of SCEP message types (CWE-287, CWE-295, CWE-306). When Step CA receives a SCEP request, it parses the message type before applying authorization logic. Message types that were considered syntactically valid but not explicitly supported — such as UpdateReq (MessageType=18) — were parsed successfully, but the authorization logic was then skipped entirely for these unsupported types, causing the request to be treated as pre-authorized (Smallstep Advisory). An unauthenticated remote attacker with network access to the SCEP endpoint can craft a SCEP request using an unsupported message type to bypass challenge-password verification and other authorization checks. The fix, introduced in commit e6da031, adds an explicit else branch that returns a BadRequest failure for any message type not explicitly handled, and removes UpdateReq from the set of types processed in DecryptPKIEnvelope (Patch Commit).

Successful exploitation allows an unauthenticated attacker to obtain fraudulently issued X.509 certificates from the Step CA instance without satisfying the SCEP protocol's authorization requirements (e.g., challenge password verification). This compromises both confidentiality and integrity at a scope beyond the directly vulnerable component, as rogue certificates can be used to impersonate services, perform man-in-the-middle attacks, decrypt TLS traffic, or authenticate to systems that trust the CA. Notably, authorization webhooks and standard CA policies (allowed names, validity period restrictions) remain enforced, but the core authentication gate is bypassed (Smallstep Advisory, Github Advisory).

As of the time of disclosure, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (Feedly). The EPSS score is approximately 0.011% (1st percentile), indicating a low near-term exploitation probability (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported. However, the attack requires no authentication, no user interaction, and no special privileges, making it trivially exploitable by any attacker with network access to a SCEP provisioner endpoint.

1. Reconnaissance: Identify Step CA instances with SCEP provisioners enabled, accessible over the network. SCEP endpoints are typically exposed at a path such as /scep/<provisioner-name> on the Step CA HTTPS port.
2. Confirm SCEP availability: Send a GetCACert SCEP operation request to the target endpoint to confirm the SCEP provisioner is active and retrieve the CA certificate for use in subsequent steps.
3. Craft a malicious SCEP request: Construct a SCEP PKIOperation request using an unsupported message type — specifically UpdateReq (MessageType=18) — instead of the standard PKCSReq (MessageType=19). Embed a Certificate Signing Request (CSR) for the desired certificate subject in the PKCS#7 envelope, encrypted with the CA's public key.
4. Submit the request: Send the crafted SCEP message to the target's PKIOperation endpoint (e.g., via HTTP GET/POST with operation=PKIOperation&message=<base64-encoded-payload>). Because Step CA skips authorization logic for unsupported message types, the challenge password check is bypassed.
5. Receive the issued certificate: Parse the SCEP response to extract the signed X.509 certificate issued by the CA, which can then be used for impersonation, TLS interception, or authentication against systems trusting the CA (Smallstep Advisory, Patch Commit).

• Network: Unexpected SCEP PKIOperation requests to the Step CA SCEP endpoint containing PKCS#7 messages with MessageType=18 (UpdateReq) or other non-standard SCEP message types; successful certificate issuance responses (HTTP 200 with application/x-pki-message content type) to clients that did not supply a valid challenge password.
• Logs: Step CA access logs showing PKIOperation requests from unknown or untrusted IP addresses resulting in successful certificate issuance; absence of challenge password validation log entries for issued certificates when challenge passwords are configured.
• File System / Certificate Store: Certificates issued by the Step CA with unexpected subject names, SANs, or validity periods that do not match known enrollment requests; certificates issued outside of normal provisioning workflows.
• Process/Application: Step CA log entries indicating processing of SCEP message types other than PKCSReq or RenewalReq in versions prior to v0.30.0 (Smallstep Advisory).

Upgrade Step CA to version v0.30.0 or later, which adds explicit rejection of unsupported SCEP message types (Github Advisory, Smallstep Advisory). If an immediate upgrade is not possible, apply one of the following workarounds:

• Disable or remove SCEP provisioners from the Step CA configuration until the upgrade can be performed.
• Restrict network access to SCEP provisioner endpoints to trusted clients only (e.g., via firewall rules or network segmentation).

For urgent questions, contact security@smallstep.com. Organizations running Step CA in production can also request inclusion on Smallstep's embargo list for advance notification of future security updates at https://u.step.sm/disclosure.

The vulnerability received coverage from security news outlets shortly after disclosure, including The Hacker Wire, which highlighted the critical unauthenticated certificate issuance issue (The Hacker Wire). It was also featured in a weekly cybersecurity vulnerability roundup noting its CVSS 10.0 score (Security Online). Red Hat tracked the issue via Bugzilla and assigned it urgent priority (Red Hat Bugzilla). OpenSUSE also issued a security announcement related to the vulnerability (OpenSUSE). Community reaction was focused on the severity of the authentication bypass in a PKI component, with operators urged to patch immediately.