CVE-2021-22991

What it actually does

CVE-2021-22991 is a memory corruption vulnerability in F5 BIG-IP Traffic Management Microkernel (TMM) URI normalization. A specially crafted request sent to a BIG-IP virtual server can be incorrectly normalized, triggering a buffer overflow in TMM. The primary confirmed impact is unauthenticated, network-reachable denial of service through TMM crash or restart, disrupting traffic handled by affected virtual servers. F5 also noted that, in certain situations, the flaw may theoretically allow bypass of URL-based access controls or remote code execution, which is reflected in the critical CVSS score and CISA Known Exploited Vulnerabilities listing.

Why it matters to the business

Successful exploitation can interrupt applications and network services fronted by BIG-IP, including load balancing, access management, web application firewalling, DNS/GTM, SSL orchestration, and related traffic-management functions. Because the vulnerability is remotely reachable without authentication, has high EPSS likelihood, is listed in CISA KEV, and has been exploited in the wild, exposed BIG-IP virtual servers should be treated as urgent remediation targets. The CISA remediation deadline of 2022-02-01 has long passed, so continued exposure represents a significant operational and compliance risk.

How an attack unfolds

An attacker identifies an internet-facing or otherwise reachable BIG-IP virtual server running a vulnerable version. The attacker sends a crafted HTTP request that exercises the vulnerable URI normalization logic inside TMM. When TMM mishandles the request, memory corruption occurs and the TMM process may crash, reset, or fail over, causing a denial of service for traffic passing through the affected virtual server. In environments where vulnerable URL-based access-control logic is in use, the same normalization weakness may allow protected paths to be interpreted differently than intended. F5 also described remote code execution as theoretically possible in certain conditions, so exploitation should not be treated as only a nuisance outage risk.

How to fix it

Upgrade BIG-IP to a fixed release: 16.0.x to 16.0.1.1 or later; 15.1.x to 15.1.2.1 or later; 14.1.x to 14.1.4 or later; 13.1.x to 13.1.3.6 or later; and 12.1.x to 12.1.5.3 or later. Versions that have reached End of Software Development were not evaluated by F5 and should be upgraded to a supported branch rather than assumed safe. Prioritize systems with internet-facing virtual servers, URL-based access controls, access policy enforcement, WAF/ASM/Advanced WAF, DNS/GTM, SSL Orchestrator, or high-availability traffic roles. Where immediate upgrade is not possible, reduce exposure by limiting access to affected virtual servers, placing upstream filtering in front of critical services, blocking suspicious malformed URI traffic at perimeter controls where feasible, and ensuring HA/failover capacity is stable; these mitigations reduce risk but do not replace patching.

How to confirm the fix worked

Confirm the running BIG-IP software version and hotfix level on every device and compare it against the fixed versions. Validate that all active and standby HA members are upgraded, not only the currently active unit. Inventory virtual servers and confirm that no vulnerable BIG-IP instance continues to process untrusted traffic. After upgrade, verify TMM stability under normal traffic, confirm no new TMM core files are being generated, and review system logs for crash or restart events. Vulnerability scanners should be used carefully against production BIG-IP devices because aggressive probes may trigger instability on vulnerable systems.

Typical attack path

1. Discover BIG-IP virtual servers exposed to the internet or reachable from a compromised network segment.
2. Fingerprint the BIG-IP version or infer vulnerability from service behavior, banners, TLS metadata, error pages, or management disclosures.
3. Send crafted requests to a virtual server that trigger the vulnerable TMM URI normalization path.
4. Cause TMM memory corruption, resulting in process crash, traffic disruption, reset, or device failover.
5. Optionally repeat requests to sustain denial of service or test whether URL-based access controls can be bypassed.
6. If a crash occurred, attempt to exploit operational instability, failover behavior, or degraded security controls during recovery.

How to detect it

Review BIG-IP logs and host artifacts for evidence of exploitation or probing, especially around unexplained application outages, virtual-server resets, HA failovers, or TMM restarts. Primary sources include /var/log/ltm, /var/log/tmm, /var/log/tmm.*, /var/log/messages, /var/log/audit, qkview outputs, HA/failover logs, upstream reverse proxy logs, WAF logs, NetFlow, packet captures, and SIEM telemetry from perimeter devices. Look for TMM segmentation faults, panic messages, assert failures, core dump creation, watchdog restarts, failover events, and clusters of malformed HTTP requests immediately before those events. Because F5 did not publicly disclose a stable exploit request pattern, detection should correlate abnormal URI normalization inputs, encoded or overlong URL paths, repeated requests to a virtual server, and subsequent TMM instability rather than rely on a single request signature. If exploitation is suspected, preserve logs, core files, qkview data, configuration snapshots, and packet captures before rebooting or cleaning up the device.

• /var/log/ltm
• /var/log/tmm
• /var/log/tmm.*
• /var/log/messages
• /shared/core
• /shared/core/tmm
• /var/core
• tmm crash
• TMM crash
• tmm.*segmentation fault
• segmentation fault
• SIGSEGV
• panic
• assert
• core dumped
• emerg logger: Re-starting tmm
• bigstart restart tmm
• Traffic Management Microkernel
• sod.*failover
• 01010029
• 01010221

What your security team should do

• Treat this as urgent for any exposed BIG-IP virtual server because it is in CISA KEV, has active in-the-wild exploitation, and has a high EPSS score.
• Patch or upgrade all affected BIG-IP branches to the fixed versions, including standby HA peers and disaster-recovery appliances.
• Prioritize internet-facing traffic-management devices and devices enforcing URL-based access policies.
• If systems are end-of-life or end-of-software-development, migrate them to a supported BIG-IP release rather than relying on compensating controls.
• Search historical BIG-IP logs and core dump directories for TMM crashes, restarts, failovers, and malformed URI request patterns around service disruption windows.
• Monitor for repeated requests from the same source followed by TMM crash, failover, or traffic interruption events.
• Limit network reachability to virtual servers where business requirements allow, especially from untrusted networks.
• Ensure incident response plans include BIG-IP HA failover validation, configuration backup, and forensic preservation of logs and core files before cleanup.