Is CVE-2018-13374 (Fortinet FortiOS and FortiADC Improper Access Control) being exploited in the wild?

Yes. CISA added CVE-2018-13374 to its Known Exploited Vulnerabilities catalogue on 8 September 2022, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Fortinet FortiOS and FortiADC contain an improper access control vulnerability that allows attackers to obtain the LDAP server login credentials configured in FortiGate by pointing a LDAP server connectivity test request to a rogue LDAP server.

What makes this a real-world exploitation case, not just a published flaw?

CVE-2018-13374 is the kind of vulnerability that moves from “theoretical” to “operational” once it appears in KEV. CISA’s KEV listing means defenders should treat it as actively exploited, not merely disclosed. For edge appliances, the practical question is not whether the issue exists, but whether the exposed device, management plane, or adjacent credential path is still reachable and trustworthy.

For readers managing internet-facing appliances, the most relevant distinction is between software presence and exposure. A FortiOS or FortiADC deployment may be vulnerable even if the business has not observed obvious abuse, because attackers often target the management or diagnostic path that reveals secrets rather than the main data path. The issue becomes materially more serious when that appliance is trusted by other systems for authentication or directory access.

That is why an appliance flaw of this kind belongs in the same operational bucket as other exploited perimeter-device weaknesses. NHIMG’s Edge Device Security Guide is useful here because the real control problem is not only patching, but also understanding management exposure, appliance credentials and minimum logging expectations for devices that sit at the network edge.

Why the LDAP credential exposure matters more than the CVE label

The key security consequence in the direct answer is credential disclosure. If an attacker can steer a connectivity test request to a rogue LDAP server, the appliance may reveal the LDAP login credentials configured in FortiGate. That turns a product flaw into a broader access problem, because those credentials may be reused elsewhere or may open a path into directory-backed administration and application access.

This is a classic example of why an “improper access control” issue can become a secret-exposure issue. The vulnerability is not just about unauthorized reading of a value on the appliance, it is about what the revealed secret can authenticate to after it leaves the device. If the same directory credentials protect admin functions, remote access, or other integrated services, the blast radius extends beyond the firewall or ADC itself.

For practitioners, that means the relevant question is whether the appliance stores or uses high-value directory credentials and whether those credentials have been exposed to an untrusted endpoint. Once that happens, incident response must treat the appliance as a source of compromised trust, not just as a software patching task. Related guidance in NHIMG’s Zero-Day and Exploited Vulnerabilities Guide and Vulnerability Management Guide maps well to the KEV workflow: confirm exposure, prioritise by exploitability, and verify that mitigation actually reduced risk.

What to do when patching is delayed or you suspect exposure

If you cannot patch immediately, the priority is to reduce the attack surface and assume credential exposure may already have occurred. That usually means isolating management access, validating whether the appliance can still reach external LDAP endpoints, and reviewing whether the configuration allows a connectivity test to be directed anywhere other than the intended directory service. The safest response is to remove trust from any credential or session that may have passed through that path.

When patching is delayed, investigation should not stop at the appliance. Look for signs that the LDAP credentials were used outside their normal pattern, including unexpected directory binds, unusual admin logins, new access paths from the appliance subnet, and any privilege changes that would indicate follow-on use. If the exposed credential can authenticate to more than one system, rotate it broadly and invalidate dependent sessions where possible.

Because this issue concerns exposed secrets on an edge device, the most useful related control questions are: who owns the appliance, who can change its directory settings, and what evidence proves the credential was rotated after exposure. NHIMG’s IAM and IGA Basics and Authorisation Models Guide are the best internal references for understanding why this kind of credential exposure quickly becomes an authorization problem across multiple systems.

Risk and Threat Considerations

Edge appliances are attractive targets because they sit in trusted positions and often hold credentials that can unlock directory-backed access. Once a flaw can leak those credentials, an attacker does not need to defeat the rest of the environment immediately, they can reuse the exposed secret to blend in as a legitimate directory user or pivot into adjacent systems.

Failure mechanism: A malicious or misdirected connectivity test sends appliance-managed LDAP authentication material to an attacker-controlled server, which captures credentials that the device intended to send to a trusted directory endpoint.

Impact: The exposed credentials may enable unauthorized access, privilege escalation, lateral movement, or ransomware staging if they are valid beyond the appliance itself.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes rapid identification and prioritisation essential for this CVE.
Recommendation — Prioritise and remediate KEV-listed flaws first, then verify exposure across all edge appliances.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This CVE needs exposure confirmation and rapid exploitability triage.
	IA-5 — Authenticator Management	The flaw can expose LDAP credentials that must be rotated and invalidated.
Recommendation — Scan for vulnerable Fortinet appliances and track remediation status until confirmed closed. Rotate exposed LDAP credentials and revoke any sessions or authenticators they may have enabled.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	The KEV-listed flaw requires formal vulnerability handling and verification.
Recommendation — Process the CVE through vulnerability management, with verification that the exposure is removed.
OWASP ASVS	V8 — Authorization	The vulnerability is an access-control failure that can expose credentials and enable unauthorized access.
Recommendation — Enforce server-side authorization checks on configuration and diagnostic functions that can reveal secrets.

Practitioner Guidance

What to verify: Confirm whether any FortiOS or FortiADC instance still permits directory connectivity tests to untrusted destinations, and verify whether the configured LDAP credential has been rotated since the KEV listing date. If the appliance was reachable from the internet or a semi-trusted network, assume the test path deserves immediate scrutiny.

Decision rule: If the appliance could have exposed reusable directory credentials, treat credential rotation and dependent session review as urgent, even before you finish proving active abuse. If the credentials were scoped narrowly and never reused, the incident may stay contained to the device, but you still need to prove that containment rather than assume it.

Practitioner takeaway: For exploited appliance flaws, the most important judgement is to validate the secret path first, because the real incident often begins when a management function leaks trust credentials rather than when the original CVE is scanned.