The 'test connection' button that mails your stored credentials to an attacker
CVE-2018-13374 lets an attacker recover the LDAP bind credentials stored in a FortiGate by pointing its LDAP connectivity test at a rogue server. It's a small bug with a broad lesson: 'test connection' features that transmit stored secrets are a credential-disclosure pattern.
Almost every appliance that integrates with Active Directory has a “test connection” button next to the LDAP settings. You fill in the server, the bind account, the password, and click test to confirm it works. CVE-2018-13374 is what happens when that convenience leaks. The flaw, an improper access control issue (CWE-732) in Fortinet FortiOS and FortiADC, lets an attacker recover the LDAP server credentials configured in a FortiGate by redirecting the device’s LDAP connectivity test to a rogue LDAP server they control. The device dutifully connects to the attacker’s server and presents the stored bind credentials, handing them over. CISA added it to the Known Exploited Vulnerabilities catalog on September 8, 2022, with the ransomware flag.
What the bug is and why it matters more than it looks
On paper this is a modest information disclosure, not an RCE. In practice it’s a credential-theft bug aimed at one of the most valuable credentials an organization has: the service account a firewall uses to bind to Active Directory. That account exists to query the directory, so it has standing read access to AD, and in plenty of deployments it’s over-privileged beyond what’s strictly needed. Recover it, and an attacker has authenticated access to the directory, a foothold for enumeration, and a credential to reuse elsewhere. A “minor” disclosure on the perimeter device becomes a step toward the domain.
The mechanism is the part worth generalizing. The attacker doesn’t break encryption or dump memory; they exploit the fact that the test feature actively transmits the stored secret to whatever server it’s told to contact. If the attacker can influence the test target (here, via the access-control flaw), the credential walks out the door by design.
The pattern: connectivity tests that send secrets
This anti-pattern recurs across products well beyond Fortinet. Anywhere an admin UI lets you “test” an integration, LDAP, SMTP, a database connection, an API webhook, by having the device connect outward using stored credentials, there’s a latent risk: if an attacker can change where the test connects, or trigger it against a server they control, the stored secret is disclosed. It’s the credential-theft equivalent of an SSRF, and it’s easy to overlook because the feature is doing exactly what it was built to do.
The defensive principle for builders is to never transmit a stored secret to a destination the requester controls without re-authenticating the request and validating the target. For defenders consuming these products, the principle is to assume any credential a device can “test” is a credential a bug might leak, and to scope and protect those credentials accordingly.
What to do
- Patch FortiOS/FortiADC to a fixed version. This closes the access-control flaw. Given it’s KEV-listed, treat it on the same urgency as other Fortinet management-plane bugs.
- Rotate the LDAP bind credential if you ran an exposed, unpatched device. If an attacker could reach the management interface, assume the configured LDAP credential may have leaked, and rotate it.
- Least-privilege the directory service account. The firewall’s AD bind account should have only the read access it genuinely needs, never domain admin or broad write rights. This limits what a leaked credential is worth. Consider a dedicated, tightly-scoped account used nowhere else.
- Keep the management interface off the internet. As with every appliance management-plane bug, restricting who can reach the admin UI defuses the attack path.
- Audit “test connection” features across your stack. Treat integration credentials (LDAP, SMTP, SQL, API) as disclosable, monitor for their use from unexpected sources, and scope them minimally.
The reframe is to widen the definition of attack surface to include the helpful features. A connectivity test is a small, friendly button that exists to make setup easier, and CVE-2018-13374 is the reminder that it’s also a mechanism for moving a stored credential to wherever it’s pointed. Patch the bug, rotate and scope the credential it targets, and look at your own products’ test features with the same suspicion. We flag the credential-disclosure entries even when they’re “only” information disclosure, because the information in question is often the key to the directory.
Sources
Share
Related field notes
-
They read one file off the VPN gateway and left with your whole Active Directory
CVE-2024-24919 is filed as 'information disclosure.' On a Check Point gateway that meant unauthenticated file read, which meant password hashes, which meant ntds.dit within hours. It was a zero-day for a month before disclosure, and patching it doesn't undo the theft.
-
FortiClient EMS CVE-2023-48788: a SQL injection that talks the database into running SYSTEM commands
When a product runs on Microsoft SQL Server, a SQL injection is rarely just a data leak. The attacker turns on xp_cmdshell from inside the injection and gets OS command execution. On FortiClient EMS that's unauthenticated, as SYSTEM. Here's how to check, patch, and detect it.
-
Fortinet's other products take their turn: FortiWeb, FortiManager, FortiClient EMS
Beyond the long-running FortiOS auth-bypass cycle, 2025-2026 brought a wave of exploited bugs in FortiWeb, FortiManager, and FortiClient EMS, SQL injection, path traversal, auth bypass, and a format-string RCE. Same vendor, same perimeter-and-management target profile.
One email, every weekday morning.
You're in. Check your inbox.