The F5 auth bypass that fit in one header: Connection: X-F5-Auth-Token
CVE-2022-1388 let unauthenticated attackers run commands as root on F5 BIG-IP by abusing hop-by-hop header handling. Naming the auth-token header in the Connection header made the proxy strip it after the auth check read it, but before the backend did.
The exploit for CVE-2022-1388 is almost too small to believe. To bypass authentication on F5 BIG-IP’s iControl REST management API and run commands as root, you send a request with the header Connection: X-F5-Auth-Token. That’s the core of it. CVSS 9.8, unauthenticated, and the payoff is the /mgmt/tm/util/bash endpoint executing arbitrary system commands as root. It’s a different mechanism from the AJP request-smuggling bypass in CVE-2023-46747, but it’s the same underlying disease: the components in front of and behind the auth check disagree about the request.
Why one header is enough
The Connection header is a hop-by-hop header. Its job is to tell a proxy which headers are meant only for that hop and should be removed before the request is forwarded onward. So when a request arrives at BIG-IP’s front-end carrying Connection: X-F5-Auth-Token, it’s instructing the proxy to strip the X-F5-Auth-Token header before passing the request to the backend iControl REST service.
The vulnerability is in the ordering. The front-end’s authentication check looked at the request, including its headers, and then the hop-by-hop processing removed X-F5-Auth-Token, and then the request reached the backend, which handles authentication on its own terms and treated the now-modified request as authenticated. The auth decision was made against one version of the request; the backend acted on a different version. An attacker who controls the headers controls that gap. F5 documented the fix in K23605346, shipping patches on May 4, 2022; CISA added it to the Known Exploited Vulnerabilities catalog on May 10 with the ransomware flag, and public PoCs and mass exploitation followed within days.
The reusable lesson: hop-by-hop headers and request mutation
This is a specific, recurring web-security pitfall worth knowing if you build or operate anything with a proxy in front of an app:
- Hop-by-hop headers (
Connection, and what it names) can mutate a request between the security check and the handler. If your authentication or authorization decision is made by one component and the request is then modified before another component honors it, an attacker who can trigger that modification can desynchronize the two. The defense is to make the security-relevant view of the request the same as the one that’s acted upon, validate at the point of use, and don’t let untrusted input dictate which headers survive. - Don’t let the backend trust that the front-end already authenticated. As with the trusted-header bypasses, a backend that assumes “if this reached me, it’s authenticated” is one request-manipulation bug away from compromise. Each component should verify, or use a cryptographically verifiable token rather than the presence/absence of a plaintext header.
- Request smuggling and header desync are a family. CVE-2022-1388 (hop-by-hop header) and CVE-2023-46747 (HTTP-to-AJP smuggling) are two expressions of the same idea, the proxy and the origin parsing or transforming the request differently. Treat that whole class as high-risk on any layered web architecture.
What to do
The operational response is the same playbook as the other BIG-IP management-plane bugs, covered in detail in the CVE-2023-46747 runbook:
- Patch to a fixed BIG-IP version (13.1.5, 14.1.4.6, 15.1.5.1, 16.1.2.2, 17.0.0, or later). Note F5 did not fix the 11.6.x and 12.1.x lines, so those need to be retired.
- Get the management interface (iControl REST / TMUI) off any network it doesn’t need to be on, ideally a dedicated management network only. This single control defuses the entire bug class.
- Assume compromise on exposed, unpatched devices, and audit for persistence. Root RCE means attackers could add admin accounts, SSH keys, and config changes that survive the patch. Hunt for them, rotate device credentials and keys, and rebuild if you can’t be sure it’s clean.
The reframe is the same one that keeps recurring for layered systems: the security check and the thing it protects must agree on what the request is. CVE-2022-1388 broke that with a single hop-by-hop header that quietly edited the request between the two. Patch it, take the management plane off the open network, and when you design systems with a proxy in front, make sure nothing can change the request after the gate has decided to open. We track the auth-bypass and request-desync entries closely, because they’re the bugs where the door looks locked and isn’t.
Sources
Share
Related field notes
-
F5 CVE-2023-46747: the backend trusted a header that said 'I'm already an admin'
The Tomcat backend behind F5's config utility trusted a remote_user header as proof of authentication, assuming only the front-end could set it. HTTP-to-AJP request smuggling let attackers set it themselves, for unauthenticated root. Here's how to check, patch, and lock it down.
-
Adobe ColdFusion has been getting popped the same ways for 15 years
The KEV catalog holds a long run of ColdFusion bugs: deserialization RCEs, access-control bypasses, and file uploads, from 2013 to 2024. Different CVEs, same handful of weaknesses. If you still run internet-facing ColdFusion, you're operating a perennial target.
-
22,000 servers ransomed in days: the CyberPanel control-panel wipeout
Two CVSS-10 pre-auth RCEs in CyberPanel let the PSAUX ransomware crew encrypt roughly 22,000 internet-exposed servers in late October 2024. Hosting control panels run as root and face the internet by design, which is exactly why one bug becomes a fleet-wide event.
One email, every weekday morning.
You're in. Check your inbox.