Advisory: eMudhra Certificate Compromise

Update and rebuild your services to safeguard against impersonation attacks.

Summary

On October 19, 2026, a public disclosure confirmed the compromise of private keys for eight intermediate certificates issued by eMudhra, a widely trusted certificate authority.

Malicious actors can use these keys to impersonate a legitimate website or service to any client that continues to trust the compromised certificates. Render services that communicate over the internet might be vulnerable to such an impersonation attack.

Key points

The Render platform has not been compromised by this vulnerability.
We have taken immediate action to apply library and language patches to our own infrastructure and service runtimes.
Follow the steps below as soon as possible to secure your services against this vulnerability.

Steps to secure your services

Unless otherwise noted, perform these steps for all services of the following types:

Web service
Private service
Background worker
Cron job
Workflow
Static site
- Static sites require updating only if your site's build process uses Node.js or makes HTTPS requests.

1. Update your Node.js version

You can skip this step for any service that does not use Node.js at all during its builds or at runtime.

All Render native runtimes include Node.js, regardless of your application's primary language. For example, a Ruby or Python service might use Node.js to run build tools.

If your service uses Node.js at build time or runtime, set its Node.js version to one of the following (or any later version of the same major version):

22.23.4
24.22.1
26.12.1

Node.js versions before 22.x are end-of-life and have not been patched for this vulnerability.

To temporarily continue using an earlier version:

Add --use-openssl-ca to your service's NODE_OPTIONS environment variable.
Remove --use-bundled-ca and --use-system-ca from NODE_OPTIONS if present.

2. Update language and framework dependencies

The process to update a given service depends on its language and runtime:

Services on a Render native runtime include a system CA store that will automatically update with your service's next build.
- However, not all languages and frameworks use the system CA store. See details for each language below.
Services on a Render Docker-based runtime use whichever CA store the Dockerfile bundles.
- Because your Docker image fully determines the certificate authority mechanism used by your service, you are responsible for updating all aspects of that mechanism.

Updating native runtime services

Node.js

Follow Step 1 to update your Node.js version. For Docker-based services, update the Node.js installation in your image to one of the versions listed there.

Bun

Upgrade your service's Bun version to 1.4.4 or later.

Python

Many popular Python HTTP libraries (Requests, HTTPX, etc.) use the Certifi package for certificate verification. These libraries usually install Certifi as an indirect dependency if you don't install it directly. Certifi supplies its own bundle of trusted CA certificates.

Update certifi to version 2026.10.19 or later:

Package manager Update instructions

Package manager	Update instructions
pip	In your `requirements.txt` file, add or update the `certifi` entry to require `2026.10.19` or later: plaintext certifi>=2026.10.19 If you generate `requirements.txt` with a tool such as pip-tools, update the source requirements and regenerate using your tool's command.
uv	Run the following to update `uv.lock`: shell $ uv lock --upgrade-package certifi
Poetry	Run the following to update `poetry.lock`: shell $ poetry update certifi

pip

In your requirements.txt file, add or update the certifi entry to require 2026.10.19 or later:

plaintext

certifi>=2026.10.19

If you generate requirements.txt with a tool such as pip-tools, update the source requirements and regenerate using your tool's command.

Run the following to update uv.lock:

shell

$ uv lock --upgrade-package certifi

Poetry

Run the following to update poetry.lock:

shell

$ poetry update certifi

After updating, confirm that your dependency or lockfile resolves certifi to 2026.10.19 or later.

Ruby

By default, most popular HTTP libraries for Ruby and Rails apps (Net::HTTP, httparty, etc.) use the system CA store. Libraries that fall into this category do not require a version update. The system CA store will automatically update with your service's next build. Proceed to the next step to redeploy your service.

If you've configured your library to use a custom CA bundle, update that bundle separately or configure the library to use the system CA store instead.

Exception: `httpclient`

The httpclient gem supplies its own bundle of trusted CA certificates and uses it by default. Configure each HTTPClient instance to use the system CA store instead, like so:

ruby

client = HTTPClient.new
client.ssl_config.set_default_paths

Make sure to call set_default_paths before making any requests.

Go

Proceed to the next step to redeploy your service. Your Go service will automatically build using version 1.27.3 or later, which blocks trust for the compromised certificates.

Rust

Rust applications using rustls can use libraries that bundle trusted CA certificates or load them from the system trust store. These libraries might be installed as indirect dependencies.

Follow the update instructions for each library your application uses. After updating, confirm that your Cargo.lock file resolves each applicable package to the patched version or later.

Library Update instructions

Library	Update instructions
`webpki-roots` / `webpki-root-certs`	These libraries compile trusted CA certificates into your application. Update each package your application uses to `1.0.10` or later. For `webpki-roots`, run: shell $ cargo update -p webpki-roots For `webpki-root-certs`, run: shell $ cargo update -p webpki-root-certs
`rustls-webpki`	This library verifies certificates. Update to `0.103.16` or later to reject the compromised certificate keys: shell $ cargo update -p rustls-webpki
`rustls-native-certs`	This library uses the system trust store, which will automatically update with your service's next build (no update required). Proceed to the next step to redeploy your service.

webpki-roots / webpki-root-certs

These libraries compile trusted CA certificates into your application. Update each package your application uses to 1.0.10 or later.

For webpki-roots, run:
shell
```
$ cargo update -p webpki-roots
```
For webpki-root-certs, run:
shell
```
$ cargo update -p webpki-root-certs
```

rustls-webpki

This library verifies certificates. Update to 0.103.16 or later to reject the compromised certificate keys:

shell

$ cargo update -p rustls-webpki

rustls-native-certs

This library uses the system trust store, which will automatically update with your service's next build (no update required). Proceed to the next step to redeploy your service.

Elixir

Most Elixir HTTP libraries use one of the following packages for certificate verification:

Each of these packages supplies its own bundle of trusted CA certificates.

See details for the HTTP library your application uses:

Library Update instructions

Library	Update instructions
`castore` (CAStore)	Used by: Req, Finch, Mint, Tesla (Finch or Mint adapter) Update `castore` to version `1.0.22` or later. Run the following to update `mix.lock`: shell $ mix deps.update castore After updating, confirm that your dependency or lockfile resolves `castore` to `1.0.22` or later.
Erlang `certifi`	Used by: HTTPoison, Tesla (Hackney adapter) As of the most recent update to this advisory, Erlang `certifi` has not received a patch for this vulnerability. We will update this advisory when a patch becomes available.

castore (CAStore)

Used by: Req, Finch, Mint, Tesla (Finch or Mint adapter)

Update castore to version 1.0.22 or later.

Run the following to update mix.lock:

shell

$ mix deps.update castore

After updating, confirm that your dependency or lockfile resolves castore to 1.0.22 or later.

Erlang certifi

Used by: HTTPoison, Tesla (Hackney adapter)

As of the most recent update to this advisory, Erlang certifi has not received a patch for this vulnerability. We will update this advisory when a patch becomes available.

Updating Docker-based services

Docker-based services on Render do not use the same base images as Render's native runtimes. This means you are responsible for updating your image's CA certificates and dependencies.

Update the system CA store. For common base images such as Debian or Alpine, this usually involves updating your Dockerfile to install the latest patched version of the ca-certificates package available for your distribution.
Update runtimes and dependencies that supply their own CA certificates. Use the language tabs under Native runtime as a guide to identify affected packages and patch their versions.
If your service pulls a prebuilt image from a registry, push an updated image. Make sure your Render service is configured to pull the updated image (for example, push your image to the expected registry tag or change the tag that your service uses).
For Docker services in particular, we strongly recommend confirming certificate rejection in your service after you redeploy.

3. Redeploy all services

Trigger a new deploy from a service's page in the Render Dashboard. Click Manual Deploy > Deploy latest commit:

Triggering a manual deploy in the Render Dashboard

For a service that pulls a Docker image, this is instead Manual Deploy > Deploy latest reference. Make sure your service's image source correctly references the updated image.

Render CLI

Use the Render CLI's deploys create command to trigger a new deploy for a service.

To select a service interactively, run the command without options:
shell
```
$ render deploys create
```
This opens a menu of your services to choose from.
To deploy a specific service, provide its service ID:
shell
```
$ render deploys create srv-abc123
```

For all supported options, see the Render CLI reference.

Render API

Use the Render API's Trigger deploy endpoint to trigger a new deploy for a service:

shell

$ curl --request POST \
    --url https://api.render.com/v1/services/srv-abc123/deploys \
    --header 'Authorization: Bearer YOUR_API_KEY' \
    --header 'Content-Type: application/json' \
    --data '{"deployMode":"build_and_deploy"}'

Replace srv-abc123 with your service's ID and YOUR_API_KEY with a valid Render API key. The build_and_deploy mode triggers a new build before deploying.

4. Confirm certificate rejection (optional)

Members of the wider developer community have generously created emudhra.we-have-a-problem.com to help explain this vulnerability, track available fixes, and provide resources to help teams address it. The site's source is publicly available on GitHub.

The site provides test endpoints that intentionally use the compromised certificates. To check whether your deployed application rejects these certificates, use its HTTP client to send requests to both endpoints:

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

These requests should fail with a certificate verification error! If either request succeeds (even with a non-200 status code), the client still trusts the compromised certificates and requires further remediation.

To serve as a meaningful test, these requests must originate from your running Render service, using its HTTP client.

Even a curl request from your running service's shell might use a different CA store from your production server.

History of updates to this advisory

Date	Change
`2026-10-22`	Posted initial advisory.

Summary

Key points

Steps to secure your services

1. Update your Node.js version

2. Update language and framework dependencies

Updating native runtime services

Node.js

Bun

Python

Ruby

Exception: httpclient

Go

Rust

Elixir

Updating Docker-based services

3. Redeploy all services

Render MCP server

Render CLI

Render API

4. Confirm certificate rejection (optional)

History of updates to this advisory

Advisory: eMudhra Certificate Compromise

Exception: `httpclient`