F5 Big-IP WebSafe 12.0.0

In F5 BIG-IP LTM, AAM, AFM, Analytics, APM, ASM, DNS, GTM, Link Controller, PEM, and WebSafe 11.5.1 HF6 through 11.5.4 HF4, 11.6.0 through 11.6.1 HF1, and 12.0.0 through 12.1.2 on VIPRION platforms only, the script which synchronizes SafeNet External Network HSM configuration elements between blades in a clustered deployment will log the HSM partition password in cleartext to the "/var/log/ltm" log file.

Published: 2017-10-20T15:00:00.000Z
Updated: 2024-08-05T15:18:49.774Z

In F5 BIG-IP LTM, AAM, AFM, Analytics, APM, ASM, DNS, GTM, Link Controller, PEM and Websafe software version 12.0.0 to 12.1.1, 11.6.0 to 11.6.1, 11.5.0 - 11.5.4, virtual servers with a configuration using the HTTP Explicit Proxy functionality and/or SOCKS profile are vulnerable to an unauthenticated, remote attack that allows modification of BIG-IP system configuration, extraction of sensitive system files, and/or possible remote command execution on the BIG-IP system.

Published: 2017-10-27T14:00:00.000Z
Updated: 2024-09-17T03:22:54.063Z

In F5 BIG-IP LTM, AAM, AFM, Analytics, APM, ASM, DNS, Edge Gateway, GTM, Link Controller, PEM, PSM, WebAccelerator, and WebSafe 11.6.1 HF1, 12.0.0 HF3, 12.0.0 HF4, and 12.1.0 through 12.1.2, undisclosed traffic patterns received while software SYN cookie protection is engaged may cause a disruption of service to the Traffic Management Microkernel (TMM) on specific platforms and configurations.

Published: 2017-05-09T15:00:00.000Z
Updated: 2024-08-05T15:18:49.793Z

In some circumstances, an F5 BIG-IP version 12.0.0 to 12.1.2 and 13.0.0 Azure cloud instance may contain a default administrative password which could be used to remotely log into the BIG-IP system. The impacted administrative account is the Azure instance administrative user that was created at deployment. The root and admin accounts are not vulnerable. An attacker may be able to remotely access the BIG-IP host via SSH.

Published: 2017-05-23T15:00:00.000Z
Updated: 2024-08-05T15:18:49.911Z

In F5 BIG-IP 12.1.0 through 12.1.2, permissions enforced by iControl can lag behind the actual permissions assigned to a user if the role_map is not reloaded between the time the permissions are changed and the time of the user's next request. This is a race condition that occurs rarely in normal usage; the typical period in which this is possible is limited to at most a few seconds after the permission change.

Published: 2017-05-09T15:00:00.000Z
Updated: 2024-08-06T02:42:11.288Z