> ## Documentation Index
> Fetch the complete documentation index at: https://docs.codezero.io/llms.txt
> Use this file to discover all available pages before exploring further.

# October 2026 security upgrade

> Upgrade Cordon, refresh client CA bundles, and restart your apps after the October security update.

Cordon **0.4.3** fixes the [October eMudhra certificate incident](https://emudhra.we-have-a-problem.com/#developers) and applicable dependency vulnerabilities. Follow these four steps on each machine, container, or VM where you use Cordon.

Upgrading Cordon applies its security fixes. You also need to restart running instances and refresh the certificate bundles used by your apps.

## What happened and why Cordon is affected

The [incident report](https://emudhra.we-have-a-problem.com/), published on October 20, 2026, describes compromised private keys for eight eMudhra intermediate certificate authorities. An attacker could use those keys to impersonate a website to a vulnerable client. Cordon connects to APIs on your behalf and sends credentials, so it must reject those certificates.

Cordon 0.4.3 adds that protection. Your apps also need updated runtimes and certificate sources because they verify some connections themselves. See the [release notes](https://github.com/codezero-io/cordon/releases/tag/v0.4.3) for the dependency fixes.

> [!NOTE]
>
> Cordon's locally generated CA is unrelated to eMudhra. Keep it: you do not need to regenerate it or rerun `cordon trust`. An affected installation does not by itself mean credentials were exposed.

> **Technical background**
>
> Faulty key generation made the eight intermediate private keys recoverable from public certificates that had existed since April 2025. Some intermediates have cross-signed certificates, so removing only eMudhra's own root is insufficient.
>
> The CA revoked the affected certificates, but many non-browser clients do not consume those revocation updates or enforce Certificate Transparency. The report does not establish whether attackers exploited the keys against those clients.
>
> Cordon's upstream HTTPS and PostgreSQL TLS connections load OS roots but use Rust's `rustls-webpki` verifier, without the OS's native revocation services. Version 0.4.3 updates it to **0.103.16**, which distrusts the affected intermediate public keys even with older roots installed. It also updates `webpki-roots` to **1.0.11** for the CLI's bundled trust store.
>
> An attacker able to intercept or redirect a configured credential route could receive injected credentials if Cordon accepted the fraudulent certificate. Investigate and rotate credentials if there is evidence of exposure under your incident-response process. For unconfigured HTTPS hosts, Cordon forwards an opaque tunnel and the app verifies the server itself.

## 1. Upgrade Cordon and your runtimes

For npm installations, update Node through your existing version manager or package manager. Supported versions are **22.23.4+**, **24.22.1+**, or **26.12.1+** within those respective major versions. Node 20 is no longer supported.

Check project version pins and service launch paths too: a service can use a different Node or Cordon installation from your terminal.

For an npm installation:

```bash theme={null}
node --version
npm install -g @codezero-io/cordon
cordon --version
```

This installs the latest release. Confirm that Cordon reports **0.4.3 or later**. Use your existing installation method for other copies: [`cordon upgrade`](https://docs.codezero.io/cli/upgrade) supports npm and Homebrew; manually installed binaries need the appropriate [release asset](https://github.com/codezero-io/cordon/releases).

Update the apps and runtimes that use Cordon too. Python tools, Java, and browsers can have their own certificate stores; an OS update alone may not cover them.

## 2. Restart Cordon

Find your running instances and their service names:

```bash theme={null}
cordon status list --verbose
```

For each active service, replace `SERVICE_NAME` with its name:

```bash theme={null}
cordon service stop SERVICE_NAME && cordon service start SERVICE_NAME
cordon status SERVICE_NAME --verbose
```

Run [`cordon doctor`](https://docs.codezero.io/cli/doctor) from the upgraded installation with that service's configuration:

```bash theme={null}
cordon doctor --config /path/to/cordon.toml
```

Confirm the service is healthy and doctor reports `binary is current (v0.4.3)` or a later patched version. If it reports an old version or cannot identify the running version, use the checks below. Leave intentionally inactive instances stopped.

> **The service still runs an old version, or will not start**
>
> A service records its executable's path when installed. Upgrading can leave it pointing at an old or removed copy. Record its name and exact config path, then run these commands from the upgraded Cordon CLI:
>
> ```bash theme={null}
> cordon service install SERVICE_NAME --config /path/to/cordon.toml --dry-run
> ```
>
> Check that the preview shows the intended binary, service name, and config. Then repair the service:
>
> ```bash theme={null}
> cordon service uninstall SERVICE_NAME && cordon service install SERVICE_NAME --config /path/to/cordon.toml
> cordon status SERVICE_NAME --verbose
> cordon doctor --config /path/to/cordon.toml
> ```
>
> Installation starts the daemon and preserves your config and CA. If installation fails, resolve the error and rerun the install command. If you customized the launchd/systemd definition or environment, preserve those settings and update the executable through your service-management procedure instead.

> **I start Cordon manually, or doctor cannot identify its version**
>
> Stop and relaunch manually started instances through their usual launcher, with the same config and environment. For a foreground instance:
>
> ```bash theme={null}
> cordon stop --config /path/to/cordon.toml
> cordon start --config /path/to/cordon.toml
> ```
>
> For these instances, or when doctor's result is inconclusive, replace `PORT` below with the config's listen port:
>
> ```bash theme={null}
> curl --noproxy '*' --fail --silent --show-error http://127.0.0.1:PORT/status
> ```
>
> Check that `version` is 0.4.3 or later and `config_path` is the intended configuration. Confirm the listener PID in `cordon status list --verbose` belongs to the restarted instance. A missing version or a healthy listener alone does not prove the upgrade completed.

## 3. Refresh client CA bundles

**Update the public certificate source first.** Refreshing copies installed certificates; it does not download new ones. If Cordon uses Homebrew's CA bundle, update `ca-certificates` through Homebrew. On Debian/Ubuntu, update the `ca-certificates` package and run `update-ca-certificates`. Use your distribution's equivalent elsewhere. On macOS, updating Keychain alone may leave Homebrew's bundle unchanged.

> [!WARNING]
>
> If you added custom certificates directly to `combined-ca.pem`, back it up and install those custom roots in the managed source bundle before refreshing. Refresh replaces the whole combined bundle. Do not restore outdated public roots from the old file.

In each project configured for TLS, run:

```bash theme={null}
cordon env --refresh-ca-bundle > /dev/null
```

Check that it succeeds and reports the certificate source you updated. The redirect hides environment output, which can contain proxy tokens; errors and refresh details remain visible. Your local Cordon CA, private key, and configuration are preserved.

> **User scope, other projects, or custom configurations**
>
> Project and user scopes are separate. Refresh each configuration you use, including occasional projects and integration profiles such as `~/.hermes/cordon.toml` or `~/.openclaw/cordon.toml` where applicable:
>
> ```bash theme={null}
> # User scope, if configured
> cordon env --scope user --refresh-ca-bundle > /dev/null
>
> # Another project or custom configuration
> cordon env --config /path/to/cordon.toml --refresh-ca-bundle > /dev/null
> ```
>
> `cordon status list` finds installed services and running processes, not every inactive config.

> **Certificate source selection or refresh errors**
>
> Cordon reads the first available PEM bundle in its known Homebrew/OS locations. See [`cordon env`](https://docs.codezero.io/cli/env#refreshing-the-ca-bundle) for source selection and certificate requirements. Install custom roots through that source manager's supported mechanism; direct edits to generated files can be overwritten.
>
> Input-validation and bundle-write failures preserve the previous bundle. If a `Refreshed` message is followed by a token or environment-output error, the bundle was already replaced. Resolve the later error and rerun the command.
>
> Refreshing does not change OS trust, rotate Cordon's local CA, or add certificate revocation checking.

## 4. Restart your apps and check they work

Restart the applications, agent sessions, and gateways that use Cordon so they reload the updated runtime, certificates, and connections. Make sure they still use the intended Cordon configuration.

Make a normal request through your configured provider and check the features you use, such as streaming or uploads. Repeat for each active configuration. Normal requests confirm functionality; the recommended checks below verify rejection of the compromised certificates.

> **Verify rejection of affected certificate chains**
>
> > [!WARNING]
> >
> > Use public probes without real API credentials. Do not add probe hosts to production credential routes.
>
> The [incident site](https://emudhra.we-have-a-problem.com/#developers) provides affected-chain probes. Test all variants, including cross-signed and no-CT chains, with the client runtime and CA settings you actually use. Use `https://emudhra.we-have-a-problem.com/` as a healthy control.
>
> Confirm rejection is specifically a certificate-validation error. Timeouts, DNS failures, connection refusals, and generic proxy errors are inconclusive. A browser result covers that browser; through an unconfigured Cordon host, the app validates TLS, not Cordon's upstream verifier.
>
> Cordon 0.4.3's release qualification tested its upstream HTTPS, PostgreSQL TLS, and CLI HTTPS verification against all 14 affected chains and healthy controls. That evidence does not identify which binary or client settings your installation uses.

You're finished when every Cordon copy you use is patched, active instances have restarted, client runtimes and certificate sources are updated, bundles are refreshed, and your restarted apps work normally.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.