Python and CI/CD Users Urged to Update After emSign CA Incident

Oct 22, 2026 · Original article ↗

Summary

Google confirmed that eight emSign intermediate CA certificates had keys generated with insufficient randomness. The article gives Python and CI/CD users update and verification steps; exploitation against non-browser clients remains unknown.

Key points

Google confirmed that eight intermediate CA certificates had private keys generated with insufficient randomness. Forged certificates could be used against clients accepting an affected chain if an attacker also intercepts or redirects the connection.
Recommended update targets include certifi 2026.10.19 or later, pip 26.2.2 or later, uv 0.13.4 or later, and updated CA packages for conda and Pixi.
Updating standalone certifi does not replace pip’s vendored certifi. The article advises checking each tool’s actual trust store, distributor backports, and custom certificate configuration.
In tests of 14 published certificate chains, certifi 2026.07.22 accepted 7, while certifi 2026.10.19 and the bundle in pip 26.2.2 rejected all 14. These local tests are not evidence of exploitation.
Audit developer environments, CI runners, containers, build and runtime stages, and cached environments; rebuild images and replace deployed containers after updating.
Verify affected chains with the actual client and trust configuration, keep TLS verification enabled, and use independently trusted dependency hashes where available.
The disclosure authors say it remains unknown whether attackers exploited the weakness against non-browser clients; an outdated trust store alone does not establish compromise.

Article Details

Defense Focus: Remove trust in the affected emSign certificate chains from every Python package-management environment and verify that the actual client trust configuration rejects them. The article notes that an affected trust store alone does not establish compromise.
Detection Methods: Test the affected and cross-signed certificate chains using the actual client and trust configuration used by each workload; confirm that verification fails.
Inventory Python interpreters, virtual environments, CI runner images, containers, and separate tool installations to find outdated package managers or trust bundles.
Inspect explicit trust-store settings, including PIP_CERT, REQUESTS_CA_BUNDLE, SSL_CERT_FILE, SSL_CERT_DIR, and uv's system-certificate setting.
Monitor outbound connections during dependency installation and builds, correlating activity with CI workflow steps; investigate unexpected connections, suspicious artifacts, process execution, or credential use.
Data Sources: Python interpreter and package-manager version output
Certificate bundles and explicit trust-store configuration
Affected-chain verification results from the workload's actual client
CI outbound-connection activity correlated with workflow steps
Dependency artifacts, process execution, and credential-use activity
Defensive Actions: Update certifi to 2026.10.19 or later and update pip, uv, sigstore Python client, conda, and Pixi to the article's recommended versions or later; account for distributor backports.
Update pip's vendored certifi separately from any project-installed certifi, and check the pip wheel bundled with ensurepip in interpreters that create new environments.
Review custom and system trust stores, and verify affected chains are rejected by the trust source actually selected by each application.
Rebuild CI images and containers, refresh cached environments, and check build and runtime stages for old version pins or pinned base-image digests.
Keep TLS verification enabled. If an internal package index is affected, replace its certificate chain rather than bypassing verification.
Use reviewed, version-pinned requirements with independently trusted SHA-256 hashes and enforce them with pip's --require-hashes option.
Use outbound-connection monitoring and destination-restricting network policies as complementary controls, not substitutes for corrected certificate trust.