Security Notice: eMudhra (emSign) CA Distrust
The eMudhra (emSign) CA compromise (CVE-2026-111943), what Luther changed, and the versions to use.
Published 2026-10-22. Tracker: luthersystems/buildenv#163.
Action: upgrade every Luther image, tool and Go library to the version in the tables below, and build your own Go code with Go 1.26.10 or later. The Release Notes list each release.
Summary
| Item | Detail |
|---|---|
| Issue | The private keys of eight intermediate certificate authorities (CAs) of eMudhra (emSign), a public CA, leaked |
| Scope | Industry-wide. It affects every operating system, browser, language runtime and container image that trusts the public CAs. It is not a Luther security incident |
| Identifiers | CVE-2026-111943, GO-2026-6809, golang/go#82345, Mozilla bug 2083449 |
| Risk | A holder of a leaked key can issue a certificate for any host name or any code signer. A client that trusts the chain accepts it |
| Luther fix | Luther images remove or block 25 certificates in every trust store. Luther Go programs are built with Go 1.26.10, which refuses the leaked intermediates |
| Your action | Upgrade to the versions on this page. Set the Helm chart image versions in Helm charts: AWS CLI and Docker |
Industry context
eMudhra is a public CA. Operating systems, browsers and language runtimes trusted its emSign root CAs. When the intermediate keys leaked, the browser and operating system vendors removed the emSign roots (Mozilla NSS 3.131.1 and later) and the Go team added a block list to Go 1.26.10.
Every organization that runs software with its own copy of the public CA list must update that copy. This includes container images, Java runtimes, Python packages and Node.js. The issue is not in Luther code, and no Luther system was breached. Luther changed its images and builds so that they do not depend on the update schedule of each upstream vendor.
What the threat is
A CA certificate lets its key holder sign certificates that clients trust. With a leaked intermediate key, an attacker can issue a valid certificate for any domain. Then the attacker can intercept TLS traffic, for example to an AWS API, a Git host or a package registry. The leaked keys include one code-signing CA (EM OV CS CA), so signed code is also at risk.
Removing the emSign root CAs from a trust store is not sufficient. Sectigo (Comodo) "AAA Certificate Services" cross-signed the same intermediates with the same keys. A system that still trusts AAA Certificate Services accepts the leaked intermediates through that root. Mozilla removed website trust from AAA Certificate Services in April 2025, so Ubuntu 24.04 and Python certifi 2025.4.26 and later no longer hold it. Many bundles still do, for example Debian 12 and 13 (and so the official Debian-based images), Ubuntu 20.04, and JDK cacerts files.
Each runtime also has its own trust store. Java, Python certifi, Node.js and
Chrome (NSS) do not read the operating system bundle by default. A fix that
changes only /etc/ssl/certs leaves those runtimes exposed.
What Luther changed
The fix has two parts, because Go programs and the other runtimes verify certificates in different ways.
| Part | What it does | Where |
|---|---|---|
| Go 1.26.10 | Go's crypto/x509 refuses any chain that holds one of the 8 leaked public keys, whatever CA store the program uses. It checks the key, not the certificate, so it also refuses every cross-signed copy |
Every Luther Go service, tool and library release on this page |
| Image trust stores | Each image removes the emSign roots and AAA Certificate Services from every trust store. It blocks every listed certificate in the OS bundle, Java (blocked.certs), Python certifi, Node.js and Chrome/NSS. The image build fails if any listed certificate still verifies, on amd64 and arm64 |
Every Luther image on this page |
The images block 25 certificates:
| Group | Count | Certificates |
|---|---|---|
| emSign roots | 6 | emSign Root CA - G1, emSign Root CA - C1, emSign ECC Root CA - G3, emSign ECC Root CA - C3, emSign Root TLS CA - G3, emSign Root CS CA - G3 |
| eMudhra intermediates | 18 | EM DV TLS CA, EM OV TLS CA, EM EV TLS CA and EM OV CS CA (G3B and G3C), each in its emSign-issued and its AAA cross-signed copy (16), and the two emSign G3 roots as cross-signed by emSign ECC Root CA - G3 (2) |
| Cross-signing root | 1 | AAA Certificate Services (Sectigo/Comodo) |
The certificate list gives the SHA-256 fingerprint and crt.sh link of each certificate.
Current Sectigo certificates chain to the USERTrust roots. Those roots stay trusted, so blocking AAA Certificate Services does not break current Sectigo sites.
How this compares with the Go fix
The image policy has the same aim as the Go team's fix, and it covers more:
| Go 1.26.10 | Luther images | |
|---|---|---|
| Blocks the 8 leaked intermediate keys | Yes, by public key | Yes, each of the 16 certificates that carry them |
| Removes the 6 emSign roots | No | Yes, as Mozilla NSS 3.131.1 does |
| Removes AAA Certificate Services | No | Yes |
| Applies to | Go programs only | Every trust store in the image: OS bundle, Java, Python, Node.js and Chrome |
Most runtimes cannot block a certificate by its public key, so the images block each certificate that carries a leaked key. They also remove the roots that issued or cross-signed the intermediates, so a certificate the list does not name cannot chain through them.
What to do
- Read the Release Notes for each version you upgrade across. Follow each Upgrade note before you upgrade.
- Upgrade each Luther image to the version in Containers.
- Upgrade each Luther Go library to the version in Go libraries.
- Build your own Go code with Go 1.26.10 or later. A newer library version alone does not give the Go fix, because the Go version that builds the program decides it.
- Set the image versions of the Helm charts. See Helm charts: AWS CLI and Docker.
- Plan to move off the deprecated items, and stop using the retired items. See Deprecated and retired.
- If you build your own images, remove the 25 certificates from each trust store in them.
Containers
Hardened means that the image blocks the 25 certificates and that its Go programs (if any) use Go 1.26.10. Hardened, deprecated means that the image is safe to run, but you should plan to move off it. Deprecated, no change needed means that the image has no CA store, so there is nothing to block. Some source repositories are private; ask us for access.
Core platform
| Image | Used for | Source | Use this version | Status |
|---|---|---|---|---|
luthersystems/substrate |
Substrate chaincode. Runs your phylum on Hyperledger Fabric | substrate | v2.248.0 | Hardened |
luthersystems/shiroclient |
Shiroclient gateway. Sends JSON-RPC requests to Fabric | substrate | v2.248.0 | Hardened |
luthersystems/auth |
Luther Auth, the authentication service | lutherauth | v4.8.3 | Hardened |
luthersystems/oracle |
Example application image of Luther Enterprise (built from the sandbox repository) | sandbox | v0.0.2 | Hardened |
Application services
| Image | Used for | Source | Use this version | Status |
|---|---|---|---|---|
luthersystems/connectorhub |
Connector Hub. Connects your workflows to external systems | connectorhub | v0.0.28 | Hardened. Every connector runs on supergateway 3.4.3-2 |
luthersystems/supergateway-debian, luthersystems/supergateway-npx-git, luthersystems/supergateway-uvx-git |
Part of Connector Hub. Runs MCP connector servers | connectorhub | 3.4.3-2 | Hardened |
luthersystems/pdfserv |
PDF rendering service (headless Chrome) | hyphae | v1.2.0 | Hardened |
luthersystems/service-base-alpine |
Runtime base image of the Luther services | buildenv | v0.1.45 or later | Hardened |
luthersystems/nginx-frontend |
Base image that serves static web front ends | buildenv | v0.1.45 or later | Hardened |
Infrastructure and operations
| Image | Used for | Source | Use this version | Status |
|---|---|---|---|---|
luthersystems/mars |
Infrastructure tool (Terraform, Ansible, Helm charts). Deploys the platform | mars | v0.141.0 (see Helm charts) | Hardened |
luthersystems/awscli |
AWS CLI 2.35.11 in the init containers of the mars Helm charts. See Helm charts | buildenv | v0.1.45 or later | Hardened |
luthersystems/fabric-tools |
Hyperledger Fabric command-line tools | buildenv | v0.1.45 or later | Hardened |
luthersystems/fabric-network-builder |
Generates the crypto material and configuration of a Fabric network | fabric-network-builder | v0.0.10 | Hardened |
luthersystems/fabric-snapshot-archiver |
Sidecar that archives peer ledger snapshots | fabric-snapshot-archiver | v0.0.8 | Hardened |
luthersystems/dind |
Docker daemon (Docker 28.5.2) beside the Fabric peer, for Docker chaincode. Deprecated in favor of external chaincode (chaincode as a service, CCaaS) | buildenv | v0.1.45 or later | Hardened, deprecated |
luthersystems/buildpack |
Builder for Fabric external chaincode. It has no CA store and no TLS client. Deprecated in favor of external chaincode (chaincode as a service, CCaaS) | buildpack | No new version | Deprecated, no change needed |
luthersystems/pushprox |
Prometheus proxy for chaincode metrics (mars Prometheus chart). Deprecated in favor of external chaincode, which Prometheus scrapes directly | pushproxng | v0.1.0 | Hardened, deprecated |
CI/CD and build
| Image | Used for | Source | Use this version | Status |
|---|---|---|---|---|
luthersystems/build-go, luthersystems/build-go-alpine, luthersystems/build-api, luthersystems/build-godynamic |
Go build, test and lint images | buildenv | v0.1.45 or later | Hardened |
luthersystems/build-java |
Java build image | buildenv | v0.1.45 or later | Hardened |
luthersystems/build-js, luthersystems/build-e2e |
Node.js build and browser test images. Node.js uses the hardened system store (NODE_OPTIONS=--use-openssl-ca) |
buildenv | v0.1.45 or later | Hardened |
luthersystems/build-swaggercodegen |
API client code generation | buildenv | v0.1.45 or later | Hardened |
luthersystems/shirotester |
Phylum unit test, lint and debug runner | substrate | v2.248.0 | Hardened |
luthersystems/martin |
End-to-end API test runner | hyphae | v1.2.0 | Hardened |
InsideOut
These images are part of InsideOut, Luther's cloud infrastructure agent. You need them only if you run InsideOut yourself. The InsideOut Go module is in Go libraries.
| Image | Used for | Source | Use this version | Status |
|---|---|---|---|---|
luthersystems/insideout-mcp |
InsideOut MCP server | insideout-mcp | v0.50.4 | Hardened |
Agent builder
No customer runs this image today. It is listed so the list is complete.
| Image | Used for | Source | Use this version | Status |
|---|---|---|---|---|
luthersystems/connector-mcp-discovery |
Connector discovery MCP server of the agent builder | agent-builder | 0.1.1 | Hardened |
Go libraries
Build with Go 1.26.10 or later. Each version below is built and tested with Go 1.26.10.
Platform libraries
| Module | Used for | Use this version |
|---|---|---|
| Go toolchain | Builds your programs. It decides the Go fix | 1.26.10 or later |
| github.com/luthersystems/svc | Service framework for oracles (REST/gRPC gateway, storage, logging) | v0.19.1 |
| github.com/luthersystems/shiroclient-sdk-go | Go client of the shiroclient gateway | v0.18.0 |
| github.com/luthersystems/lutherauth-sdk-go | Go client of Luther Auth | v0.0.10 |
| github.com/luthersystems/elps | ELPS interpreter (the phylum language) | v1.85.0 |
| github.com/luthersystems/libmxf | MXF codec loaders for offline decoders | v0.1.1 (do not use v0.1.0: go get gets a broken decoder file) |
| github.com/luthersystems/hyphae | Source module of pdfserv and martin | v1.2.0 |
| github.com/luthersystems/blockinspector | Command-line tool that inspects Fabric block files (go install) |
v0.1.0 |
InsideOut libraries
| Module | Used for | Use this version |
|---|---|---|
| github.com/luthersystems/insideout-terraform-presets | InsideOut Terraform presets and composer | v0.12.0 |
Helm charts: AWS CLI and Docker
The mars Fabric and shiroclient Helm charts run the AWS CLI in init containers. You may not see these containers in your own manifests, but they connect to AWS over TLS, so their trust store matters. They copy the MSP, TLS and chaincode files from S3 before the main container starts.
| Chart (mars role) | Init containers that run the AWS CLI |
|---|---|
fabric-peer (k8s_fabric_peer) |
chaincode-archive-bootstrap, config-fetch |
fabric-orderer (k8s_fabric_orderer) |
config-fetch |
fabric-ca (k8s_fabric_ca) |
config-fetch |
fabric-cli (k8s_fabric_cli) |
chaincode-archive-bootstrap, config-fetch |
shiroclient (helm_charts) |
config-fetch |
shiroclient-cli (shiroclient_cli) |
config-fetch |
All of these use luthersystems/awscli: the upstream amazon/aws-cli image (AWS
CLI 2.35.11) with the 25 certificates blocked. The AWS CLI bundles its own
Python certifi store, and that store is hardened too.
Upgrade to mars v0.141.0. It is the first mars release whose charts use
the hardened images by default: luthersystems/awscli v0.1.46 in every chart
listed above (the shiroclient chart included), luthersystems/dind v0.1.46,
luthersystems/fabric-tools v0.1.46 in the fabric-cli chart and
luthersystems/fabric-snapshot-archiver v0.0.8. Earlier mars releases
default to images that remove the emSign roots only.
If you must stay on mars v0.140.0 for now, set these values in your Ansible inventory:
# luthersystems/awscli in the Fabric and shiroclient-cli init containers
luther_buildenv_images_version: v0.1.46
# luthersystems/dind beside the peer (Docker chaincode only)
k8s_fabric_peer_dind_version: v0.1.46
# luthersystems/fabric-snapshot-archiver (when the archiver is on)
k8s_fabric_peer_snapshot_archiver_version: v0.0.8
The shiroclient chart in v0.140.0 does not read
luther_buildenv_images_version. Set its own value in the shiroclient Helm
values:
awsCLIVersion: v0.1.46
The fabric-cli chart in v0.140.0 runs the upstream hyperledger/fabric-tools
image and has no setting to change it. Upgrade to v0.141.0 to fix it.
Deprecated and retired
Infrastructure and operations
| Item | Status | What to use |
|---|---|---|
Docker chaincode: luthersystems/dind beside the peer (k8s_fabric_peer_chaincode_docker) |
Hardened, deprecated. The hardened image is v0.1.45 | Chaincode as a service (CCaaS) |
luthersystems/buildpack, the builder for Fabric external chaincode |
Deprecated. It has no CA store and no TLS client, so it needs no change | Chaincode as a service (CCaaS) |
luthersystems/pushprox |
Hardened, deprecated. The hardened image is v0.1.0. It belongs to the same older chaincode setup as buildpack | Plan to move off it |
Connector Hub
| Item | Status | What to use |
|---|---|---|
luthersystems/supergateway-uvx-debian |
Retired. Its only tag is from before the fix | luthersystems/supergateway-uvx-git 3.4.3-2 |
luthersystems/connectorhub-local |
Retired. No longer published | luthersystems/connectorhub v0.0.28 |
CI/CD and build
| Item | Status | What to use |
|---|---|---|
luthersystems/build-python |
Retired. No new tags. One Luther build still uses it until that build moves off | A Python base image of your choice, with the 25 certificates removed |
luthersystems/build-goextra |
Retired (last push 2024) | luthersystems/build-go v0.1.45 or later |
Earlier fix releases
These releases came before the full fix.
| Item | Status | What to use |
|---|---|---|
| buildenv v0.1.41 to v0.1.44 images | Do not use. They remove emSign roots only. They do not block the eMudhra intermediates | v0.1.45 or later |
luthersystems/mars v0.138.0 to v0.139.0 |
Do not use. They remove the emSign roots only | v0.141.0 |
luthersystems/mars v0.140.0 |
Upgrade. The image is hardened, but its Helm chart defaults name older images | v0.141.0 |
| supergateway 3.4.3-1 | Do not use. It removes the emSign roots only | 3.4.3-2 |
luthersystems/connectorhub v0.0.27 |
Upgrade. The image is hardened, but its connector defaults name supergateway 3.4.3-1 | v0.0.28 |
No change needed
| Item | Why |
|---|---|
hyperledger/fabric-peer and hyperledger/fabric-orderer 2.5.5 and later |
They ship no system CA store. Fabric trusts only the CAs in its channel and MSP configuration |
Third-party images that Connector Hub can run (for example supercorp/supergateway, mcp/*, AWS Labs images, node) |
Luther does not build them. Their vendors own their trust stores. Check them with your vendor |
Questions
Email dev@luthersystems.com, or ask in your shared Slack channel with Luther.