Is CVE-2024-23113 (Fortinet Multiple Products Format String) being exploited in the wild?

What makes CVE-2024-23113 a credible active-exploitation issue?

CISA’s KEV listing is the practical signal that matters here: it means the vulnerability has crossed from theoretical exposure into a confirmed exploitation problem. For operators, that changes the priority from routine backlog handling to immediate exposure review, because internet-facing appliance flaws are often abused before defenders finish normal change windows.

For edge and security appliances, the first question is not whether the product is deployed somewhere in the estate, but whether it is reachable in a way an attacker can influence. If the vulnerable Fortinet components are exposed externally or reachable from untrusted networks, the exploitation risk is materially higher and the remediation clock should be treated as urgent.

When a flaw allows remote, unauthenticated code or command execution, the security boundary is the management or service interface itself. That makes it a high-value target for opportunistic scanning, exploitation-at-scale, and follow-on compromise such as configuration tampering, credential capture, or pivoting into internal networks.

What should you verify before treating it as contained?

Start with asset confirmation: identify every FortiOS, FortiPAM, FortiProxy, and FortiWeb instance and determine where they sit in the network path. Inventory is only useful if it includes management exposure, internet reachability, and whether the device is acting as a choke point for authentication, proxying, or administrative access.

If the product is in scope, verify whether the environment has already been touched. For KEV-listed flaws, defenders should look for unusual administrative actions, new local accounts, configuration changes, unexpected outbound connections, crash or error patterns around the vulnerable service, and any evidence that the device was used as an initial foothold rather than just as a vulnerable endpoint.

Because these devices often mediate access for many users or services, compromise can have an outsized blast radius. A successful exploit may not stay local to the appliance, so checking logs, session history, and connected systems is part of confirming whether exposure stayed theoretical or became an incident.

How should remediation and containment be handled when patching is delayed?

Use the vendor advisory and the CISA KEV catalogue for version-specific instructions, then apply the fix or mitigation that the vendor recommends without waiting for routine maintenance windows. For appliances that cannot be patched immediately, the priority is reducing reachability, restricting administrative paths, and disabling any unnecessary exposed interfaces or services.

If there is any chance the vulnerable system handled credentials, sessions, or privileged administrative traffic, rotate what it may have exposed. That can include admin passwords, API tokens, certificates, and service credentials that were stored on or passed through the device, especially where the appliance sits in front of privileged access or remote support functions.

Security teams should also plan for compensating controls that buy time without creating false confidence. Network segmentation, temporary access restrictions, and close monitoring can reduce exposure, but they do not remove the need to patch a KEV-listed issue that already has reliable exploitation evidence.

Risk and Threat Considerations

Actively exploited appliance vulnerabilities are attractive because they combine reach, trust, and speed. A remotely reachable format string flaw can give an attacker a direct path to code execution before defenders have time to test, schedule, and roll out a fix, especially on devices that are difficult to monitor as closely as servers or endpoints.

Failure mechanism: The attacker sends crafted requests to trigger memory corruption or command execution through the vulnerable service, then uses the appliance’s privileged position to persist, pivot, or manipulate traffic and access paths.

Impact: Compromise can expose administration channels, credentials, internal sessions, and downstream systems that rely on the appliance for secure access or traffic handling. On perimeter devices, a single exploit can become an estate-level incident.

Practitioner Guidance

What to prioritise: Treat the KEV listing as an exposure deadline, not a background indicator. If the device is internet-facing or handles privileged access, move it ahead of routine vulnerability queues.

What to verify: Confirm whether any vulnerable unit is externally reachable, whether vendor mitigation has been applied, and whether logs show abnormal administrative or configuration activity since the KEV date.

Decision rule: If patching cannot happen immediately, reduce exposure first, then rotate any secrets or sessions the appliance could have disclosed, and only then move to deeper compromise analysis.

Practitioner takeaway: With a KEV-listed appliance flaw, the key judgement is not whether exploitation is possible, but whether your environment still gives an attacker a usable path to it.

Related resources from NHI Mgmt Group

• Guide: Edge Device Security Guide
• How do you patch or mitigate CVE-2024-23113 (Fortinet Multiple Products Format String)?
• CVE-2024-23113 (Fortinet Multiple Products Format String)
• Is CVE-2025-59718 (Fortinet Multiple Products Improper Verification of Cryptographic Signature) being exploited in the wild?
• Is CVE-2024-55956 (Cleo Multiple Products Unauthenticated File Upload) being exploited in the wild?