How do you patch or mitigate CVE-2023-46748 (F5 BIG-IP Configuration Utility SQL Injection)?

What to do first when CVE-2023-46748 affects F5 BIG-IP Configuration Utility

The first job is exposure confirmation, not patch wishful thinking. Identify every BIG-IP instance that exposes the Configuration Utility, confirm whether it is internet reachable, and determine which systems are running the affected component in a production or administrative path. If the vulnerable interface is not needed externally, remove that exposure immediately while you prepare the vendor update or mitigation.

Where the environment is large or mixed, treat this as an asset inventory problem as much as a vulnerability problem. A device that is hidden behind a load balancer, management VLAN, or administrative jump path is still part of the attack surface if the utility can be reached from a place an attacker could touch.

Patch, mitigate, or take it out of service

The required response is straightforward in principle: apply the vendor security update or documented mitigation, then verify that the Configuration Utility is no longer exposed in a way that allows unauthorised access. If a supported mitigation exists but patching is delayed, reduce reachability first, then harden access paths so only the smallest necessary management population can reach the interface.

Edge Device Security Guide is the right operating model here because F5 BIG-IP sits in the class of internet-facing appliances that need strict management exposure control, logging, and an end-of-life plan when remediation is not immediately available. For the vulnerability-management side of the response, the relevant discipline is to track the KEV status, apply the vendor fix, and verify completion rather than assuming a successful deployment from a ticket closure alone.

When the device cannot be patched or safely mitigated, CISA's required action is to discontinue use of the product. In practice that means removing it from service or placing it behind a compensating control set that materially prevents abuse of the vulnerable function, not simply leaving it powered on and hoping it stays quiet.

What to check for after exposure or exploitation

SQL injection on a management utility can expose more than the application itself. Once an attacker can influence backend queries, the next questions are whether administrative data, configuration data, credentials, or session material were reachable through the same path, and whether the device was used as a foothold into adjacent management networks. For a control plane product, the blast radius often matters more than the initial web flaw.

SQL Injection Prevention Guide is useful here because the same failure mode that enables exploitation also defines what you should look for in logs, query patterns, and privilege boundaries. If the interface handled sensitive configuration or authentication state, review whether administrators need password rotation, session invalidation, or key replacement after remediation, especially if there are signs of suspicious access.

If you do find signs of abuse, preserve logs and appliance artefacts before rebooting or reconfiguring the system, because management-plane compromise can erase useful evidence quickly. The practical question is not only whether the CVE was reachable, but whether the attacker used it to alter configuration, create persistence, or pivot through trusted administrative paths.

Risk and Threat Considerations

This flaw is risky because management utilities are high-value targets: they often sit close to trust boundaries, hold privileged configuration, and are reachable from networks that were assumed to be administrative only. SQL injection against that layer can turn a web request into a management-plane compromise, with consequences that extend well beyond the vulnerable page.

Failure mechanism: The injection point can let an attacker manipulate backend queries against the Configuration Utility, which may expose administrative data or enable actions that were never intended through the web interface. If the utility is internet reachable, the exploitable path becomes much easier to find and automate.

Impact: A successful exploit can lead to configuration theft, device tampering, credential exposure, or use of the appliance as a pivot into internal management networks. In environments that rely on BIG-IP for traffic steering or access control, compromise can also create service disruption and broad downstream trust loss.

Practitioner Guidance

What to verify: Confirm the exact BIG-IP estate, not just the obvious production pair. Check whether any appliance exposes the Configuration Utility beyond an approved management path, and verify that the mitigation or update was actually applied on the live device, not merely staged in change control.

Decision rule: If the vulnerable interface cannot be patched immediately, remove internet exposure first; if it still cannot be brought to an acceptable risk level, take the product out of service rather than treating exposure as a temporary exception.

Practitioner takeaway: For management-plane SQL injection, the safest sequence is always exposure reduction, then fix, then compromise review, because a vulnerable administrative interface is a direct trust-boundary problem, not just an application bug.

Related resources from NHI Mgmt Group

• CVE-2023-46748 (F5 BIG-IP Configuration Utility SQL Injection)
• How do you patch or mitigate CVE-2025-53521 (F5 BIG-IP Stack-Based Buffer Overflow)?
• CVE-2023-46747 (F5 BIG-IP Configuration Utility Authentication Bypass)
• How do you patch or mitigate CVE-2024-29824 (Ivanti Endpoint Manager (EPM) SQL Injection)?