Unit 42 dates its FortiGate implant case to September 2024; the flaw behind the implant was published in April 2026

Three dates the report does not connect

Unit 42, the research team at Palo Alto Networks, published a report on 14 October 2026 about an intrusion at a telecommunications managed service provider. The report dates that intrusion to September 2024. It says the attackers put a memory-resident implant, which it names PEERSTITCH, on firewalls by using CVE-2025-61624, a FortiOS flaw. Fortinet's advisory FG-IR-26-122 and the CVE record both date the publication of that flaw to 14 April 2026.

Those are three dates the report never ties together. From the first day of September 2024 to 14 April 2026 is 590 days, and from the last day of September 2024 it is 561 days (derived). From 14 April 2026 to the report is 183 days (derived). From the intrusion month to the report is 744 to 773 days (derived). The report calls the intrusion "prolonged" and refers to an "extended dwell period" before the attackers began reconnaissance. It does not say when the implant was placed, and it does not say when Unit 42 found it.

The missing date is the point. If the implant went in while CVE-2025-61624 was unpublished, Fortinet had no fix to offer for it. If it went in after 14 April 2026, a fixed build existed for two FortiOS branches and none for three others (Fortinet's advisory, read below). The record does not establish which. It therefore does not establish how long any device has carried the implant, how many devices carry it, who is behind it, whether Fortinet has confirmed or added anything, or whether a device that has since been patched can still carry it. Every one of those is a row in the table further down.

Interest, in one sentence: Palo Alto Networks sells network security products that compete with Fortinet's, and its report lists its own products as protections. This briefing therefore attributes every claim about the implant to Unit 42, treats the report as one vendor's account of one victim, and takes dates, versions and scores from Fortinet's advisories, the CVE and NVD records and CISA's catalogue. This site has read Palo Alto's own advisories the same way, for example CISA gave 3 days and Palo Alto gave no count for very limited exploitation.

How this was read: the Unit 42 report was read in full from 08:43 BST on Thursday 15 October 2026. Fortinet's advisories, the NVD and CVE.org records, CISA's catalogue file, Mandiant's 2024 post and the UK pages were read from their own sites and re-read at 09:02 BST. Independent coverage was thin, and the record section says exactly what was and was not found.

What Unit 42 says it found, in its own terms

Unit 42 says it investigated a prolonged intrusion against a telecommunications managed service provider, which it tracks as cluster CL-STA-0954 and says is also known as UNC5820 (the label Mandiant used in 2024). Initial access, it says, was CVE-2024-47575 against a central FortiManager. From that one appliance the attackers took an archive containing running configurations, cryptographic material and database files for "more than 500" managed FortiGate firewalls, which protected the provider's own infrastructure and its clients' networks.

After a dwell period the attackers, per the report, used the FortiManager to push packet-capture settings to downstream firewalls, aimed at unencrypted web traffic and eleven further services and, later, at authentication, directory and file-transfer traffic on core perimeter firewalls. Unit 42 says it confirmed that administrative and VPN passwords could be recovered from the stolen configurations, and that the attackers then used legitimate credentials to open VPN sessions to perimeter firewalls. Its executive summary lists the results as five items: long-term access, intercepted traffic, VPN sessions, backdoors and a separate privilege-escalation flaw.

The implant, at the level a CISO needs. PEERSTITCH is, in the report's words, "a novel, memory-resident ARM64 malware". It runs once, patches the memory of two core FortiOS services (the logging service and the VPN service), leaves no persistent binary on disk, opens no listening ports and starts no outbound connections. It communicates through traffic generated by legitimate processes on the device, which Unit 42 says makes it "resistant to conventional endpoint and network detection". What it gives an attacker, per the report: it suppresses the firewall's tamper detection, and it lets selected VPN sessions bypass the firewall's default security validation. It was delivered through CVE-2025-61624, which the report describes as taking an authenticated administrator to root.

Persistence needs care. The report says the implant leaves no persistent binary on disk, and its conclusion says the attackers "achieved sustained persistence while evading traditional monitoring". That second sentence is about the attackers, and the report builds their access from several parts: recovered credentials and VPN sessions, a second command channel made from a certificate-management feature that ships on the firewall (the report calls that channel persistent), impersonation of the management platform, and the implant. The report does not say whether PEERSTITCH itself survives a restart or a firmware upgrade. Code held only in running memory would normally be lost when the process restarts (inference; the report does not test it). That would not remove stolen passwords or keys, and it would destroy volatile evidence, which is why the checklist puts evidence first.

The report lists steps taken to avoid evidence: switching off local and remote logging before running its scripts, clearing crash records, deleting the administrator accounts, VPN groups and script objects it had created, leaving decoy content in place of one configuration file, and removing the implant's own file from disk. Unit 42 assesses with medium confidence that the attackers also induced drops in log telemetry to central management consoles, and says it could not confirm the mechanism.

Separately, an administrative account whose name matched a Fortinet cloud service downloaded full configurations from several managed firewalls, although the victim ran no such service. Unit 42 assesses with medium confidence that the attackers impersonated the management platform, and says the evidence does not distinguish between two ways of doing it: abusing a second Fortinet flaw, CVE-2024-26009, or reusing the stolen trust material. It names CVE-2024-26008 as a possible cause of the telemetry drops, and excludes a set of cloud sign-in flaws (CVE-2025-59718, CVE-2025-59719 and the issues grouped under FG-IR-26-060) because the firewalls were not enrolled in that feature.

Scope and attribution are modest. Unit 42 examined the provider's own environment and did not examine the client networks; it says the exposure it describes is "of configuration and credential material rather than confirmed intrusion into those networks". It says aspects of the post-exploitation activity "overlap with intrusions attributed to suspected nation-state actors", and names no actor and no country. Mandiant's October 2024 post, which introduced UNC5820, said it lacked "sufficient data to assess actor motivation or location". No 2026 statement from Mandiant was found.

Unit 42's advice is short. For organisations that manage infrastructure for others, the management platform is "the highest-value target on the network". Edge management interfaces should get "the highest level of zero trust isolation", and the credentials and certificates they hold should be treated "as compromised the moment the platform is". A compromise, it says, "also does not end when the platform is patched". For detection it says the implant needs specialised hunting and lists five places to look: memory, the integrity of the two services, system-call telemetry, crash records and configuration revisions. The specifics are in its table.

Stated and not stated, row by row

"Not stated" means not found in the Unit 42 report, read in full, or in the Fortinet and CISA pages named in the sources. It does not mean the information does not exist.

What the Unit 42 report (14 October 2026) states and what neither it nor the Fortinet, CVE, NVD and CISA records state, as read on 15 October 2026.

The question	Stated	Not stated
What is the implant for?	A memory-resident ARM64 implant on FortiGate firewalls that hides in two core services, suppresses tamper detection and lets selected VPN sessions skip default validation.	What the attackers did with the access it gave, or whether it is used for anything else.
Which products and versions?	FortiManager (CVE-2024-47575) and FortiOS (CVE-2025-61624), with CVE-2024-26009 and CVE-2024-26008 as possible paths. The victim ran no FortiManager Cloud tenant.	The FortiManager or FortiOS versions the victim ran, the FortiGate models, or which models are ARM64.
How was it found?	An investigation of a real intrusion at a provider, in the provider's own environment. Findings shared with the Cyber Threat Alliance.	Who engaged Unit 42 and when, how the intrusion was first noticed, how the implant was obtained, whether the provider is a Palo Alto customer.
How many devices?	More than 500 managed FortiGate configurations in the archive. The loader went to "a select number of firewalls". Capture settings went to "multiple" downstream firewalls.	How many firewalls carry the implant, how many clients were affected, or any count of devices reached by each step.
When?	Intrusion in September 2024. "Prolonged". An "extended dwell period".	The day of first access, the date the implant was placed, how long it ran, the date of discovery.
Who?	Cluster CL-STA-0954, "aka UNC5820". Some overlap with suspected nation-state activity.	An actor name, a country, a motive, or any Mandiant confirmation of the match.
Does a patched device still carry it?	Compromise of the platform "does not end when the platform is patched". Stolen trust material stays valid until rotated.	Whether a restart or an upgrade removes the implant, or whether any patched firewall was found carrying it.
Has Fortinet confirmed or added anything?	Fortinet's advisory for CVE-2025-61624 says "Known Exploited: Yes", with a single timeline entry, 14 April 2026, as read on 15 October.	Any Fortinet advisory, blog post or statement about the implant or the report. None was found on its advisory feed or blog index.
Independent confirmation?	Mandiant in 2024 reported UNC5820 exploiting CVE-2024-47575 and taking configuration data.	Any independent analysis of the implant. The only coverage found is a rewrite of the report.
Link to FortiBleed?	The report's resource list includes the 6 October 2026 FBI and Secret Service FortiBleed alert.	Any statement in the text connecting this intrusion to FortiBleed.

On coverage: the feeds of The Hacker News, BleepingComputer, SecurityWeek, The Register, Infosecurity Magazine, Dark Reading and CyberScoop, read on the morning of 15 October 2026, carried no item on PEERSTITCH. One secondary rewrite, on SecurityOnline, repeats the report's claims and adds no analysis or confirmation, and this briefing does not rely on it. A rewrite is not a second source. For the implant, the whole public record is one vendor's report on one victim.

One match is worth stating, as a comparison made for this briefing rather than anything Unit 42 says. The rogue-device details and the first two attacker addresses that Unit 42 gives for the entry stage all appear among the indicators Fortinet published in FG-IR-24-423 in 2024, and the rogue device's name and serial also appear in Mandiant's 2024 post. So the entry stage left indicators that Fortinet and Mandiant had already published in 2024. No earlier public description of the implant stage was found.

Fix date before write-up date

CVE-2024-47575 is not new. The CVE record, Fortinet's advisory FG-IR-24-423 and CISA's catalogue entry are all dated 23 October 2024, which is 721 days before the Unit 42 report (derived). Fortinet's advisory lists a fixed build for every affected FortiManager branch (FortiManager Cloud 6.4 is told to migrate), and CISA said on 30 October 2024 that all patches had been released. The table sets every date this briefing relies on in order.

Dates in order, each from the source named. Exploitation dates are not advisory dates. Intrusion day is not stated by Unit 42.

Date	What happened	Source
27 June 2024	Mandiant's earliest observed exploitation attempt on CVE-2024-47575, among 50+ potentially compromised FortiManager devices. Other victims, not stated to include Unit 42's.	Mandiant, 24 October 2024
September 2024	Unit 42's intrusion. Day not stated.	Unit 42
27 September 2024	CVE ID for CVE-2024-47575 reserved.	CVE.org
23 October 2024	Fortinet advisory FG-IR-24-423 published with fixed builds. CVE record published. CISA adds the flaw to its catalogue. CVSS 9.8, critical.	Fortinet, CVE.org, NVD, CISA
13 November 2024	CISA's due date, 21 days after listing. Ransomware use recorded as "Unknown".	CISA catalogue
27 November 2024	Last update of FG-IR-24-423.	Fortinet
12 August 2025	Advisory for CVE-2024-26009, Known Exploited: No.	Fortinet FG-IR-24-042
29 September 2025	CVE ID for CVE-2025-61624 reserved. The 2025 in the number is the reservation year.	CVE.org
14 October 2025	Advisory for CVE-2024-26008, Known Exploited: No.	Fortinet FG-IR-24-041
14 April 2026	Advisory FG-IR-26-122 and CVE record for CVE-2025-61624 published. Fortinet: Medium, 6.0, Known Exploited: Yes. NVD: 6.5, Medium.	Fortinet, CVE.org, NVD
14 October 2026	Unit 42 report. The NVD record for CVE-2025-61624 is last modified the same day; what changed was not read.	Unit 42, NVD
15 October 2026	FG-IR-26-122 shows no later entry than 14 April 2026. CISA's catalogue, version 2026.10.14, has no entry for CVE-2025-61624.	Fortinet, CISA

On Unit 42's own dating, the first access came before Fortinet's advisory: the intrusion month precedes 23 October 2024 by 23 to 52 days (derived). So at least for this victim the entry flaw was used before a fix existed. Mandiant's earliest observed attempt, on other victims, is 118 days before the advisory (derived).

CVE-2025-61624 is the flaw that looks old and is not. Its number says 2025, but CVE.org shows the ID was reserved on 29 September 2025 and published on 14 April 2026, 197 days later (derived). The number is the reservation year, not a date of discovery or use. Two records of that flaw differ today: Fortinet's advisory says "Known Exploited: Yes", while the CISA-ADP entry in NVD, time-stamped 14 April 2026, records exploitation as none. The ADP entry is a snapshot from the day of publication, so the difference may be age rather than conflict. Fortinet's advisory also lists a virtual patch whose identifier ends in "0day". The advisory does not explain that label, so this briefing does not read it as a statement about when exploitation began.

An archived copy of the April advisory would show whether the exploited flag was there from the start. The Internet Archive's index lists a capture of 15 April 2026, but the archive refused the request (too many requests), so it was not read. What can be said is what the live page says on 15 October 2026.

Which Fortinet products and versions are in the frame

The report names the flaws but states no firmware version or model for any device in the victim. The table is therefore Fortinet's, not Unit 42's: what each advisory lists, and where it says the fix is.

The four Fortinet flaws named in Unit 42's report, from Fortinet's advisories as read on 15 October 2026. Unit 42's role for each is in the first column.

Flaw, advisory, date, score	Affected, per Fortinet	Fixed builds, per Fortinet	Exploited, per Fortinet
CVE-2024-47575, FG-IR-24-423, 23 Oct 2024, 9.8. Unit 42: initial access.	FortiManager 7.6.0; 7.4.0 to 7.4.4; 7.2.0 to 7.2.7; 7.0.0 to 7.0.12; 6.4.0 to 6.4.14; 6.2.0 to 6.2.12. FortiManager Cloud 7.4, 7.2, 7.0, 6.4. Some older FortiAnalyzer models with the manager feature on.	7.6.1, 7.4.5, 7.2.8, 7.0.13, 6.4.15, 6.2.13. Cloud 7.4.5, 7.2.8, 7.0.13. Cloud 6.4: migrate.	Yes. In CISA's catalogue.
CVE-2025-61624, FG-IR-26-122, 14 Apr 2026, 6.0 Medium. Unit 42: escalation to root.	FortiOS 7.6.0 to 7.6.4; 7.4.0 to 7.4.9; 7.2, 7.0 and 6.4 all versions. Also FortiPAM, FortiProxy, FortiSwitchManager.	FortiOS 7.6.5 and 7.4.10. For 7.2, 7.0 and 6.4: migrate to a fixed release.	Yes. Not in CISA's catalogue at version 2026.10.14.
CVE-2024-26009, FG-IR-24-042, 12 Aug 2025, 8.1 High. Unit 42: a possible path.	FortiOS 6.4.0 to 6.4.15; 6.2.0 to 6.2.16; 6.0 all versions. FortiOS 7.0 to 7.6: not affected.	6.4.16 and 6.2.17. For 6.0: migrate.	No.
CVE-2024-26008, FG-IR-24-041, 14 Oct 2025, 5.3 Medium. Unit 42: a possible cause of telemetry drops.	FortiOS 7.4.0 to 7.4.3; 7.2.0 to 7.2.7; 7.0, 6.4 and 6.2 all versions.	7.4.4 and 7.2.8. For 7.0, 6.4, 6.2: migrate.	No.

Three readings follow from Fortinet's own pages, with no help from the report. First, of the five FortiOS branches Fortinet lists for CVE-2025-61624, two have an in-branch fixed build and three do not, which is 40 per cent and 60 per cent (derived). Owners of 7.2, 7.0 and 6.4 cannot close it by installing the latest release of their branch. Second, Fortinet lists FortiOS 7.0 to 7.6 as not affected by CVE-2024-26009, so if the provider's firewalls ran those branches that path was closed. The report states no version, so this cannot be settled. Third, CVE-2025-61624 also lists FortiPAM, FortiProxy and FortiSwitchManager. Unit 42 reports the implant on FortiGate only, and says nothing about the others.

What a patch undoes, and what it leaves

The report's most useful claim for a defender is not the implant. It is that patching the management platform does not end the compromise, because what the attackers took does not expire. The figure draws the three steps in Unit 42's report and what a patch undoes at each.

Fortinet's 2024 advice and Unit 42's 2026 advice agree on the main control, which is rotation. What changed is the evidence. The table puts the two side by side.

Fortinet's advisory FG-IR-24-423 (published 23 October 2024, last updated 27 November 2024) set against Unit 42's report (14 October 2026).

Fortinet, 2024	Unit 42, 2026
No reports of "low-level system installations of malware or backdoors" on the compromised FortiManager systems.	Claims no implant on a FortiManager. Describes an implant on managed FortiGate firewalls.
Had not seen managed devices compromised, but said it should be assumed that could happen.	Attackers pushed capture settings to downstream firewalls, opened VPN sessions with recovered credentials and deployed the implant to "a select number of firewalls".
Change the credentials of all managed devices: administrator and local accounts, certificate private keys, VPN pre-shared keys, directory and authentication secrets, routing and management secrets, and more.	The trust material "remains valid until it is rotated".
The fix is "not meant to prevent adding unauthorized devices". It stops unauthorised devices sending exploit commands, so registration log lines can continue on a patched system.	A rogue virtual FortiGate was registered to the central FortiManager during the initial phase.

That is a change in the public record, not a contradiction. Fortinet's 2024 statement covered what it knew in 2024, and it was about FortiManager systems. But the advisory has not been updated since 27 November 2024, which is 686 days before the Unit 42 report (derived). A reader who stopped at its "no reports" sentence could conclude that managed devices had not been reached, though the same page says to assume they could be. The advisory's 7 November 2024 timeline entry, "Added recommendation for managed devices", is 706 days before the report (derived).

Six words that do the work of a control

A comforting label is not a control. The report, the headlines built on it and the vendor pages use words that sound like a status. Each one hides a question.

Six words used about this story, what they suggest, and what the record shows.

The word	What it suggests	What the record shows
Implant	One object you can find and delete.	A memory-resident injector that patches two running services, plus separate footholds: recovered credentials, VPN sessions, a second command channel and management impersonation. Removing one does not remove the rest.
Stealthy	It cannot be seen.	Unit 42 says it resists conventional endpoint and network detection. The same report shows figures captioned as Fortinet logs of the escalation, lists five hunting surfaces, and says logging was switched off first. Stealth belonged to the attackers' steps, not to the implant alone.
Patched	The risk is closed.	The entry flaw has had a fix since 23 October 2024. Stolen keys and passwords stay valid until rotated, three FortiOS branches have no fixed build for the escalation flaw, and whether a patched device can carry the implant is not stated.
FortiGate, in the title, and FortiManager, in the address	One product, one fix.	The way in was FortiManager. The implant is on FortiGate. FortiGate firewalls are not in CVE-2024-47575's affected list, yet they are where the implant sits, and the 2024 fix is a FortiManager fix.
Known vulnerability	Old and handled.	The 2024 flaw is known to catalogues. The flaw used for the implant carries a 2025 number but was published in 2026. Known to a catalogue is not known to your asset inventory.
Medium	It can wait.	Fortinet scores CVE-2025-61624 at 6.0 and NIST at 6.5, both Medium, and Fortinet marks it exploited. It needs an administrator login, and the report says administrative passwords were recovered from the stolen configurations.

The UK reading

The report does not say where the provider is, whether any UK network is among the 500 firewalls, or whether any personal data is involved. Nothing here says a UK organisation is affected. The pages in the table are what a UK organisation that runs Fortinet management, or buys it as a service, should hold the report against. All are read as published.

UK sources as read on 15 October 2026, and what they mean for a reader holding this report.

UK source	What it says	Held against this report
NCSC, Responding to active exploitation of vulnerabilities (v2.1, 1 May 2026)	A table sets update windows for a catalogued vulnerability. Internet accessible, not automatable, total control: install within 48 hours, with an assured incident response provider. Critical suppliers and managed service providers should be contractually liable to mitigate rapidly. If investigation is not possible, erase and rebuild.	CVE-2024-47575 is catalogued, and the CISA-ADP entry in NVD says not automatable with total technical impact. For an internet-reachable manager that is the NCSC's 48-hour row. One that was never investigated sits outside it.
NCSC alert on Fortinet firewalls and VPN gateways (18 June 2026)	Isolate compromised devices, factory reset because changing credentials alone may not be enough if persistence was gained, keep logs and configurations first, and investigate other edge devices that share credentials.	A different campaign, the FortiBleed credential leak, which [an earlier briefing](https://www.pk-sharma.com/briefing/fortibleed-fbi-alert-names-no-cve-86644-is-socradars-count-once-30791) covers. The reasoning transfers: credentials alone are not enough, and evidence goes before the reset.
NCSC alert on internet-exposed systems and edge devices (27 August 2026)	Manage boundary devices only from a segregated management network not connected to the internet. Keep an inventory. Monitor for unexpected configuration changes or outbound connections. Register for Early Warning.	Unit 42's own conclusion has the same shape: isolate the management plane.
NCSC blog on forensic observability (29 July 2026) and device guidance (4 February 2025)	Defenders need supported ways to tell whether a device can still be trusted, including from memory. The guidance says devices should support volatile collection of running state, such as process memory maps.	A memory-resident implant is the case this guidance is written for. Ask your vendor and provider how they would collect memory from a firewall before you need to.
Cyber Essentials, Requirements for IT Infrastructure v3.3 (April 2026)	Update within 14 days when the vendor calls the fix critical or high or the CVSS v3 score is 7 or above. Software must be supported. Accounts used by a managed service provider are in scope.	CVE-2024-47575 (9.8) started that 14-day clock on 23 October 2024, which ended on 6 November 2024 (derived). CVE-2025-61624 (6.0 and 6.5) does not meet it by score, yet Fortinet marks it exploited.
ICO, Personal data breaches: a guide	Report a notifiable breach within 72 hours of becoming aware, in phases if needed. A processor tells the controller without undue delay. Communications service providers use the PECR route, also 72 hours.	The report does not say personal data was taken. It describes capture aimed at authentication and directory traffic and recovered credentials. Whether that is personal data is each controller's call. Settle who tells whom before an incident.

Two limits on that table. The NCSC row is a retrospective reading, because the page is dated May 2026 and the flaw is from 2024. And the Cyber Essentials trigger is a score or a vendor label, not an exploitation flag, so it will not by itself move a Medium flaw that Fortinet says is exploited. Branches with no fixed build are not unique to this flaw: an exploited FortiMail flaw had none in four branches.

What to do, in the order worth doing it

The question that exposes the gap

If your FortiManager, or your provider's, was reachable from the internet at any point before 23 October 2024, who can show you in writing that every key, certificate and password it held was replaced, and on what date?

The record has a date for the fix, 721 days before the report (derived). It has a date for the escalation flaw, 14 April 2026. It has no date for the implant, no count of firewalls that carry it and no answer on whether a patched device still can. The keys have no expiry date unless someone sets one, and the report says they stay valid until rotated. A provider that answers with a patch date has answered a different question.