How to Fix CVE-2018-13374: Incorrect Permission Assignment for Critical Resource in Fortinet Fortios, Fortiadc

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

Upgrade the firmware. CISA's Known Exploited Vulnerabilities catalog lists this CVE, which means active exploitation has been confirmed. KEV entry added 2022-09-08, federal due date 2022-09-29. The fix is a FortiOS / FortiADC firmware upgrade per Fortinet advisory FG-IR-18-157, not a package update or a host-level patch.

What is CVE-2018-13374?

CVE-2018-13374 is an improper access control flaw in Fortinet FortiOS (the operating system on FortiGate firewalls) and FortiADC (the application delivery controller). It is classified as CWE-732, incorrect permission assignment for a critical resource. In plain terms: the LDAP server connectivity test that an administrator uses to confirm directory authentication is wired correctly will obediently send the configured LDAP bind credentials to whatever server it is told to talk to. There is no check that the target is actually the configured directory server.

An attacker who can reach the FortiGate or FortiADC administrative interface and trigger that connectivity test points it at a rogue LDAP server they control. The appliance connects out and presents the stored LDAP service-account username and password in the bind. The attacker reads those credentials straight off the wire. Because the bind happens in cleartext unless LDAPS or STARTTLS is enforced, the disclosure is immediate and reliable. This is why the CVSS vector scores confidentiality impact (C:L) but not integrity or availability: the bug leaks a secret, it does not crash or rewrite anything.

The affected builds named in the record are FortiOS 6.0.2, 5.6.7 and earlier, and FortiADC 6.1.0, 6.0.0 to 6.0.1, and 5.4.0 to 5.4.4. The CVSS 3.1 base score is 4.3 (Medium), vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N. Note the PR:L: the attacker needs some level of access to invoke the test, which is why locking down administrative access is a meaningful mitigation here, not just a nice-to-have.

Why this CVE matters

The leaked credential is rarely just a read-only directory account. In a lot of FortiGate deployments the LDAP service account configured for authentication has broad read access to Active Directory, and in poorly scoped setups it can enumerate users, groups, and sometimes more. Once an attacker holds that bind credential, they pivot off the firewall entirely and start working against the directory itself. That is the real damage path: a Medium-scored firewall bug becomes the first domino in a domain compromise.

This CVE sits on CISA's Known Exploited Vulnerabilities catalog, which only happens after active exploitation is observed. If your FortiOS or FortiADC build matches the affected range and the admin interface was reachable from an untrusted network, treat the configured LDAP credentials as exposed. Upgrading the firmware closes the hole, but it does not un-leak a password that an attacker already harvested, so credential rotation is part of the fix, not an optional extra.

Confirm whether you are affected

FortiOS and FortiADC are appliance firmware. There is no Linux package and no Windows installer to query, so ignore any guide that tells you to run dpkg, rpm, yum, or a PowerShell Win32_Product check for this product. You read the firmware version from the device itself.

On a FortiGate, open the CLI (SSH or the GUI console) and run the status command. Compare the build line against the affected range in the table above.

# FortiGate / FortiOS: read the running firmware version
get system status

# The output includes a line like:
#   Version: FortiGate-100E v6.0.2,build0163,...
# If the version is 6.0.2, or any 5.6.7-or-earlier build, you are affected.

# FortiADC: read the running firmware version
get system status        # CLI
# or in the GUI: System > Settings, check the Firmware Version field
# Affected: 6.1.0, 6.0.0–6.0.1, 5.4.0–5.4.4

How to fix CVE-2018-13374

The fix is a firmware upgrade to a build where Fortinet corrected the connectivity-test behaviour, as described in advisory FG-IR-18-157. The advisory is the authoritative source for the exact fixed builds for your platform and major version. Because Fortinet ships fixes across several maintenance branches, the right target depends on the train you run today (for example a 5.6.x device upgrades to a later 5.6.x maintenance build, a 6.0.x device upgrades to a later 6.0.x build). Confirm the named fixed build in FG-IR-18-157 before you start so you do not have to guess.

Download the correct image from the Fortinet support portal (support.fortinet.com), not from any third party. Read the release notes for your model and current build to confirm the supported upgrade path; FortiOS sometimes requires stepping through an intermediate build rather than jumping directly to the target.

FortiGate / FortiOS upgrade

# 1. Record the current version and back up the running config FIRST.
get system status
execute backup config tftp fgt-preupgrade.conf 10.0.0.10

# 2. Upload and install the patched image named in FG-IR-18-157.
#    Via TFTP from the CLI:
execute restore image tftp FGT_6xx-vX.X.X-buildNNNN-FORTINET.out 10.0.0.10
#    The unit validates the image, writes it, and reboots automatically.
#    (You can also push the image through GUI: System > Firmware.)

# 3. After reboot, confirm the running build matches the fixed version.
get system status | grep -i version

For an HA cluster, upgrade through the cluster so FortiOS handles the members in sequence; do not pull individual units unless the release notes tell you to. Have console access ready in case a unit needs recovery.

FortiADC upgrade

# 1. Back up the configuration before touching firmware.
#    GUI: System > Settings > Configuration > Backup
#    CLI: execute backup config

# 2. Install the fixed image from System > Settings (GUI upload),
#    or via the CLI image-restore procedure for your model.
#    Target build = the FortiADC fix named in FG-IR-18-157.

# 3. Verify after reboot.
get system status

Rotate the leaked LDAP credentials (do not skip this)

Firmware alone does not undo a credential that may already be in an attacker's hands. After you upgrade, rotate the LDAP bind account password in your directory, then update it on the FortiGate or FortiADC. While you are there, scope that service account down to the least privilege it needs for authentication lookups.

# On the FortiGate, update the stored LDAP bind password after you have
# changed it in the directory, then re-run a connectivity test from a
# trusted admin session only.
config user ldap
    edit "your-ldap-server"
        set password <new-bind-password>
    next
end
diagnose test authserver ldap "your-ldap-server" <test-user> <test-pass>

If you can't upgrade immediately

An upgrade is the only durable fix. These mitigations cut exposure while the change window is scheduled; they do not remove the vulnerability. Because the attacker needs administrative access to invoke the LDAP test, the most effective short-term control is to make the admin interface unreachable from anywhere it does not belong.

Restrict administrative access (trusted hosts)

# FortiOS: limit every admin account to your management subnet only.
config system admin
    edit "admin"
        set trusthost1 10.0.0.0 255.255.255.0
    next
end

# Remove HTTPS/SSH admin access from any internet- or user-facing interface.
config system interface
    edit "wan1"
        unset allowaccess          # or set to only the services you truly need
    next
end

Enforce LDAPS (LDAP over TLS) on the directory connection so that even if the test is redirected, the bind is not handed over in cleartext to an unauthenticated server. Restrict who holds administrative accounts on the appliance, and review the admin audit log for any connectivity tests aimed at unexpected destinations.

Verify the repair

After the upgrade, re-read the firmware version on the device and confirm it matches the fixed build named in FG-IR-18-157.

# FortiGate / FortiADC: confirm the running build is the fixed one.
get system status | grep -i version

Run an authenticated vulnerability scan with a current signature set and confirm the scanner no longer flags CVE-2018-13374. If the appliance's admin interface was reachable from an untrusted network while unpatched, assume the configured LDAP bind credentials were exposed: rotate them, then review directory logs for unexpected binds from that account around the exposure window.

Frequently asked questions

What exactly does CVE-2018-13374 leak?

It leaks the LDAP bind credentials configured on the FortiGate or FortiADC. When an administrator runs the LDAP server connectivity test, the appliance sends those stored credentials to whatever server is named in the request. An attacker who redirects the test to a rogue LDAP server reads the username and password directly.

Which FortiOS and FortiADC versions are affected?

FortiOS 6.0.2, 5.6.7 and earlier; FortiADC 6.1.0, 6.0.0 to 6.0.1, and 5.4.0 to 5.4.4. Read your running build with get system status and check it against that range. The fixed builds are named in Fortinet advisory FG-IR-18-157.

Is CVE-2018-13374 used in ransomware campaigns?

The CISA KEV record does not flag this CVE for known ransomware use. It does confirm active exploitation in the wild, with a federal remediation due date of 2022-09-29, so it still warrants emergency handling.

Do I have to rotate the LDAP credentials after upgrading?

Yes, if the admin interface was ever reachable from an untrusted network while unpatched. The firmware upgrade stops future disclosure, but it cannot recall a password an attacker already captured. Rotate the LDAP bind account in your directory, update it on the appliance, and scope it to least privilege.

Is the admin interface required for this attack?

Yes. The CVSS vector lists privileges required as low (PR:L), so the attacker needs access to trigger the connectivity test. Restricting administrative access with trusted hosts and removing admin access from untrusted interfaces is an effective interim mitigation until you upgrade.

References

• Official vendor advisory: https://fortiguard.com/advisory/FG-IR-18-157
• NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2018-13374
• CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• CISA KEV record: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2018-13374
• Additional reference: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2018-13374

This guide was assembled from the official vendor advisory, the NVD record, and the CISA KEV catalog entry on 2026-05-25. Always confirm against the vendor advisory before applying changes in production.

Related fixes

Additional nearby issues sensible to fix in the same maintenance window:

• How to Fix CVE-2018-0173: Improper input validation in Cisco IOS and IOS XE
• How to Fix CVE-2018-0171: Improper Input Validation in Cisco IOS and IOS XE
• How to Fix CVE-2018-13382: Incorrect authorization in Fortinet FortiOS, FortiProxy
• How to Fix CVE-2018-0174: Improper input validation in Cisco IOS and IOS XE
• How to Fix CVE-2018-13383: Out-of-bounds write in Fortinet FortiOS and FortiProxy