Is CVE-2025-68686 (Fortinet FortiOS Exposure of Sensitive Information to an Unauthorized Actor) being exploited in the wild?

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

The practical test is not whether a proof of concept exists, but whether defenders should assume real attacker activity. For a FortiOS information exposure flaw, “in the wild” means adversaries may already have used the issue to read sensitive data from exposed systems, so the response priority shifts from routine patch scheduling to immediate exposure assessment and containment.

That is why CISA KEV matters here. The KEV catalogue is reserved for vulnerabilities with reliable evidence of active exploitation, which is a stronger operational signal than a generic severity score. If a perimeter or internet-facing Fortinet appliance is in scope, treat it as an urgent security event rather than a backlog item.

For teams trying to validate the status themselves, the safest authoritative references are the CISA Known Exploited Vulnerabilities Catalog and the vendor advisory, with the CVE Program and NIST National Vulnerability Database used for record lookup and technical context.

What exposure to check first on FortiOS systems

Start by confirming whether any FortiOS instances are reachable from untrusted networks, because sensitive-information exposure flaws often become meaningful when management, logging, or status data is exposed beyond intended operators. Prioritise appliances that sit at the network edge, are externally managed, or aggregate secrets, configuration, or authentication material from multiple services.

Then verify whether the device is actually running the affected FortiOS branch or feature set, because “installed somewhere” is not the same as “exposed in a way an attacker can exploit.” Inventory gaps, stale CMDB records, and forgotten branch appliances are common failure points for security teams responding to KEV-listed issues.

The quickest way to reduce uncertainty is to identify all Fortinet instances, map internet exposure, and check the vendor’s fixed-version guidance directly rather than relying on partial asset records. Edge Device Security Guide is a useful companion for this kind of perimeter-appliance triage because it focuses on management exposure, logging minimums, and end-of-life edge devices.

What to do if patching or upgrade must wait

If remediation cannot happen immediately, the goal is to narrow the attack surface and reduce the chance of sensitive-data disclosure before an exploit attempt lands. That usually means restricting management reachability, tightening administrative access, removing unnecessary exposure paths, and preserving logs so you can tell whether the device was queried or scraped before the fix.

If the vulnerable appliance has handled credentials, tokens, configuration exports, or session-related data, assume the exposure may extend beyond the box itself. In practice, that can require rotating any secrets that may have traversed the device or been retrievable through it, especially where the appliance has been used as a central trust point for network administration.

A broader incident response lens is useful here. The Zero-Day and Exploited Vulnerabilities Guide and Vulnerability Management Guide both support the operational decision to treat KEV-listed exploitation as a triage, containment, and verification problem, not just a patching workflow.

Risk and Threat Considerations

When an edge security appliance exposes sensitive information, the primary risk is that attackers can harvest data that helps them pivot deeper into the environment. Even if the first exposure is only partial, it can still reveal credentials, topology details, or administrative context that make follow-on intrusion easier and quieter.

Failure mechanism: Internet-reachable or otherwise accessible FortiOS systems can disclose information that was assumed to be internal, privileged, or operationally sensitive. Attackers then use that data to identify better targets, replay trust relationships, or accelerate compromise of adjacent systems.

Impact: The likely consequence is not just disclosure, but expanded blast radius, faster lateral movement, and increased likelihood that the appliance becomes an entry point or intelligence source for a broader intrusion.

Practitioner Guidance

What to prioritise: Treat KEV-listed FortiOS exposure as a live response item. First confirm asset ownership and internet exposure, then validate whether the vendor’s mitigations or fixed releases can be applied without breaking critical access paths.

What to verify: Confirm whether the affected appliance has stored or processed credentials, session material, configuration exports, or management secrets that would justify forced rotation if compromise cannot be ruled out. If logs are retained, preserve them before any disruptive change so compromise assessment remains possible.

Decision rule: If the system is externally reachable and you cannot prove it was never exposed to sensitive data, assume higher risk and shorten the remediation window. Where patching is delayed, compensation should focus on reachability reduction, administrative hardening, and post-exposure verification, not on waiting for more evidence.

Practitioner takeaway: For KEV-listed edge-device flaws, the right question is not “is there proof of abuse on my network yet?” but “what sensitive material could this appliance already have revealed, and how quickly can I reduce that blast radius?”

Related resources from NHI Mgmt Group

• How do you patch or mitigate CVE-2025-68686 (Fortinet FortiOS Exposure of Sensitive Information to an Unauthorized Actor)?
• CVE-2025-68686 (Fortinet FortiOS Exposure of Sensitive Information to an Unauthorized Actor)
• Is CVE-2026-20133 (Cisco Catalyst SD-WAN Manager Exposure of Sensitive Information to an Unauthorized Actor) being exploited in the wild?
• Is CVE-2025-48928 (TeleMessage TM SGNL Exposure of Core Dump File to an Unauthorized Control Sphere) being exploited in the wild?