Security Advisory: Distrust of eMudhra Root and Intermediate Certificate Authorities

Advisory ID: Druva/DVSA-2026-001

Issue date: November 4, 2026

Advisory status: Interim

Version: 1.0

Overall severity: Medium

This advisory explains the eMudhra certificate authority issue, how Druva is responding, and the steps you can take to protect your systems, if any are needed.

The Druva Security and Engineering teams have reviewed a recently disclosed security issue involving eMudhra, a certificate authority (CA) that issues the digital certificates browsers and operating systems use to verify websites and software. On October 17, 2026, a security researcher reported that eight intermediate CA certificates operated by eMudhra had private keys (P-384) that could be recovered, and according to public reports, researchers demonstrated control of those keys. Six were used to issue website (TLS) certificates and two were used to sign software. Anyone with these keys could create certificates that many systems would trust, allowing them to pose as a legitimate website or service. These certificates were widely trusted because they link back to eMudhra’s emSign ECC Root CA - G3 and were also cross-signed by Sectigo’s AAA Certificate Services root.

eMudhra has stated that it revoked the eight certificates. According to their published statements, Google, Mozilla, Apple, Microsoft, and the major Linux distributions have blocked them and are removing the related root certificates from their trust stores. According to eMudhra, none of the affected intermediates issued certificates, and eMudhra was not aware of any exploitation before the issue was disclosed.

Druva does not use, issue, or present certificates from any of the affected eMudhra authorities, so Druva’s own certificates are not affected. As of the date of this advisory, Druva is not aware of any malicious use of this issue affecting Druva customers.

This issue concerns inbound trust: which certificate authorities Druva Endpoints and Druva Enterprise Workloads components accept when they connect to Druva Cloud. It does not involve any certificate that Druva issues. However, certain customer-deployed components that trust the affected certificate authorities are in scope, as described below. Some of these components run on hosts and appliances in your environment and partly rely on the operating system’s list of trusted certificates. The guidance below applies to those components.

If you don’t run Druva Endpoints or Druva Enterprise Workloads components in your own environment, you don’t need to take any action. Druva manages the trust configuration of its cloud services directly.

If you do run any of the components listed below on hosts or appliances in your environment, actions required depend on the component.

Updated releases for these components are in progress, and this advisory will be updated as they become available.

The tables below show which components are not affected, which appliances the workaround applies to, and which components will receive an updated release.

The Druva software in these components is not affected, so no upgrade is needed. As a best practice, we still recommend applying your operating system vendor’s ca-certificates update. This is intended to remove the affected certificate authorities from the host itself and may help protect any other connections on that host that rely on the operating system’s list of trusted certificates.

Additionally, we recommend keeping Druva components, agents, and proxies updated to the latest supported versions as part of regular maintenance and security hygiene.

Older eDiscovery Download Client versions

Versions older than v2.3.0 are affected by this issue. These versions were deprecated in September 2026, are no longer supported, and won’t receive an updated release. Customers on an older version should upgrade to eDiscovery Client v2.4.0 or later as soon as possible.

Druva is preparing updated versions of these components. Target timing is shown below (target dates are estimates, not commitments, and may change), and fixed version numbers will be added as each release becomes available.

For the AWS Proxy and the VMware backup proxy appliances, apply the appliance workaround now, then install the updated release when it's available. Together, the two address the issue.

The Enterprise Workloads software on the appliances below is not affected.

The affected certificate authorities are only in the appliance’s operating system certificate list, and the workaround removes them.

For most appliances, applying the workaround addresses the issue, and no further action is needed. The AWS Proxy also needs an updated release, listed above.

In December 2026, Druva will publish refreshed appliance images that include the updated certificates. These are for new deployments only. You don’t need to redeploy appliances you’ve already updated with the workaround.

To apply the workaround, run the following on each appliance, then restart the Druva services:

Druva recommends applying the updates as they become available.

For more background on the issue and how platform vendors have responded:

If you have questions or would like help with any of these steps, contact Druva Support through your existing channels. We're here to help.

This advisory is provided "as is" based on the information currently available without warranty of any kind, express or implied, and does not create any obligation or modify the terms of any agreement between Druva and its customers. Customers remain responsible for evaluating and testing any recommended actions in their own environments. Druva may update it as more information becomes available.