Stop fetching protocol rollout percentages from DNS TXT records.
Remove the obsolete remote selector, percentage-fetching API, and
related tests, and simplify protocol selector construction.
Delete the unused tunnelsForHA implementations and stale edge
discovery test mocks. Remove unpopulated metrics and simplify
the stream copy path by dropping its permanently disabled debug
implementation.
Remove the hidden stdin-control flag and ReconnectSignal plumbing used to
force tunnel reconnections through stdin. Delete the associated component
test and supervisor control implementation.
Serve QUIC and HTTP/2 connections directly with the caller context instead
of wrapping them in an additional errgroup for reconnect signals. Automatic
reconnection after genuine transport failures remains unchanged.
This removal should help simplify the supervisor loop a bit and make way
for better improvements in this area.
Closes TUN-10820
This PR is fixing VULN-141859. Basically, this follows on [RFC-3986](https://datatracker.ietf.org/doc/html/rfc3986#section-5.2.4) clean algorithm by taking<span dir=""> a path with dot parts like </span>`./`<span dir=""> or </span>`../`<span dir=""> and cleaning them, outputting an absolute path</span> (RFC can be found [here](https://datatracker.ietf.org/doc/html/rfc3986#section-5.2.4)).
The bulk of the changes are introduced in `canonicalizeRequestPath`, which does the following: (1) Rejects paths escaping root, (2) applies path.Clean, (3) preserves trailing slash, and (4) clears RawPath so that escaping matches the canonical Path.
We also added tests to test the normalization logic we added.
## Problem
`NewEncrypter` loaded the token transfer keypair from `cloudflared_priv.pem` and `cloudflared_pub.pem` in the current working directory, generating and persisting them only when absent. An attacker who could place those files in a directory a user later ran cloudflared from — a repository checkout, an extracted archive, a shared or world-writable directory — knew the resulting public key in advance.
That public key is sent to the edge as the token transfer capability, and the transfer service treats it as a bearer address with no identity binding. Knowing it ahead of time let an attacker poll for the victim's credential: the account-scoped API token written to `cert.pem` by `tunnel login`, or the application JWT from `access login`. The victim's login still succeeded, so the theft left no visible trace.
## Fix
Always derive the keypair from `box.GenerateKey` and never read or write it to disk. The on-disk path is removed entirely, along with the filesystem imports, so restoring it would require a visible import change in review. `NewEncrypter` no longer takes filename arguments — note this is a change to an exported signature, though the only in-tree caller is `RunTransfer`.
Also reject payloads shorter than the 24-byte nonce in `Decrypt`, which previously panicked on a slice out of range. The smallest valid payload is 40 bytes, so the guard cannot reject legitimate input.
Jira: AUTH-9041 VULN-141861
## Problem
`GetAppInfo` trusted unsigned `CF-Access-Domain` and `CF-Access-Aud` response headers when selecting cached Access tokens. An attacker-controlled endpoint could spoof another application's identity, causing cloudflared to load and send that application's cached token.
## Fix
Discover applications through the edge's signed metadata JWT, validate its claims and requested hostname, and verify its RS256 signature against a canonicalized Cloudflare Access JWKS endpoint. Cache JWKS atomically, refresh on key rotation, and validate cached token audiences before use.
This relies on access-edge-engine [early return for cf-access-metadata-requests](https://gitlab.cfdata.org/cloudflare/ea/access-edge-engine/-/blob/main/bin/access-engine-server/src/engine/http/mod.rs?ref_type=heads#L1464-1472) when processing seldhosted apps
Jira: AUTH-9012 VULN-141860
Tested manually previous working behaviour and the VULN fix
As with recent changes with Linux and MacOS, use --token-file instead of --token when installing the service for Windows.
The secret token was viewable by an unprivileged user by looking at the registry entry HKLM\\SYSTEM\\CurrentControlSet\\Services\\Cloudflared\\ImagePath, which stores the full command-line invocation of cloudflared (complete with --token ).
We fix this by storing the token in a file and restricting access to it.
The canonical way of protecting a secret token on Windows is to use the CryptProtectData and CryptUnprotectData functions in dpapi.h, which encrypt/unencrypt data using an OS-managed secret key. See here:
https://learn.microsoft.com/en-us/windows/win32/api/dpapi/
While we could use the DPAPI to encrypt/decrypt the token before writing it out to disk, this has two problems:
1) We would break existing Windows installs using --token-file with an unencrypted token file
2) We would introduce an inconsistency between how --token-file works on Linux/MacOS and Windows
Because of this, we keep things consistent and just add logic to cloudflared to protect the token file by modifying the permissions of the token file.
Windows's permission model differs completely from Linux and MacOS, so a Windows-specific function is used to restrict the token file's permissions. We strip ACLs from the file such that it's only readable by SYSTEM and Administrators.
Also done by this MR:
* Improve "service install --help" output on Windows to be in-line with Linux and MacOS
* Change uses of path.Join that work with file paths to be filepath.Join instead, which will use the correct platform-specific path separator (\\ on windows or / on \*nix) instead of only forward slashes
* Pull out constant string in MacOS service
Use curves when running pre-checks. Although it is not something critical, pre-checks should closely match the current cloudflared behavior when trying to establish connections to the edge. Adding curves here matches the current behavor.
* Refactor directory-related functions in macos_service.go to pull out common logic
* Use --token-file instead of --token when installing cloudflared with a token on MacOS such that the secret token will not show up in the output of "ps aux" (or similar)
* Improve the "service install" help text on MacOS to distinguish between the "service install " and "service install \<token\>" cases
Changing image name. The image is currently under `/tun/cloudflared/cloudflared-daemon/master`. We want to instead have it under `/tun/cloudflared/cloudflared/master`. Adding the `daemon` suffix does not add much value.
This MR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| gcr.io/distroless/base-debian13 | final | digest | `ab7554b` → `b78832f` |
---
### Configuration
📅 **Schedule**: (UTC)
- Branch creation
- At 12:00 AM through 04:59 AM and 10:00 PM through 11:59 PM, Monday through Friday (`* 0-4,22-23 * * 1-5`)
- Only on Sunday and Saturday (`* * * * 0,6`)
- Automerge
- At any time (no schedule defined)
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever MR is behind base branch, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this MR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box
---
This MR has been generated by [Mend Renovate](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4yNTcuNSIsInVwZGF0ZWRJblZlciI6IjQzLjI1Ny41IiwidGFyZ2V0QnJhbmNoIjoibWFzdGVyIiwibGFiZWxzIjpbXX0=-->
Bookworm has been deprecated and therefore our internal
repository no longer accepts the publish of new packages.
We are then removing the publish to the internal repositories of bookworm.
When installed with a token, e.g.,
$ cloudflared service install \<token\>
cloudflared will set itself up to be run by the init system using the --token argument. This results in tokens being visible in the output of ps aux by unprivileged users. Change this such that this installation method instead puts the token in a file with mode 600 in /etc/cloudflared and uses the --token-file flag instead.
Adding a test that tries to exercise the race condition for the websocket path. The sequence is as follows:
1. The test starts by writing the payload to the mock server
2. Then, it closes the write side of the connection.
3. It waits for 3 seconds to make the race window explicit: the bug in cloudflared would have closed the connection and we would not be able to read.
4. Read the message.
With the fix applied, we should be able to read the full message.
This PR addresses an issue where cloudflared prematurely closes the origin connection before the upstream-to-downstream goroutine finishes reading, causing intermittent connection drops when a client immediately closes the write-side of a connection.
When a client finishes writing data, it immediately closes its side of the connection. Under the current implementation in cloudflared's downstream-to-upstream goroutine does not wait for the second stream to complete. It unblocks the moment the first stream writes to the channel. Once this happens, the pipe returns control to `proxyTCPStream`, which prematurely closes the origin connection. Consequently, when the upstream-to-downstream goroutine attempts to read the remaining data from the origin connection, the connection is already gone, leading to unexpected failures.
We started propagating the `TimeoutAfterFirstClose` configuration/parameter. This allows the proxy to wait for a designated period, giving the second stream sufficient time to finish processing and read all remaining data before `proxyTCPStream` tears down the origin connection.
systemctl list-units exits 0 whether or not any pattern matches, so the
filter was a no-op and every unit was always treated as installed.
Detect installed units by checking for the unit file on disk instead.
Generate a clean init script at /etc/init.d/cloudflared backed by
OpenRC's supervise-daemon supervisor, plus a companion
/etc/conf.d/cloudflared for operator overrides.
This MR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| gcr.io/distroless/base-debian13 | final | pinDigest | → `ab7554b` |
---
### Configuration
📅 **Schedule**: (UTC)
- Branch creation
- At 12:00 AM through 04:59 AM and 10:00 PM through 11:59 PM, Monday through Friday (`* 0-4,22-23 * * 1-5`)
- Only on Sunday and Saturday (`* * * * 0,6`)
- Automerge
- At any time (no schedule defined)
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever MR is behind base branch, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this MR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box
---
This MR has been generated by [Mend Renovate](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4yMjQuMCIsInVwZGF0ZWRJblZlciI6IjQzLjIyNC4wIiwidGFyZ2V0QnJhbmNoIjoibWFzdGVyIiwibGFiZWxzIjpbXX0=-->
As it stands, cloudflared prechecks are not taking the `protocol` flag into consideration and is instead falling back to the default protocol, which is QUIC. Prechecks should report the protocol cloudflared will use, not the default protocol.
