CVE-2026-111943: Audit AWS Trust Stores After the eMudhra CA Failure

CLOUD TRUST / PKI RESPONSE

AWS updated security bulletin 2026-150-AWS on October 26 with service-specific remediation for the eMudhra intermediate certificate-authority incident. Cloud teams now need to remove affected trust anchors, rebuild selected runtimes and images, and test identity-provider and origin certificate chains before AWS-managed trust-store changes expose hidden dependencies.

What happened in the eMudhra CA incident

Eight eMudhra intermediate CA private keys, six for TLS and two for code signing, were generated with catastrophically insufficient entropy. CERT-In reports that the P-384 scalar values were smaller than 256 and could be recovered almost instantly from their public keys. This is not a weakness in P-384 itself. It is a key-generation failure that made the private material mathematically recoverable.

A holder of an affected intermediate private key could attempt to sign fraudulent certificates. In a client that still trusts the chain and does not receive effective revocation or distrust data, that creates a path to website impersonation, man-in-the-middle interception, or fraudulent code-signing. Mozilla and Chrome blocked the six TLS intermediates on October 17. eMudhra revoked the eight affected intermediates on October 18, and cross-signed copies were revoked on October 19.

The confirmed evidence is narrower than the theoretical impact. Chrome reported that no TLS certificates chaining to the six intermediates appeared in Certificate Transparency logs before its block, and CERT-In said public disclosures had not established malicious exploitation as of October 21. Defenders should remediate promptly without claiming that every certificate, endpoint, or user was compromised.

The affected trust anchors

AWS identifies three roots relevant to its trust-bundle response. Use the Subject Public Key Information SHA-256 value as the stable identifier. A certificate’s displayed common name is useful for triage but should not be the only matching field.

Browser protection does not automatically cover every cloud runtime. Server-side SDKs, language runtimes, container images, embedded appliances, private trust bundles, and applications that ship their own CA files can follow different update paths. That is why a browser-only validation is insufficient for an infrastructure inventory.

AWS service impact and deadlines

AWS published bulletin 2026-150-AWS on October 24 and updated it on October 26. The bulletin provides concrete version floors and deployment dates:

• botocore: update to version 1.43.117 or later.
• Amazon Linux 2 and 2023: install the current ca-certificates package.
• Bottlerocket: EKS and ECS nodes on AMI versions at or below v1.67.0 remain affected until updated images are applied. AWS also documents an interim per-node distrust override. Coordinate node replacement with the controls in our Kubernetes node migration checklist.
• AWS Lambda: rebuild container-image functions from the latest patched base image. ZIP-based managed runtimes are receiving AWS-managed patches, targeted across all Regions by October 30.
• CloudFront: root removal from the edge CA bundle is targeted for October 28. Origins chaining to an affected root can fail TLS validation after removal.
• Application Load Balancer: if an OIDC or JWT identity-provider endpoint chains to an affected root, replace its certificate chain by October 28. AWS plans ALB trust-store updates from October 29 through October 31.
• Corretto: update to a current build with the affected roots removed.
• STS and Cognito: AWS reports that managed outbound trust-store changes are complete.

RDS for SQL Server and EMR have separate managed timelines. Review the live bulletin and AWS Health rather than assuming the same action applies to every service or Region.

Build a trust-store response plan

1. Map TLS validation boundaries

Inventory every component that validates an external certificate: browsers, operating systems, SDKs, Java runtimes, reverse proxies, load balancers, CDN origins, webhook clients, container images, identity-provider integrations, service meshes, and embedded devices. Record whether each component uses the operating-system store, a language-specific bundle, a Java keystore, or a private CA file.

Do not confuse server identity with client trust. An endpoint may present a safe certificate while the client still carries an affected root. Conversely, removing a root can break a legitimate dependency if an origin or identity provider still presents a chain beneath it.

2. Inspect live chains from the relevant network path

Use a controlled administration host that follows the same proxy and egress path as the workload. Replace the example hostname with an authorized endpoint:

openssl s_client -connect idp.example.net:443 
  -servername idp.example.net -showcerts </dev/null 2>/dev/null 
  | openssl crl2pkcs7 -nocrl -certfile /dev/stdin 
  | openssl pkcs7 -print_certs -noout

Capture the complete chain, issuer names, validity dates, and validation result. Where you have a certificate file, calculate its SPKI fingerprint with:

openssl x509 -in certificate.pem -pubkey -noout 
  | openssl pkey -pubin -outform der 
  | openssl dgst -sha256

This command is for defensive certificate inventory. It does not test exploitation. Compare the hexadecimal result with vendor-published SPKI values and retain the evidence with the asset record.

3. Patch, rebuild, and restart

Update Amazon Linux hosts through the approved package-management workflow, then confirm the deployed CA bundle changed. Rebuild immutable images rather than patching only a running container. For Lambda container images, pull the patched base, rebuild without stale cache, scan it, preserve the new digest, and redeploy. For Bottlerocket, follow the AWS bulletin and your EKS or ECS node replacement process.

# Amazon Linux 2 or Amazon Linux 2023
sudo yum update ca-certificates

# Python SDK inventory
python3 -c 'import botocore; print(botocore.__version__)'
python3 -m pip install --upgrade 'botocore>=1.43.117'

Use a virtual environment or managed dependency file for Python applications. A global pip change can violate operating-system packaging policy or alter unrelated applications. The broader control pattern aligns with our AWS Security Hub evidence guide: record asset, owner, prior version, target state, deployment evidence, and validation result.

Hands-on lab: triage a synthetic AWS inventory

This offline lab converts the AWS bulletin into a repeatable first-pass queue. It uses synthetic data, makes no cloud API calls, and does not determine whether a system was attacked. The name-based certificate check is deliberately conservative; production validation must also compare the SPKI fingerprint.

Prerequisites

• Python 3.9 or later
• An empty directory on an isolated test workstation
• No AWS credentials, network access, or elevated privileges

Create inventory.csv:

asset,asset_type,version,certificate_chain_root
deployment-a,botocore,1.43.116,
deployment-b,botocore,1.43.117,
eks-node-a,bottlerocket,v1.67.0,
api-host-01,amazon_linux,2023,
image-worker,lambda_container,python3.13,
login-alb,alb_oidc,,emSign Root TLS CA - G3
cdn-origin,cloudfront_origin,,Amazon Root CA 1

Save the following as trust_store_triage.py:

import csv, re, sys

affected = {
    "AAA Certificate Services",
    "emSign Root TLS CA - G3",
    "emSign ECC Root CA - G3",
}

def version(value):
    parts = tuple(int(x) for x in re.findall(r"d+", value))
    return parts + (0,) * (4 - len(parts))

def classify(row):
    kind = row["asset_type"].strip().lower()
    current = row["version"].strip()
    root = row["certificate_chain_root"].strip()
    if kind == "botocore":
        return "CURRENT" if version(current) >= (1, 43, 117, 0) else "UPDATE_BOTOCORE"
    if kind == "bottlerocket":
        return "UPDATE_AMI" if version(current) <= (1, 67, 0, 0) else "VERIFY_AMI"
    if kind == "amazon_linux":
        return "UPDATE_CA_CERTIFICATES"
    if kind == "lambda_container":
        return "REBUILD_FROM_LATEST_IMAGE"
    if kind in {"alb_oidc", "cloudfront_origin"} and root in affected:
        return "REPLACE_CERTIFICATE_CHAIN"
    return "VERIFY_VENDOR_STATUS"

with open(sys.argv[1], newline="", encoding="utf-8") as handle:
    print("asset,asset_type,action")
    for row in csv.DictReader(handle):
        print(f'{row["asset"]},{row["asset_type"]},{classify(row)}')

Run the lab:

python3 trust_store_triage.py inventory.csv

Expected output:

asset,asset_type,action
deployment-a,botocore,UPDATE_BOTOCORE
deployment-b,botocore,CURRENT
eks-node-a,bottlerocket,UPDATE_AMI
api-host-01,amazon_linux,UPDATE_CA_CERTIFICATES
image-worker,lambda_container,REBUILD_FROM_LATEST_IMAGE
login-alb,alb_oidc,REPLACE_CERTIFICATE_CHAIN
cdn-origin,cloudfront_origin,VERIFY_VENDOR_STATUS

If the script reports a missing column, confirm the CSV header matches the example. If a vendor version contains an unexpected format, classify it manually against the current advisory. Cleanup is:

rm -f inventory.csv trust_store_triage.py

Validate remediation without causing an outage

• Test OIDC, JWT, webhook, origin, and API connections from canary workloads after trust-store changes.
• Confirm revoked or distrusted chains fail while approved certificate chains still validate.
• Monitor ALB authentication errors, CloudFront origin TLS failures, Lambda initialization errors, SDK exceptions, and application handshake telemetry.
• Verify autoscaling templates, launch images, CI runners, disaster-recovery environments, and dormant containers.
• Keep certificate-chain evidence and package or image digests with the change record.
• Escalate unexplained certificate issuance, hostname mismatch, or unexpected chain changes to incident response.

Local development roots are a separate control plane. Our mkcert guide for Debian explains how local trust is installed, which also illustrates why private and public trust stores must be inventoried independently.

Conclusion

CVE-2026-111943 is not only a browser-update problem. It is a cloud dependency and trust-distribution problem. The safest response is to map every validation boundary, update the responsible trust store or runtime, replace affected certificate chains before vendor deadlines, rebuild immutable artifacts, and test both rejection and availability from the real workload path. Keep claims proportional to evidence: the keys were recoverable and required emergency distrust, but current public sources do not establish broad malicious exploitation.

Primary sources

• AWS Security Bulletin 2026-150-AWS, published October 24 and updated October 26, 2026
• CERT-In: Compromise of eMudhra Intermediate CA Certificates, issued October 21, 2026
• Mozilla root-program incident notice, October 20, 2026
• Mozilla Bug 2083449 incident record