CVE-2020-5902: F5 BIG-IP TMUI unauthenticated remote code execution
The short version: F5 BIG-IP's Traffic Management User Interface (TMUI) — the web configuration utility — has a path-traversal flaw (CVE-2020-5902) that lets an unauthenticated attacker reach undisclosed pages and execute commands on the appliance. It scores 9.8, it's in CISA's KEV catalog, and it was exploited at scale within days of disclosure. If your management interface is internet-facing, treat it as patch-and-verify. Steady hands — but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — in practice and on paper |
| CVSS v3.1 (NVD) | 9.8 — Critical · AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| EPSS | ~99.99% · 100th percentile (2026-07-17) |
| In CISA KEV? | Yes — remediation was due 2022-05-03 |
| Known exploited? | Yes — mass exploitation began within days of the June 2020 disclosure |
| Vulnerability type | CWE-22 path traversal → unauthenticated remote code execution |
| Requires authenticated session? | No — pre-authentication |
| Affected | BIG-IP (TMUI): 11.6.1–11.6.5.1, 12.1.0–12.1.5.1, 13.1.0–13.1.3.3, 14.1.0–14.1.2.5, 15.0.0–15.1.0.3 |
| Fixed in | 11.6.5.2 · 12.1.5.2 · 13.1.3.4 · 14.1.2.6 · 15.1.0.4 |
What you need to know
TMUI is the web-based configuration utility on F5 BIG-IP. CVE-2020-5902 is a directory-traversal flaw in undisclosed TMUI pages: by crafting a request that walks outside the intended path, an unauthenticated attacker reaches functionality that lets them read files and execute commands on the appliance.
That's the whole game. No credential, no chain — a single request to an exposed management interface yields code execution on a device that sits at the center of your application delivery.
- It's the appliance's control plane. BIG-IP fronts application traffic and often carries administrative reach; code execution on it is a deep foothold, not a nuisance.
- It's pre-authentication and trivially reachable whenever TMUI is exposed to the internet — which F5's own guidance says it never should be.
- It was live immediately. Public exploits appeared within days and CISA documented threat-actor exploitation against government and commercial targets, so an exposed appliance may have been touched long ago.
How serious we see it
High — the 9.8 is not hyperbole here.
Unauthenticated, network-reachable code execution on a security-relevant appliance, confirmed exploited at scale, is the definition of top-of-queue. The bounded, reassuring part is that it's narrow and fixable: it affects specific BIG-IP branches, the fixes are long published, and exposure is quick to determine. The catch is the same as any widely exploited pre-patch flaw — being patched and being clean are separate questions on a device that has been a target since 2020.
Recommendations
Straight from F5's advisory (K52145254) and CISA:
- Patch now. Upgrade to 11.6.5.2 / 12.1.5.2 / 13.1.3.4 / 14.1.2.6 / 15.1.0.4 or later.
- Get TMUI off the public internet. Restrict the management interface to a trusted management network or VPN — F5's standing guidance.
- Hunt for prior use. Given how long this has been exploited, review the appliance for signs of compromise and webshells before assuming a clean patch.
- If you find indicators, respond fully. Rebuild the appliance and rotate all credentials, keys, and certificates it held.
- Confirm your exposure first. Verify whether any BIG-IP TMUI is reachable from the internet at all, and which version.
How BreachRisk sees it
BreachRisk starts from the outside, the way an attacker does. From little more than your domain it discovers internet-facing BIG-IP login and TMUI interfaces, fingerprints the version, and flags exposure tied to KEV-listed, actively exploited flaws like this one — pushed to the top of your results because it's in KEV. Where authorized, it goes a step further than a scanner and safely performs a bounded, non-disruptive check to confirm whether the traversal actually succeeds, turning "this looks like a vulnerable BIG-IP" into a verified finding.
That continuous, attacker's-eye view is the whole point: when a device this exposed carries a flaw this old and this exploited, you want it already mapped and ranked, not buried in a scanner backlog.