SFTP Gateway Support

3.0

eMudhra certificate authority compromise: impact on SFTP Gateway

TLDR - Quick Summary

What: On October 17, 2026, eight TLS intermediate certificates issued by the certificate authority eMudhra were found to have recoverable private keys. Browsers already block them; operating system and Java trust stores are being updated by the vendors.

Affected: Only the application's outbound HTTPS connections (cloud storage, single sign-on, Microsoft Graph, SMTP over TLS, our license service) until the server's trust store is updated. SFTP/SCP, your server's own certificate, and admin UI logins are not affected.

Action: Update the OS ca-certificates package (Ubuntu fix available now; Amazon Linux and container fixes pending from Amazon) and restart the application. No product upgrade is required. No exploitation has been reported.

Last updated: 2026-10-21. We will update this article as vendor fixes ship.

Summary

On October 17, 2026, researchers showed that eight TLS intermediate certificates issued by the certificate authority eMudhra were created with private keys that anyone can recover. An attacker holding those keys can forge a valid-looking HTTPS certificate for any hostname. Browser vendors blocked the certificates within days. Operating system and Java trust stores are being updated separately, and that is where SFTP Gateway is affected.

No action is required to keep your server running. No exploitation of this issue has been reported. The steps below remove the remaining exposure.

What is and is not affected

Not affected

  • SFTP and SCP connections to your server. SSH does not use web certificate authorities.

  • The certificate your server presents on its admin web UI. Nothing changes unless that certificate was purchased from eMudhra, which browsers now reject. If so, obtain a replacement from another CA.

  • Logins to the admin UI from a browser. Browsers already block the compromised certificates.

Affected until the trust store is updated

  • Outbound HTTPS connections made by the application itself: to cloud storage (Amazon S3, Azure Storage, Google Cloud Storage), to your identity provider for single sign-on, to Microsoft Graph, to SMTP over TLS, and to our license service. Until the trust store on the server is updated, the Java runtime would accept a forged certificate on those connections.

Exploiting this requires an attacker who can also redirect your server's network traffic to a machine they control, for example through DNS or routing compromise. For servers in a cloud VPC that is a high bar. Servers on networks with an inspection proxy or weaker DNS should apply the fix promptly.

What to do, by deployment type

Find your deployment type, apply the update, then restart the application so the Java runtime reloads its trust store.

Ubuntu images (Azure, Google Cloud, Alibaba Cloud)

Canonical has released the fix. Run:

sudo apt-get update
sudo apt-get install --only-upgrade ca-certificates

Then restart the application:

sudo systemctl restart sftpgw-admin-api

The fixed package version is 20260816ubuntu0.24.04.1 on Ubuntu 24.04 and 20260816ubuntu0.22.04.1 on Ubuntu 22.04.

Amazon Linux 2023 images (AWS Marketplace AMIs)

Amazon has not yet released an updated ca-certificates package. When it ships, the fix is:

sudo dnf update ca-certificates
sudo systemctl restart sftpgw-admin-api

If you need to close the exposure before Amazon's package is available, you can distrust the two affected roots manually as root. This blocks the eMudhra root and the Comodo AAA root that cross-signed the compromised certificates:

d=/etc/pki/ca-trust/source/blocklist
trust extract --overwrite --format=pem-bundle \
  --filter='pkcs11:object=Comodo%20AAA%20Services%20root;type=cert' \
  $d/Comodo_AAA_Services_root.pem
trust extract --overwrite --format=pem-bundle \
  --filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' \
  $d/emSign_ECC_Root_CA_-_G3.pem
update-ca-trust

Then restart the application as above. The manual step is safe to leave in place after the package update arrives.

Container images (Docker, Kubernetes, Helm)

Our container images bundle the Amazon Corretto Java runtime, which carries its own trust store. Amazon has not yet released a Corretto build with the affected roots removed. We will publish updated image tags as soon as it does and will note the tag here. No action is needed on your side until then beyond pulling the new tag when it is announced.

How to verify

After updating and restarting, confirm the roots are gone from the Java trust store the application uses:

keytool -list -cacerts -storepass changeit | grep -i emsign

On a fixed system this prints nothing for emSign ECC Root CA - G3. Other emSign entries (Root CA - G1, Root CA - C1, ECC Root CA - C3) are not part of this incident and may still be listed.

You can also test the operating system trust store with the two test hosts published by the incident tracker. A certificate error is the correct result:

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

Note that this curl test checks the OS trust store, not the Java one. On Ubuntu the two are kept in sync automatically. On Amazon Linux the Java store is linked to the OS store, so the test applies there as well. In our container images only the keytool check is meaningful.

What we are doing

  • Rebuilding the Ubuntu-based marketplace images with the fixed package now. New launches from those images will not need the manual step once the listings are updated.

  • Rebuilding the Amazon Linux AMIs and container images as soon as Amazon ships the corresponding fixes.

  • Tracking the upstream status and updating this article as it changes.

Why this is not a product vulnerability

The weakness is in certificates issued by eMudhra and in the trust stores shipped by operating system and Java runtime vendors. SFTP Gateway uses the standard trust store on the system and does not add or pin certificate authorities of its own. The fix is a vendor package update, which is why no product release is required.

References

← PreviousNext →