If You Manage Someone Else's Firewalls, You Manage Their Attack Surface Too
Managed service providers inherit a specific kind of risk. A customer's outage is the provider's outage, and a customer's internet-facing appliance is reachable whether or not the provider's contract mentions attack surface management. The CL-STA-0954 intrusion is the clearest recent illustration of how far that inheritance can reach.
Unit 42 investigated a multi-stage intrusion against a telecommunications managed service provider that occurred in September 2024. The entry point was CVE-2024-47575 in a centralized FortiManager appliance. From that single device, attackers exfiltrated an archive containing running configurations, cryptographic material and database files describing more than 500 managed FortiGate firewalls. Those firewalls protected the provider's own infrastructure and the networks of its clients.
The researchers are explicit about scope. Their investigation spanned the provider's own environment and did not examine the client networks whose firewalls the provider managed. The exposure described in the report is configuration and credential material rather than confirmed intrusion into those client networks. That distinction should shape how an MSP reads the report and what it tells customers.
The shared-tenancy problem in a management plane
A FortiManager is a tenancy boundary that does not look like one. Administrators think of it as an operations tool. In practice it holds the trust relationships, credentials and configuration for every device enrolled under it. When that platform is compromised, the blast radius is defined by enrolment, not by contract tier.
ZoomEye measurements on 2026-10-22 show how the external population looks from outside. app="Fortinet FortiGate" returned 38,987 assets; title="FortiManager" returned 711,074; app="FortiManager" returned 1 and app="FortiManager" && port="443" returned 0. The title figure is weak evidence and includes documentation and reseller pages. The fingerprint figure is narrow. None of them indicate compromise, firmware version or tenancy.
What an MSP can honestly tell a customer
After a management-plane incident, a customer will ask one question: were we affected. The useful answer has three parts, and none of them is a reassurance.
- What the platform held. Name the classes of data: configuration, credentials, certificates. Avoid claiming more precision about client networks than the investigation supports.
- What was rotated. Certificates, management credentials and VPN credentials, with dates and verification method.
- What the customer must do independently. Their own administrative accounts, their own certificate trust, their own logging review.
A provider that can answer all three is in a better position than one that simply states the platform is patched. CVE-2024-47575 was fixed; the archive was already taken.
Building a per-customer exposure view
Ongoing management should include a per-tenant external view. The mechanics are unglamorous. Record each customer's public IP ranges and hostnames, resolve their certificates, and measure which of those addresses respond on the ports you know about. Compare that list against the enrolled devices in the management platform.
Three failure modes tend to appear.
- A customer asset that responds externally but is not enrolled in central management. Someone configured it directly, and the provider cannot patch it.
- An enrolled device that no longer resolves to the recorded address, meaning the inventory has drifted.
- A management portal reachable from the internet on a shared address space, which turns one provider misconfiguration into many customer exposures.
The measurement does not solve any of these. It makes them visible and attributable, which is the precondition for fixing them.
Contract language that follows the technical reality
If a provider is going to enumerate and monitor customer edge assets, the contract should say so, along with who acts on a finding and in what timeframe. Incident notification should cover credential exposure, not only confirmed breach, because credential exposure is what changes the customer's risk most quickly and what requires their own rotation work.
Limits
This article describes one intrusion against one provider. It does not establish that managed FortiGate fleets elsewhere are compromised, and it makes no claim about any specific customer network. The measurements are product-asset counts, not tenancy or vulnerability data.
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
Top comments (0)