Executive Summary
A maximum-severity vulnerability (CVE-2026-30836) has been disclosed in Step CA (also known as step-ca or smallstep/certificates), a widely deployed open-source certificate authority used in DevOps, Kubernetes, and zero-trust networking environments. The flaw carries a CVSS score of 10.0 — the highest possible rating.
The vulnerability exists in the SCEP (Simple Certificate Enrollment Protocol) implementation: specifically the UpdateReq endpoint fails to enforce authentication before issuing certificates. An unauthenticated attacker who can reach the SCEP endpoint can obtain valid TLS/mTLS certificates signed by the trusted CA — completely bypassing all intended enrollment controls.
All Step CA versions 0.30.0-rc6 and earlier are affected. The issue has been resolved in version 0.30.0. Organizations running Step CA in any capacity should treat this as an emergency patch.
Vulnerability Overview
| Attribute | Value |
|---|---|
| CVE ID | CVE-2026-30836 |
| CVSS Score | 10.0 (Critical) |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H |
| CWE | CWE-306 — Missing Authentication for Critical Function |
| Type | Unauthenticated Certificate Issuance |
| Attack Vector | Network |
| Attack Complexity | Low |
| Privileges Required | None |
| User Interaction | None |
| Patch Available | Yes — Step CA 0.30.0 |
| NVD Published | 2026-03-19 |
Affected Versions
| Product | Affected Versions | Fixed Version |
|---|---|---|
| smallstep/certificates (Step CA) | ≤ 0.30.0-rc6 | 0.30.0 |
Technical Analysis
What Is Step CA?
Step CA is a production-grade online certificate authority developed by Smallstep. It is commonly deployed to:
- Automate TLS certificate issuance and renewal for microservices
- Power mTLS authentication in Kubernetes and service mesh environments
- Implement zero-trust networking (device and workload identity)
- Serve as the backend for ACME, SCEP, JWK, and OIDC certificate provisioners
Because Step CA acts as a trusted root or intermediate CA, certificates it issues are inherently trusted across the entire deployment — making this vulnerability especially dangerous.
The SCEP Protocol and UpdateReq
SCEP (RFC 8894) is a protocol originally designed for enrolling network devices (routers, switches, IoT) in a PKI. It supports several operations including PKCSReq (initial enrollment) and UpdateReq (certificate renewal/update without a new enrollment challenge).
The UpdateReq operation is designed to allow an already-enrolled device to renew its certificate by authenticating with its existing valid certificate (rather than a challenge password). Step CA's implementation of UpdateReq failed to verify that the signing certificate presented in the renewal request was:
- Previously issued by this CA
- Not expired or revoked
- Authorized to renew
Without these checks, any client can construct a valid-looking UpdateReq SCEP message and obtain a freshly signed certificate from the CA.
Attack Flow
1. Attacker identifies a Step CA instance with SCEP provisioner enabled
2. Attacker crafts a SCEP UpdateReq message using any self-signed or arbitrary certificate
3. Request is submitted to the SCEP endpoint (unauthenticated network access only required)
4. Step CA's UpdateReq handler issues a new certificate signed by the CA's private key
5. Attacker receives a valid CA-signed certificate for any Subject/SAN they specified
6. Certificate can be used to:
- Impersonate any service in mTLS environments
- Perform MITM attacks on TLS-protected internal services
- Gain unauthorized access to services that use certificate-based auth
- Enumerate and pivot within zero-trust architecturesWhy CVSS 10.0
The maximum score reflects the scope and severity of impact:
| Metric | Value | Reason |
|---|---|---|
| No authentication | PR:N | Exploitable by any network-connected attacker |
| No user interaction | UI:N | Fully automated exploitation |
| Low complexity | AC:L | SCEP is a well-documented protocol; tooling exists |
| Changed scope | S:C | CA compromise affects all relying parties system-wide |
| Full C/I/A | H/H/H | Arbitrary certificate issuance undermines entire PKI trust model |
Impact Assessment
| Impact Area | Description |
|---|---|
| Identity Forgery | Attacker can obtain certificates impersonating any service or user in the PKI |
| mTLS Bypass | Service-to-service authentication using mutual TLS is completely undermined |
| MITM Attacks | Valid CA-signed certs enable transparent interception of encrypted traffic |
| Lateral Movement | Certificate-authenticated services become accessible to the attacker |
| Zero-Trust Collapse | Environments relying on Step CA for device/workload identity lose all trust guarantees |
| Long-Term Persistence | Certificates can be issued with extended validity for persistent access |
| Kubernetes Impact | Clusters using Step CA for kubelet/kube-apiserver TLS are severely exposed |
Who Uses Step CA
Step CA is widely deployed across:
- Kubernetes clusters (cert-manager integration, kubelet certificates)
- HashiCorp Vault environments (as a PKI backend alternative)
- Home labs and enterprise zero-trust deployments
- IoT device management (via SCEP provisioner specifically)
- Internal developer platforms requiring automated certificate lifecycle management
Any deployment with a SCEP provisioner configured is directly exploitable.
Immediate Remediation
Step 1: Upgrade to Step CA 0.30.0
# Check current version
step-ca version
# Using Homebrew (macOS/Linux)
brew upgrade step
# Using the Smallstep install script
curl -sSf https://dl.smallstep.com/install.sh | sh
# Verify the upgrade
step-ca version
# Expected: Smallstep CA/0.30.0 ...For container/Kubernetes deployments:
# Update the step-ca container image tag
# docker.io/smallstep/step-ca:0.30.0
# Kubernetes — update the image in your deployment
kubectl set image deployment/step-ca \
step-ca=smallstep/step-ca:0.30.0 \
-n <namespace>
# Verify rollout
kubectl rollout status deployment/step-ca -n <namespace>Step 2: Temporary Mitigation — Disable SCEP If Not Required
If SCEP is not needed, disable the SCEP provisioner entirely until the upgrade is complete:
# List current provisioners
step ca provisioner list
# Remove the SCEP provisioner (replace <name> with your SCEP provisioner name)
step ca provisioner remove <name> --type scep
# Restart step-ca to apply changes
systemctl restart step-ca # or however your instance is managedStep 3: Audit for Unauthorized Certificate Issuance
After patching, audit your CA's certificate log for unexpected issuances:
# If using step-ca with a database backend, query issued certificates
# Check your CA's audit log for SCEP UpdateReq operations pre-patch
# List all issued (and still-valid) certificates
step ca certificate-list --not-after="+0s"
# Review certificates issued during the vulnerability window
# Look for unexpected subjects, SANs, or requestor identifiersStep 4: Revoke Any Suspicious Certificates
# Revoke a specific certificate by serial number
step ca revoke <serial-number>
# Or by certificate file
step ca revoke --cert suspicious-cert.pemDetection Indicators
| Indicator | Description |
|---|---|
| SCEP UpdateReq requests from unexpected source IPs | Unauthorized enrollment attempts |
| Certificates with unexpected Subject/SAN values in the CA log | Evidence of unauthorized issuance |
| mTLS authentication successes from unrecognized workloads | Certificate-based lateral movement |
| Spike in SCEP endpoint traffic | Automated exploitation or scanning |
| New certificates with unusually long validity periods | Attacker-issued persistence certificates |
Post-Remediation Checklist
- Upgrade Step CA to version 0.30.0 or later on all instances
- Revoke any certificates that may have been fraudulently issued during the vulnerability window
- Audit the CA certificate log for anomalous issuances (unexpected subjects, SANs, issuance times)
- Rotate the CA's signing key if unauthorized issuance is confirmed or strongly suspected
- Review all SCEP provisioner configurations — disable SCEP if not required
- Segment CA endpoints behind network access controls (firewall, VPN, internal-only routing)
- Enable certificate transparency or audit logging if not already configured
- Alert on SCEP UpdateReq events from non-enrolled or unexpected sources going forward
- Notify downstream relying parties if CA rotation is performed