[Bug]: T3 Connect still accepts cloudflared versions affected by the eMudhra compromise #25608

Before submitting

• I searched existing issues and did not find an open report covering this remaining gap.
• I included enough detail to reproduce or investigate the problem.

Area

packages/contracts or packages/shared

Steps to reproduce

1. Use a host with no managed cloudflared under the T3 home tools directory.
2. Put cloudflared 2026.9.3 on the server's PATH and leave T3CODE_CLOUDFLARED_PATH unset.
3. Enable T3 Connect and inspect the connector's executable and version.

The report in the closed issue describes this on macOS with Homebrew cloudflared 2026.9.3. This follow-up is based on that report and inspection of current upstream code, not a new runtime reproduction.

Expected behavior

T3 Connect should avoid running cloudflared releases affected by the eMudhra certificate-trust compromise. Cloudflare recommends upgrading cloudflared to 2026.10.2 or later.

Actual behavior

#25572 fixed the managed download pin and closed #25567. The pin is now 2026.10.4, but CLOUDFLARED_MIN_VERSION remains 2025.6.1.

In the relay client resolver, compatibleCandidate applies that older minimum to PATH binaries, explicit overrides, and managed copies. As a result:

• With no managed copy, an affected PATH binary such as 2026.9.3 is accepted.
• T3CODE_CLOUDFLARED_PATH can select an affected version.
• An affected older managed copy such as 2026.10.0 remains eligible as a fallback while the pinned update is unavailable.

Impact

The managed pin update does not cover every executable T3 Connect can select. These paths can still run a release affected by the certificate-trust compromise.

Version or commit

main @ b6994c5, after #25572 merged.

Environment

Reported on macOS with Homebrew cloudflared. The shared resolver also handles Linux and Windows.

Workaround

Upgrade the selected cloudflared binary to a fixed release and restart the connector. For an explicit override, point it at the upgraded executable. Installing a newer PATH binary alone does not replace an older managed copy, because managed copies take precedence.

Proposed scope for maintainer confirmation

Would raising CLOUDFLARED_MIN_VERSION to at least 2026.10.2 be the intended follow-up, including rejecting outdated explicit overrides and older managed fallbacks?

This would use the existing behavior for incompatible versions: skip an outdated PATH binary so the managed pin can be installed, and report an outdated explicit override as unavailable rather than silently selecting a different binary. If the managed download fails and only affected copies remain, Connect would be unavailable until a fixed binary is installed.

A follow-up PR would stay limited to that version floor, its explanatory comment, and focused regression tests for PATH, overrides, and managed fallback. This issue asks for confirmation of that behavior before opening a PR.

Filed with GPT-6.1 Sol in the Codex harness.