F5 CVE-2023-46747: the backend trusted a header that said 'I'm already an admin'

The root cause of CVE-2023-46747 is a trust assumption that shows up in a lot of architectures: a backend application server trusted an HTTP header as proof that the front-end had already authenticated the user. In F5 BIG-IP’s Traffic Management User Interface, the Tomcat backend treated headers like remote_user and REMOTEROLE as authoritative, on the assumption that only the front-end Apache proxy could ever set them. Praetorian’s researchers broke that assumption with HTTP-to-AJP request smuggling: Apache and Tomcat disagree about where one request ends and the next begins, so an attacker smuggles a second request straight to the backend with those headers set to “authenticated administrator.” Unauthenticated attacker in, root command execution out. CVSS 9.8.

This is a runbook. F5 BIG-IP sits in front of critical applications and a compromise is root on the device, so work this top to bottom.

What the bug is

CVE-2023-46747 is an authentication bypass (CWE-288) in the BIG-IP Configuration utility (TMUI), reachable by an unauthenticated attacker with network access to the management port or self IP addresses. It chains with CVE-2023-46748, an authenticated SQL injection, to reach full remote code execution; the smuggling bug provides the authentication, the SQLi provides the code execution. Affected versions span BIG-IP 13.1.0 through 17.1.1 across most modules (LTM, APM, AFM, ASM/WAF, and others). CISA added it to the Known Exploited Vulnerabilities catalog on October 31, 2023, with a November 21 deadline and the ransomware flag, and a public PoC appeared within days of disclosure.

Step 1 — Find your BIG-IP devices and check exposure

• Inventory every BIG-IP appliance and VE instance, with its software version. Vulnerable ranges: 13.1.0–13.1.5, 14.1.0–14.1.5, 15.1.0–15.1.10, 16.1.0–16.1.4, 17.1.0–17.1.1.
• For each, determine whether the TMUI / management interface is reachable from anything other than a dedicated management network. Check the management port and every self IP that has the config utility enabled.
• Treat any internet-reachable TMUI as a five-alarm finding. F5 has said for years that the management interface should never be exposed to the public internet, and this CVE is why.

Step 2 — Patch

• Upgrade to a fixed release and apply F5’s engineering hotfix for your branch, per F5 article K000137353. The fixes address both CVE-2023-46747 and the paired CVE-2023-46748, so patch them together.
• Reboot/confirm the device comes back healthy and traffic-management functions are unaffected (the data plane and the management plane are separate, but verify).

Step 3 — Apply F5’s mitigation if you can’t patch immediately

• F5 published mitigation guidance for the config utility. The durable mitigation is the same as the long-standing best practice: restrict TMUI to the management network only. Block access to the configuration utility from self IPs and untrusted networks until you can patch.
• This is a stopgap. The request-smuggling bypass works against anything that can reach TMUI, so the only safe posture is “almost nothing can reach TMUI.”

Step 4 — Determine whether you were already compromised

A public PoC and active exploitation followed disclosure quickly, and successful exploitation means root on the device. If your TMUI was reachable and unpatched, investigate before trusting the box.

• Check TMUI/httpd access logs for the request-smuggling signature: anomalous requests to TMUI endpoints (the login and SOAP/tmui paths) with unusual Content-Length/Transfer-Encoding combinations, and requests that reached authenticated functionality without a preceding successful login.
• Look for unexpected command execution on the device, new local accounts, modified configurations, and webshells.
• F5 published indicators of compromise and a detection script in their advisory; run it against the device.

Step 5 — If compromised, treat it as a root-level appliance breach

• A BIG-IP compromise is serious because of where the device sits. It can see and often terminate TLS for the applications behind it, so assume the attacker had visibility into traffic and credentials passing through.
• Rebuild the device from a known-good image rather than cleaning in place. Rotate device credentials, the management accounts, any SSL keys and certificates stored on the BIG-IP, and credentials for the applications it fronts.
• Review configurations for tampering, including iRules, which can be abused for persistence.

The general lesson

Carry this past F5: a header is not authentication. Any time a backend trusts a header (remote_user, X-Forwarded-User, a role claim) as proof that an upstream component authenticated the request, the security of the whole system depends on it being impossible for an attacker to reach the backend directly or to smuggle a request past the front-end. Request smuggling, SSRF, and misconfigured proxies all break that “impossible.” The robust pattern is for the backend to verify authentication itself, or to use a signed, verifiable token rather than a plaintext header that’s only protected by network topology.

For these specific CVEs, the actions are clear and overdue: patch BIG-IP to a fixed hotfix, get TMUI off any network it doesn’t need to be on, and if you ran an exposed unpatched device, investigate it as a potential root compromise. We flag the management-plane bugs on infrastructure like this the day they land, because the device that fronts your applications is exactly the one you can’t afford to have answering to strangers.

Sources

• CISA Known Exploited Vulnerabilities Catalog
• NVD CVE-2023-46747 — 2023-10-26
• F5 Security Advisory K000137353 — 2023-10
• Praetorian: Compromising F5 BIG-IP with request smuggling (CVE-2023-46747) — 2023-10
• ProjectDiscovery: F5 BIG-IP unauthenticated RCE via AJP smuggling — 2023-10
• Tenable: CVE-2023-46747 critical authentication bypass in F5 BIG-IP — 2023-10