Fortinet CVE-2025-61624 enters KEV: medium score, active exploitation

CVSS helps compare the technical characteristics of vulnerabilities, but it cannot answer every question about business risk. CVE-2025-61624 has a 5.4 “medium” score, yet CISA added it to the Known Exploited Vulnerabilities catalog on October 16. The remediation deadline for US federal civilian agencies is October 19.

The vulnerability affects multiple Fortinet products: FortiOS, FortiProxy, FortiSwitchManager and FortiPAM. According to the CVE record, an authenticated attacker with an administrator profile and at least read-write permissions can use specific CLI commands to write or delete arbitrary files. The path traversal issue is classified as CWE-22.

Breachroad’s conclusion: a medium score does not mean low priority when the product is an important control point and the flaw is being exploited. At the same time, this is not described as an unauthenticated remote attack. Investigation should also ask how an attacker could have obtained privileged access in the first place.

Why CVSS and KEV answer different questions

The CVSS vector assumes local access and high privileges. That reduces the score compared with an internet-reachable flaw that needs no account. But if an intruder has already stolen administrator credentials, compromised a management workstation or exploited another vulnerability, arbitrary file write and deletion can become a later stage in the attack chain.

CVSS describes properties of an individual vulnerability. KEV indicates evidence of real-world exploitation. An organisation’s priority should combine both signals with the product’s role, exposure, data access and the ability to detect abuse.

The reverse inference is also unsafe: a KEV listing does not prove that every installation was compromised. It establishes the need for urgent verification, remediation and review of evidence.

Products and branches named in the record

The official CVE record includes the following ranges among those affected:

• FortiOS 7.6.0–7.6.4 and 7.4.0–7.4.9, plus listed releases in the 7.2, 7.0 and 6.4 branches;
• FortiProxy 7.6.0–7.6.4 and 7.4.0–7.4.11, plus releases in the 7.2 and 7.0 branches;
• FortiSwitchManager 7.2.0–7.2.7 and 7.0.0–7.0.6;
• listed FortiPAM releases spanning the 1.0 through 1.7 branches.

Because the range is broad, teams should not guess a target version merely by adding one to an upper bound. Check the specific product and branch in Fortinet advisory FG-IR-26-122, account for cluster dependencies and follow a supported upgrade path.

An action plan for organisations

1. Build an accurate inventory. Look beyond perimeter appliances to switch managers, proxies and privileged-access systems.
2. Confirm the version on every node. Do not rely only on a value stored in the CMDB or support contract.
3. Read the PSIRT guidance for that branch. Plan a configuration backup, maintenance window, cluster compatibility and safe rollback.
4. Review administrator accounts. Check dormant users, profile scope, login sources, MFA and supplier access.
5. Preserve and analyse CLI logs. Look for unusual commands, administrative sessions, file changes and work outside approved windows.
6. Compare configuration with a trusted copy. Continued availability does not prove integrity.
7. Inspect systems that lead to the console. A compromised administrator workstation, VPN or SSO identity may explain the required access.
8. Rotate secrets based on evidence and exposure. If abuse is found, include credentials reachable from the appliance, not just one operator password.

Remediation is necessary, but with active exploitation the task should not end at a version-compliance report.

Questions for the service owner

A business owner need not interpret CLI syntax, but should receive clear answers:

• do we use any affected product, and what role does it serve;
• is it current according to the relevant vendor advisory;
• who had administrative access, and can logs support the answer;
• which services will be affected by upgrade or isolation;
• were signs of compromise found, and what further scoping is required;
• who formally accepts the risk if remediation is deferred?

This avoids two errors: dismissing the flaw because its score is 5.4, or declaring an incident without evidence solely because a CVE appears in KEV.

Facts and conclusions

The vulnerability description, required privileges, affected products and CVSS score come from the CVE record and Fortinet advisory. Active exploitation and the federal deadline come from CISA’s catalog. That deadline is not a universal legal requirement for organisations outside the US federal government.

The method for combining CVSS, KEV, appliance role and compromise evidence is a Breachroad recommendation. Embed it in a vulnerability management process connected to the incident response plan. Infrastructure, SOC and service owners can rehearse this scenario during cybersecurity training for organisations, while an IT security audit can assess configuration, segmentation and privileged access.