Repository navigation
[Bug]: T3 Connect's managed cloudflared 2026.10.0 still trusts the compromised eMudhra intermediates #25567
Description
Area
packages/contracts or packages/shared
Steps to reproduce
- Turn on T3 Connect on a host that has no
cloudflaredonPATH. - Let T3 Code install its managed relay client.
- Run
~/.t3/tools/cloudflared/2026.10.0/<platform>/cloudflared --version.
Expected behavior
The managed relay client is cloudflared 2026.10.2 or later. Cloudflare asks every Tunnel owner to run that version or later, and 2026.10.3 or later for macOS builds not installed with Homebrew.
Actual behavior
CLOUDFLARED_VERSION on main is "2026.10.0" (packages/shared/src/relayClient.ts), so every host that uses the managed relay client runs 2026.10.0. That version still trusts the eight eMudhra (emSign) intermediate certificates whose private keys are weak. Anyone with those keys can issue a certificate that cloudflared accepts for any name.
Cloudflare's write-up: https://blog.cloudflare.com/emudhra-certificate-compromise/. Cloudflare also emailed Tunnel owners on 2026-10-26 asking them to upgrade every cloudflared instance.
The Electron side of the same problem was fixed in #22610 / #22645, and the preview browser in #24542. The managed relay client is still pinned to an affected release.
cloudflared 2026.10.4 (released 2026-10-26) is the latest release. It also includes VULN-176088, which allowlists debug endpoints on the metrics server. T3 Code starts the connector with --metrics.
Impact
Security exposure on every host that uses the managed relay client. No functional breakage.
Version or commit
main @ 210b2e7
Environment
Any platform that uses the managed relay client. Seen on the Linux x64 desktop app.
Logs or stack traces
$ ~/.t3/tools/cloudflared/2026.10.0/linux-x64/cloudflared --version
cloudflared version 2026.10.0 (built 2026-10-05-17:37 UTC)Workaround
Install cloudflared 2026.10.2 or later from Cloudflare's package repository. Then point T3CODE_CLOUDFLARED_PATH at it, or remove the managed copies under ~/.t3/tools/cloudflared. Resolution prefers a managed copy over PATH, so installing a newer system cloudflared alone does not switch the connector.
Filed with Claude Opus 5.5 in Claude Code.
Activity
adpadillar commentedon Oct 26, 2026
+1 this
maschwenk commentedon Oct 26, 2026
(from agent)
one gap #25572 doesn't cover:
CLOUDFLARED_MIN_VERSIONis still2025.6.1, so a cloudflared on PATH or inT3CODE_CLOUDFLARED_PATHolder than 2026.10.2 is still accepted. resolution only falls through to PATH when there's no managed copy, which is the homebrew case.hit this today: nothing under
~/.t3/tools/cloudflared, homebrew cloudflared 2026.9.3 on PATH, and the T3 Connect connector was running/opt/homebrew/bin/cloudflared2026.9.3. afterbrew upgradeand letting the supervisor restart the child it came back on 2026.10.3, but nothing in T3 would have flagged or replaced the old one.the same check also keeps a stale managed 2026.10.0 usable through the older-managed fallback if the 2026.10.4 install fails, until it eventually succeeds.
suggest raising
CLOUDFLARED_MIN_VERSIONto 2026.10.2. a too-old PATH binary then gets skipped with the existing "Skipping an incompatible relay client on PATH" warning and T3 installs the pinned build. tradeoff: an override pointing at an old build fails closed instead of running. seems right for a cert-trust fix but it's a behavior change, so asking before opening a PR. happy to send one if you want it.