Compromised eMudhra emSign intermediate CAs trusted by sbomify and sbomify Action (GHSA-6q48-6c7w-9gw2)

Summary

eMudhra's emSign intermediate CAs were compromised, and their private keys were trivially weak. Anyone holding those keys can issue certificates that chain to the emSign roots. Any client that still trusts those roots can then be intercepted (MITM) over TLS.

sbomify and sbomify Action trusted the affected emSign roots in these places:

• certifi in sbomify: the app's Python CA bundle. requests, httpx and sentry-sdk use it for all outbound TLS, including vulnerability scanners, webhooks and challenge checks.
• certifi in sbomify Action: the CA bundle the action trusts for its uploads to sbomify and its package-registry lookups.
• pip's vendored certifi: pip before 26.2.2 always trusts it, even alongside the system store. The sbomify image build ran pip install uv with it.
• The sbomify production image's OS CA bundle: Python ssl defaults, cosign and osv-scanner read it. It still trusted emSign Root CA C1 and ECC C3.
• sigstore before 4.5.1, used by sbomify.
• pypa/gh-action-pypi-publish before v1.14.3, used to publish sbomify Action to PyPI.
• The JDK in sbomify Action's jvm tool bundle: Temurin's cacerts trusted emSign Root CA - G1 and emSign ECC Root CA - G3. sbomify Action downloads this bundle from sbomify/sbom-tools at run time to generate SBOMs for Maven, Gradle and sbt projects, and that JDK makes the build tools' HTTPS connections to Maven Central and the Gradle plugin portal.
• Identifier: GHSA-6q48-6c7w-9gw2 (certifi bundles emSign root CAs with compromised intermediate CA keys; upstream severity Critical, published 2026-10-20)
• References:
  • https://github.com/advisories/GHSA-6q48-6c7w-9gw2
  • https://discuss.python.org/t/information-for-python-users-regarding-emudhra-emsign-ca-certificate-security-incident/109576

Affected

• sbomify: all releases up to and including v26.9.0 (certifi 2025.10.5 in v26.9.0). v26.10.0 is the first fixed release. The hosted service at app.sbomify.com is fixed.
• sbomify Action: all releases up to and including v26.9.0 (certifi 2026.6.17 in v26.9.0). v26.10.0 ships certifi 2026.10.19 and is not affected at runtime. v26.10.1 is the first release that also ships the patched PyPI publish step.
• sbomify Action, JVM projects (added 2026-10-26): every release from v26.8.0 to v26.10.2 fetched a jvm tool bundle whose JDK still trusted emSign Root CA - G1 and ECC G3. This was corrected on 2026-10-26, when the bundle was rebuilt. It applies only to SBOMs generated for Maven, Gradle or sbt projects. The bundle is downloaded at run time, so upgrading the Action does not change it; see Remediation.

Impact

An attacker on the network path between sbomify or sbomify Action and an upstream service could present a certificate issued under a compromised emSign intermediate. The attacker would also need to hold one of the compromised keys. With both, they could read or alter that outbound connection. Examples are a vulnerability feed, a webhook delivery, an SBOM upload from the action, or a package download during the image build. We have found no evidence that this happened. Inbound connections to app.sbomify.com are not affected, because they use sbomify's own certificates.

Remediation

All fixes are merged. The minimum fixed versions follow Python's guidance: certifi 2026.10.19, pip 26.2.2, sigstore 4.5.1 and gh-action-pypi-publish v1.14.3.

• https://github.com/sbomify/sbomify/pull/1869: certifi 2025.10.5 → 2026.10.19 in the app. Released in sbomify v26.10.0.
• https://github.com/sbomify/sbomify/pull/1887: Python 3.14.9 / pip 26.2.2 base image and sigstore 4.5.1. The production image's OS CA bundle now tracks upstream Wolfi ca-certificates-bundle, which follows Mozilla's root store: emSign ECC Root CA - G3 is removed, and emSign Root CA - G1 is the only emSign root left. certifi 2026.10.19 follows the same store and still includes G1, C1 and ECC C3. OpenJDK's guidance for the JDK (JDK-8395690) goes further and also distrusts G1, which is why the JDK in sbomify Action's jvm tool bundle drops it. We follow each ecosystem's own root-store decision, and will update sbomify if Mozilla removes G1. Released in sbomify v26.10.0.
• https://github.com/sbomify/sbomify-action/pull/457: certifi 2026.6.17 → 2026.10.19 in the action. Released in v26.10.0.
• https://github.com/sbomify/sbomify-action/pull/466: gh-action-pypi-publish v1.14.3 for the PyPI publish step. Released in v26.10.1.
• https://github.com/sbomify/sbom-tools/pull/51: the jvm tool bundle moves to Temurin 21.0.13+9. At assembly it removes emSign Root CA - G1 and ECC G3 from the JDK's cacerts, following OpenJDK's guidance for CVE-2026-114820 / JDK-8395690, and the build fails if either is still present. The tools-rolling bundle that sbomify Action downloads was rebuilt from it on 2026-10-26. Its cacerts has no emSign roots (verified with keytool).

Users: upgrade sbomify Action to v26.10.1 or later (v26.10.0 is the minimum for the runtime fix). For JVM projects no upgrade is needed: every release fetches the rebuilt bundle. However, the action reuses a bundle it has already downloaded. If your runner keeps the sbomify tool cache between jobs (a self-hosted runner, or a persisted SBOMIFY_TOOL_CACHE, XDG_CACHE_HOME or HOME), delete the bundle-jvm-tools-rolling-* directory under sbomify/runtimes (or under SBOMIFY_TOOL_CACHE) so the next run downloads the fixed bundle. GitHub-hosted runners start clean and need no action. The ghcr.io/sbomify/sbomify-action:latest image already points at v26.10.1. Self-hosted sbomify users should upgrade to sbomify v26.10.0 (https://github.com/sbomify/sbomify/releases/tag/v26.10.0) or later.