# 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](node-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:
>
> 1. Add `--use-openssl-ca` to your service's `NODE_OPTIONS` environment variable.
> 2. 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](language-support) 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](docker) 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.

**Tab: Native runtime**

#### Updating native runtime services

**Subtab: Node.js**

#### Node.js

Follow [Step 1](#1-update-your-nodejs-version) 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.

**Subtab: Bun**

#### Bun

Upgrade your service's [Bun version](bun-version) to `1.4.4` or later.

**Subtab: Python**

#### Python

Many popular Python HTTP libraries ([Requests](https://requests.readthedocs.io/en/latest/user/advanced/#ca-certificates), [HTTPX](https://www.python-httpx.org/advanced/ssl/), etc.) use the [Certifi](https://github.com/certifi/python-certifi#readme) 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:*

------

##### pip

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

```text
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
```

------

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

**Subtab: Ruby**

#### 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](#3-redeploy-all-services) 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.

**Subtab: Go**

#### Go

Proceed to the [next step](#3-redeploy-all-services) to redeploy your service. Your Go service will automatically build using version `1.27.3` or later, which blocks trust for the compromised certificates.

**Subtab: Rust**

#### 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.

------

##### `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](#3-redeploy-all-services) to redeploy your service.

------

**Subtab: Elixir**

#### Elixir

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

- [CAStore](https://hexdocs.pm/castore/CAStore.html)
- [Erlang `certifi`](https://hex.pm/packages/certifi)

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

*See details for the HTTP library your application uses:*

------

##### `castore` (CAStore)

*Used by:* Req, Finch, Mint, Tesla (Finch or Mint [adapter](https://tesla.hexdocs.pm/3-adapter.html))

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](https://tesla.hexdocs.pm/3-adapter.html))

*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.

------

**Tab: Docker**

#### 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.

1. *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.
2. *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.
3. *If your service [pulls a prebuilt image](/deploying-an-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).
4. *For Docker services in particular,* we strongly recommend [confirming certificate rejection](#4-confirm-certificate-rejection-optional) in your service after you [redeploy](#3-redeploy-all-services).

### 3. Redeploy all services

**Tab: Dashboard**

Trigger a new deploy from a service's page in the [Render Dashboard](https://dashboard.render.com). Click *Manual Deploy > Deploy latest commit*:

[image: 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.

**Tab: MCP Server**

#### Render MCP server

The [Render MCP server](mcp-server) provides tools for triggering service deploys. After you connect your coding agent (Codex, Claude Code, etc.), prompt it to redeploy your services.

**Tab: CLI**

#### Render CLI

Use the Render CLI's [`deploys create`](cli-reference#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](cli-reference#deploys-create).

**Tab: API**

#### Render API

Use the Render API's [Trigger deploy](https://api-docs.render.com/reference/create-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](api#1-create-an-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](https://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](https://github.com/galadran/we-have-a-problem.com).

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. |


---

##### Appendix: Glossary definitions

###### environment variable

Config values you can apply to a service to customize its behavior at build and runtime, such as `NODE_VERSION` or `OPENAI_API_KEY`.

Render sets some environment variables for your service by [default](environment-variables).

Related article: https://render.com/docs/configure-environment-variables.md