Is CVE-2019-5591 (Fortinet FortiOS Default Configuration) being exploited in the wild?

What “being exploited in the wild” means for this CVE

For this issue, the practical question is not whether the flaw exists, but whether defenders should treat it as an active incident driver. CISA’s KEV listing is the operational signal that the vulnerability has credible exploitation evidence, so exposure should be treated as urgent rather than theoretical. For FortiOS appliances, that means checking whether any instance could be reached on the affected network path and whether it is being used in a role that would make LDAP impersonation useful to an attacker.

Because the vulnerability is a default configuration weakness, the first step is to confirm whether the device is deployed in the configuration pattern described by the advisory, not just whether it is patched. On appliance platforms, exploitation often succeeds by abusing trust in internal services or management assumptions, so a device can remain dangerous even when it is not directly internet-facing. That is why CISA KEV status should trigger exposure review, not just ticket creation.

In practice, “exploited in the wild” also changes how you interpret logs and traffic. The presence of active exploitation means you should assume opportunistic scanning, subnet-local abuse, and attempts to impersonate service infrastructure may already be in circulation. For a FortiOS device, that shifts the focus from simple vulnerability awareness to whether the appliance could have been used as a stepping stone for credential interception or downstream access.

Why the FortiOS default configuration is operationally risky

The vulnerability matters because it targets a trust boundary inside the network, not only a software defect on the appliance itself. A default configuration issue can let an unauthenticated attacker on the same subnet impersonate an LDAP server and intercept sensitive information, which means the abuse path depends on internal placement, local trust, and how the device participates in authentication or directory lookups. That makes the risk especially relevant in segmented-but-not-strictly-controlled environments.

In security terms, this is the sort of flaw that can turn a network appliance into a credential interception point. If a device accepts or initiates directory-related traffic without sufficiently strict validation, an attacker who can position themselves on the same subnet may be able to influence where sensitive data goes. The issue is therefore not only exploitation of the appliance, but abuse of the appliance’s role in the broader authentication path.

That is why default configuration weaknesses on edge devices deserve the same attention as classic remote code execution in many environments. An attacker does not always need full device compromise to create serious exposure. If the trust relationship itself can be impersonated, the resulting impact can include secret capture, session follow-on activity, or misuse of any credentials that traverse the path.

What defenders should do before and after patching

Start by inventorying every FortiOS instance and verifying whether it is reachable from any subnet where an untrusted or semi-trusted actor could place traffic. Then confirm whether the configuration matches the vulnerable pattern described by Fortinet and whether any LDAP-related traffic, routing, or management dependencies could expose sensitive information if impersonated. Edge Device Security Guide is the most relevant internal starting point for management exposure, device hardening, and logging minimums on this class of appliance.

If patching or configuration change cannot happen immediately, reduce the blast radius around the appliance. Restrict subnet-level reachability, remove any unnecessary dependence on directory services from the vulnerable path, and increase monitoring for unusual LDAP-related behavior or unexpected upstream endpoints. When the device is acting as a trust broker, even a temporary exposure window can be enough for an attacker to capture information that is useful elsewhere in the environment.

After remediation, verify the device is no longer presenting the exploitable behavior and that any dependent service accounts, cached sessions, or exposed credentials have been reviewed for reuse. For this kind of flaw, post-fix validation matters as much as the patch itself because the real risk is often what the appliance may have disclosed before you closed the hole. If evidence suggests the device handled sensitive authentication traffic during the exposure window, credential rotation and compromise assessment should be part of closure, not an optional extra.

Risk and Threat Considerations

This vulnerability combines active exploitation with a trust-abuse path, which makes it more dangerous than a routine configuration bug. The main risk is not only direct device exposure, but the possibility that an attacker on the same subnet can impersonate a directory service and intercept information that administrators assumed was going to a trusted endpoint.

Failure mechanism: The device accepts or participates in a configuration flow that can be abused by a local attacker, allowing impersonation of LDAP infrastructure and interception of sensitive data before defenders notice abnormal behavior.

Impact: Attackers may capture credentials or other sensitive information, then reuse that access for lateral movement, privilege escalation, or follow-on compromise inside the environment.

Practitioner Guidance

What to prioritise: Treat any exposed FortiOS appliance as a candidate for urgent review if it sits on a subnet where an attacker could plausibly establish local network presence. The practical question is whether the device can still be trusted to mediate directory-related traffic safely, not just whether it is technically vulnerable.

What to verify: Confirm the exact configuration pattern called out by the vendor advisory and compare it with observed traffic, especially any LDAP dependencies, management-plane reachability, or unusual authentication flows. If the appliance has been operating in that role, verify whether logs and telemetry are sufficient to rule out interception or impersonation attempts.

Decision rule: If the device may have handled sensitive authentication-related traffic while exposed, prioritise compromise assessment and credential review alongside remediation. If you cannot establish that the appliance was isolated from risky subnet conditions, treat the environment as potentially affected until proven otherwise.

Practitioner takeaway: For a KEV-listed configuration flaw on a network appliance, the right response is exposure confirmation plus trust-path review, because the most important question is often what the device may already have disclosed.

Related resources from NHI Mgmt Group

• CVE-2019-5591 (Fortinet FortiOS Default Configuration)
• Is CVE-2023-27997 (Fortinet FortiOS and FortiProxy SSL-VPN Heap-Based Buffer Overflow) being exploited in the wild?
• Is CVE-2020-12812 (Fortinet FortiOS SSL VPN Improper Authentication) being exploited in the wild?
• Is CVE-2018-13379 (Fortinet FortiOS SSL VPN Path Traversal) being exploited in the wild?