F5 BIG-IP CVE-2026-40435

Exploitation requires that IP-based access restrictions be configured on the BIG-IP httpd instance (not a default-empty configuration). The attacker must identify an endpoint that is NOT covered by the IP filter - this is the critical condition. The httpd service must be network-accessible (default). No authentication is required, and the attacker's IP address must be in the blocked range. Exploitation is limited to information disclosure (low confidentiality impact); no code execution or integrity compromise is possible via this vector. The attack does not require user interaction or advanced network positioning.

CVSS 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) indicates network-accessible, unauthenticated exploitation with low attack complexity, but limited to confidentiality impact with no integrity or availability consequences. EPSS data is not provided, but the combination of network vector and low complexity suggests moderate real-world exploitation probability. The vulnerability does not appear in CISA KEV at time of analysis, indicating no confirmed active exploitation at scale. However, the attack surface is significant: F5 BIG-IP is widely deployed as a load balancer and application delivery controller in enterprise environments, making it an attractive target. The practical risk depends critically on deployment context - organizations using IP-based restrictions as a primary security boundary (instead of layered controls) face elevated risk. No POC availability is documented, but the vulnerability is straightforward to verify: an attacker simply attempts to access known administrative or protected endpoints from a blocked IP address. The low complexity and lack of user interaction suggest this would be relatively easy to exploit once an unpatched instance is identified.

An attacker's IP address is blocked by organization policy (e.g., via IP allowlist). The attacker scans BIG-IP for endpoints that bypass the IP filter - for example, a status or health-check endpoint that lacks access control. The attacker sends an HTTP request to that endpoint from their blocked address and successfully receives a response containing sensitive information (e.g., configuration details, version strings, or internal metrics), confirming the filter was not applied. The attacker can now enumerate unprotected endpoints and extract information to inform further attacks.