Security Bulletin: response to eMudhra CA intermediate certificate compromise

Published: October 23, 2026

Applies To: Capacity Private Cloud version 8.0.x (On-Premise & Private Cloud Deployments). Customers running version 7.x or earlier should contact Support to discuss their upgrade path.

Action Required: Yes. Update to the patched images listed below.

Overview

On October 20, 2026, Mozilla and the Chrome Root Program confirmed that the private keys for eight intermediate certificate authority (CA) certificates operated by eMudhra (emSign) are compromised. The keys were generated with insufficient randomness and can be derived from the public certificates. An attacker holding them could issue certificates for any domain that would be trusted by software still relying on the affected certificate chains.

Six of the affected certificates are used for TLS (website) authentication and two for code signing. Major browsers and operating system vendors have blocked them. However, many non-browser applications, language runtimes, and container base images do not receive these blocks automatically and are protected only when the software itself is updated.

Platform Impact Assessment

• Certificate trust exposure: Prior versions of our container images relied on Go runtime releases and base image CA bundles that did not yet reject the affected certificates. In an unpatched deployment, a service could accept a forged certificate when connecting to an external endpoint, but only if an attacker were also positioned to intercept that network traffic.
• Exploitation prerequisites: This cannot be exploited remotely against a service on its own. It requires interception of network traffic between a service and the endpoint it connects to.
• Encryption is not weakened: This issue concerns certificate-based authentication, not the strength of TLS encryption algorithms.
• No evidence of impact: We have no evidence or indication that any customer systems or data were impacted.

Our Security Response

We reviewed all Capacity images in our deployed Helm charts. Images not listed below were not affected, were not republished, and require no action. For the affected images, we released patched versions outside our normal release schedule. The patches include:

• An update to Go 1.27.3, which rejects the compromised intermediate certificates and includes related fixes
• Updated base images carrying corrected CA certificate bundles
• Additional dependency (npm) updates addressing other vulnerabilities

We also verified the certificate chains presented by the external endpoints our software contacts for licensing and model distribution. None involve eMudhra/emSign certificates, and we do not use certificates issued by eMudhra/emSign.

Version 8.0.1

Version 8.0.2

These images are also tagged 8.0, 8, and latest. Your Helm deployment references the 8.0 tag.

Recommended Customer Actions

1. Update your Helm (Kubernetes) deployment.

Important: Capacity deployments use the floating :8.0 image tag with imagePullPolicy: IfNotPresent. In that configuration, helm upgrade and pod restarts do not download the patched images, because nodes keep using the images they already have. You must take one of the explicit actions below.

If you previously pinned global.image.tag to a specific version such as ":8.0.0", set it back to ":8.0" (note the leading colon). Do not set the tag to :8.0.1 or :8.0.2. Not every image has those tags, and some pods would fail with ImagePullBackOff.

Method A: Pre-pull on your nodes, then restart (keeps IfNotPresent).

This requires command-line access to your cluster nodes, which is typical for self-managed clusters but usually not available on managed Kubernetes services (for example EKS, AKS, or GKE). If you run a managed service, use Method B.

a. On every node that can run these pods, pull the images your deployment uses. If you use a private registry mirror, update the mirror first and use its path. Skip tts and neural-tts if you don’t run them, as these images are large.

for i in license resource grammar storage deployment reporting-api configuration \
         archive management-api file-store admin-portal tts neural-tts session deployment-portal; do
  sudo crictl pull docker.io/lumenvox/$i:8.0
done

(crictl applies to containerd. For a Docker runtime, use docker pull.) Pull on all eligible nodes, not only those currently running the pods, or a later reschedule can land on a node still holding the old image.

b. Restart the patched services:

kubectl get deploy -n lumenvox
kubectl rollout restart deployment/<name> -n lumenvox

Restart only Capacity workloads. If you run the in-cluster external-services test dependencies, do not restart those.

Method B: Set the pull policy to Always - Recommended for managed Kubernetes services.

In your values.yaml:

global:
  image:
    pullPolicy: Always

Then follow the standard upgrade procedure. All Capacity workloads will restart as in a normal upgrade, and pull the current images. Nodes will need to reach the registry when pods start. If you later revert to IfNotPresent, re-verify your digests, as a node holding an old cached image could run it.

2. Update MRCP (Docker Compose) deployments.

MRCP runs from the Docker Compose file in the mrcp-api repository, not Helm. To avoid disrupting traffic, take the instance out of service first using the management API (see the README), and wait for active calls on that instance to complete:

curl -X PUT -d '{"out-of-service":"1"}' -u <user>:<password> https://localhost:8085/out-of-service

(Add --insecure if you use the auto-generated certificate.) Then update:

cd mrcp-api/docker
docker compose pull
docker compose up -d

Alternatively, set PRODUCT_VERSION=8.0.1 in docker/.env (no leading colon) and run docker compose up -d. The out-of-service setting resets when the service restarts, so you do not need to clear it.

3. Verify the update. Confirm each running container uses a patched image by comparing digests to the tables above.

Kubernetes:

kubectl get pods -n lumenvox -o jsonpath='{range .items[*]}{range .status.containerStatuses[*]}{.image}{"\t"}{.imageID}{"\n"}{end}{end}' | sort -u

MRCP:

docker images --digests lumenvox/mrcp-api

4. Review your own environment. This issue affects any software that validates TLS certificates, not only our products:

• Update CA bundles and operating system packages on hosts and in any custom images you maintain.
• Review any custom trust stores or mutual TLS configurations, including extra root CAs supplied via global.extraRootCaCerts (Helm) or MEDIA_SERVER__EXTRA_ROOT_CA (MRCP). Remove any eMudhra/emSign roots.
• If services your deployment connects to present certificates issued by eMudhra/emSign, those connections will fail validation after updating. The affected intermediates have been revoked. Contact the owner of those services or your certificate provider to have the certificates reissued.
• If you use emSign code-signing certificates, review those as well.

5. Do not disable certificate verification to resolve certificate errors you encounter after updating. This removes the protection the updates restore. Contact Support instead.

6. Do not roll back to earlier image versions, as this would reinstate the vulnerable components.

Additional Information

• Cloudflare: https://blog.cloudflare.com/emudhra-certificate-compromise
• The Hacker News: https://thehackernews.com/2026/10/eight-emudhra-ca-keys-compromised.html
• Test site and package status (maintained by Mozilla’s Dennis Jackson): https://emudhra.we-have-a-problem.com/

Support

If you have questions about your specific deployment, or need help updating your installation, please reach out to your Account Manager or Support representative.