How do you patch or mitigate CVE-2018-13374 (Fortinet FortiOS and FortiADC Improper Access Control)?

CISA’s required action for CVE-2018-13374 is to apply updates per vendor instructions. In practice, find every instance of Fortinet FortiOS and FortiADC in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What CVE-2018-13374 Means for FortiOS and FortiADC Owners

This is an access-control failure in perimeter appliances, so the first job is to confirm whether you have Fortinet FortiOS or FortiADC anywhere in scope, including devices that are internet-facing, remotely managed, or tucked inside a shared services segment. If the product is present, treat it as a patch-and-exposure problem, not just a versioning exercise. Prioritise the appliances that sit on the trust boundary first.

Because these systems often sit in front of many other services, one exposed appliance can become a shortcut into multiple downstream environments. That is why patching should be paired with a quick inventory of where the devices are deployed, what interfaces are exposed, and whether management or administrative paths are reachable from untrusted networks. The issue is operational as much as technical.

Vendor instructions should drive the update path, but the practical question is whether you can safely remove the vulnerable product from the attack path until the fix is in place. If you cannot patch immediately, reducing exposure by removing internet reachability or taking the device out of service is a valid containment step because the risk here is live exploitation of a boundary control.

For teams handling appliance estates at scale, a centralised view of version, exposure, and ownership matters more than a one-off ticket. NHIMG’s Edge Device Security Guide is useful here because the same operational pattern, exposed management plane, firmware hygiene, and end-of-life handling, applies to many perimeter devices, including Fortinet-class appliances.

How to Mitigate When You Cannot Patch Immediately

The safest mitigation is still the vendor update, but when maintenance windows or dependency risk delay that work, focus on blast-radius reduction. Restrict management access to trusted administrative networks, remove public exposure where possible, and disable any unnecessary service paths that let remote users reach the vulnerable function. The goal is to make exploitation materially harder while you schedule the fix.

If the appliance is business-critical and cannot be removed, compensate with tighter perimeter controls and monitoring. Put it under heightened log review, watch for unexpected authentication events, configuration changes, unusual admin sessions, and traffic patterns that suggest probing or follow-on access. For these devices, “mitigated” should mean controlled and observable, not merely still online.

Internal triage should also include asset and vulnerability management discipline. A Vulnerability Management Guide is a good fit for this kind of work because the decision points are the same: confirm exposure, prioritise by exploitability and asset criticality, track exceptions, and verify remediation rather than assuming a ticket equals a fix.

For the network side of the response, the Network Access Control (NAC) Guide is relevant to the containment phase because the shortest path to safer operation is often to constrain where the appliance can be reached from, especially for administrative access and other high-trust management flows.

How to Check for Exploitation and Recover Safely

After patching or containment, review logs for signs that the flaw was already used. Look for unexpected logins, account changes, configuration edits, new tunnels or forwarding rules, and any administrative activity that does not match normal change windows. Since attackers used the flaw in the wild, absence of an alert is not proof of absence; you need a deliberate search for compromise indicators.

If you find suspicious activity, treat the appliance as a potential initial access point and assess whether credentials, session material, or adjacent administrative access may also need rotation. That is especially important if the device was used to manage other systems or if admin secrets were stored on or reachable through the appliance. Recovery is about restoring trust, not only restoring service.

When you need a stronger model for post-exploitation review, NHIMG’s Salt Typhoon telecom intrusions 2025 offers a useful analogue for how compromised network-edge systems can be used to persist, harvest credentials, and move laterally after the initial breach.

Risk and Threat Considerations

Perimeter appliances are attractive targets because they sit on a high-trust boundary and often mediate many downstream connections. When access control fails on that kind of device, the impact is rarely limited to the appliance itself, because it can expose management functions, internal routing, and adjacent services to an attacker who should never have reached them.

Failure mechanism: An attacker reaches the vulnerable appliance, abuses the improper access control, and uses the resulting foothold to probe, alter, or pivot through trusted administrative and network paths.

Impact: Successful exploitation can lead to unauthorized access, configuration tampering, internal reconnaissance, and broader compromise of connected environments if the appliance was acting as a gateway or management point.

Standards & Framework Alignment

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

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	CVE patching and mitigation require timely flaw remediation on vulnerable appliances.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-patch review of appliance logs is needed to find signs of prior exploitation.
	AC-17 — Remote Access	Containment often depends on restricting remote and internet access to the vulnerable device.
Recommendation — Track the Fortinet fix, apply it promptly, and document any approved mitigation or exception. Review appliance logs for suspicious access, configuration changes, and follow-on activity. Restrict administrative reachability to trusted management networks until remediation is complete.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	The issue is a known exploited vulnerability that needs inventory, prioritisation, and remediation tracking.
	CIS-4 — Secure Configuration of Enterprise Assets and Software	Mitigation includes reducing exposure and disabling unnecessary access paths on the appliance.
Recommendation — Identify all affected appliances, prioritise them by exposure, and verify remediation status. Harden appliance exposure and remove unnecessary management access paths while patching.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	This CVE was used in the wild against exposed Fortinet systems, matching public-facing exploitation.
	T1046 — Network Service Discovery	Checking for earlier compromise includes looking for attacker reconnaissance after initial access.
Recommendation — Hunt for exploitation of exposed appliance interfaces and investigate resulting access. Search for probing and service-discovery activity that followed appliance compromise.

Practitioner Guidance

What to prioritise: Fix the internet-facing and remotely managed instances first, then work inward to less exposed deployments. If you have more than one Fortinet platform in scope, rank them by reachability and business criticality rather than by change convenience.

What to verify: Confirm the update or mitigation was actually applied, confirm the vulnerable service is no longer externally reachable where that is the chosen containment path, and verify whether any admin or device logs show suspicious pre-patch activity. A patch that is not independently verified should not be treated as closure.

Decision rule: If patching is delayed and the appliance still faces untrusted networks, treat the exposure as active and choose containment over optimism. If the device cannot be safely contained, removal from service is the cleaner risk decision.

Practitioner takeaway: For edge appliances, the real control objective is to shorten the window between exposure and verified remediation, while preserving enough logging and isolation to tell whether the device was already abused.