Security teams triage exploits. They have CVSS scores, patch deadlines and a ticket workflow built around the idea that a flaw either is or is not present. CL-STA-0954 breaks that model, because the most damaging asset in the intrusion was not a vulnerability at all. It was a file full of secrets that already described how the network was built.

Unit 42's research, published 14 October 2026, explains what the attackers took from a compromised FortiManager: complete running configurations for more than 500 managed FortiGate firewalls, the global.db and revinfo.db management databases, internal topology maps, routing tables and interface configurations, ciphertext administrative, local and SSL/VPN credentials, and encoded cryptographic trust material including public certificates and private keys. A separate flat text file listed more than 500 FortiGate serial numbers beside their public IP addresses.

Why configuration material resists patching

A patched appliance still has the same hostname, the same certificate, and often the same administrator account name. CVE-2024-47575 was addressed by Fortinet, and the affected FortiManager ranges run from 6.2 through 7.6. Installing the fix closes the missing-authentication path. It does not change the fact that someone outside the organisation now knows the interface layout, the policy package names, and the public IP of every firewall that the platform managed.

That knowledge does not appear in a scanner. ZoomEye can tell you that 38,987 assets carry the app="Fortinet FortiGate" fingerprint, as measured on 2026-10-22, and that 711,074 assets carry FortiManager in their page title. Neither number says anything about who holds a copy of a configuration file.

The blast radius question

The practical question after a management-plane compromise is not which CVE to patch. It is what that device knew about everything else. For a FortiManager, the answer is the trust relationships with every enrolled device, the credentials used for management, and the certificates that make those relationships work.

Unit 42 notes that the investigation covered the provider's own environment and did not examine the client networks whose firewalls the provider managed. The researchers describe the exposure in that report as configuration and credential material rather than confirmed intrusion into those client networks. Exposure of a credential is a risk; it is not proof of use.

Building a rotation plan that matches the theft

If a management platform was reachable and potentially compromised, the response should be sequenced by what was taken.

  1. 1.

    Certificates and private keys first. Replacing them invalidates trust material that may already be in someone else's archive, and the change is verifiable from both sides.

  2. 2.

    Administrative credentials for the management platform and for each enrolled device. Unit 42 describes the attackers impersonating the FortiManager platform to pull configurations from managed firewalls of other hosts, so device-level admin trust needs review as well as the platform's own accounts.

  3. 3.

    SSL VPN credentials, with multi-factor authentication enforced before the rotation completes, so the new secret is not a single factor again.

  4. 4.

    Local accounts and service accounts discovered in the stolen configuration, which are often the ones nobody documented.

What external data can and cannot support

An external asset view has one honest use in this scenario: confirming that a device with a known public IP is still answering, and that its certificate matches the one you expect. A certificate that changed without a corresponding change ticket is worth a conversation. A device that answers on a port it should not is worth a conversation. Neither observation proves anything about the intrusion.

The reverse mistake is more common. Teams rebuild the perimeter after a high-profile incident and leave the management interfaces where they were, reachable from the same addresses as before, trusting a password that appeared in an archive nobody has fully catalogued.

Conclusion

Patching CVE-2024-47575 and CVE-2025-61624 is necessary and insufficient. The intrusion's durability came from information, and information exposure is closed by rotation, re-issuance and verification rather than by a version number. The uncomfortable part is that the work has no scanner result to celebrate at the end.

References

  • Unit 42, "Unit 42 Uncovers PEERSTITCH, a Stealthy FortiGate Implant", 14 October 2026: https://unit42.paloaltonetworks.com/fortimanager-cve-2024-47575-peerstitch-malware/

  • NVD, CVE-2024-47575: https://nvd.nist.gov/vuln/detail/CVE-2024-47575

  • NVD, CVE-2025-61624: https://nvd.nist.gov/vuln/detail/CVE-2025-61624

  • Fortinet PSIRT, FG-IR-26-122: https://fortiguard.fortinet.com/psirt/FG-IR-26-122