Skip to main content
Cordon 0.4.3 fixes the October eMudhra certificate incident 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, 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 for the dependency fixes.
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.
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:
This installs the latest release. Confirm that Cordon reports 0.4.3 or later. Use your existing installation method for other copies: cordon upgrade supports npm and Homebrew; manually installed binaries need the appropriate release asset. 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:
For each active service, replace SERVICE_NAME with its name:
Run cordon doctor from the upgraded installation with that service’s configuration:
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.
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:
Check that the preview shows the intended binary, service name, and config. Then repair the service:
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.
Stop and relaunch manually started instances through their usual launcher, with the same config and environment. For a foreground instance:
For these instances, or when doctor’s result is inconclusive, replace PORT below with the config’s listen port:
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.
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:
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.
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:
cordon status list finds installed services and running processes, not every inactive config.
Cordon reads the first available PEM bundle in its known Homebrew/OS locations. See cordon env 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.
Use public probes without real API credentials. Do not add probe hosts to production credential routes.
The incident site 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.