Citrix NetScaler was exploited at least 22 days before the patch. The three-day federal clock ends today

22 days of exploitation, then 3 days to patch

The federal deadline for the two exploited Citrix NetScaler flaws falls today, Wednesday 30 September. The clock started on Sunday 27 September, when Citrix published its bulletin with fixed builds and CISA added CVE-2026-88771 and CVE-2026-88772 to the Known Exploited Vulnerabilities (KEV) catalogue. The earliest exploitation anyone has documented is 5 September, reported by the security firm eSentire. That is 22 days of attacks before any fix was public, followed by 3 days for federal agencies to apply it. Counted from 5 September, today is day 25.

What that does not establish. The 5 September date is one vendor's observation of its own customers' intrusions, and it concerns one of the two flaws. It is a floor, not a start date: Mandiant, part of Google, says only that exploitation of the other flaw has run "since at least early September". The number says nothing about who is behind the attacks, how many organisations were compromised, or when Citrix first learned of the flaws. Nor does it mean that an appliance patched this week is clean.

This briefing builds the timeline from primary sources, separates what Mandiant observed from what the coverage says it observed, checks the exploited pair against the earlier briefing on the same bulletin, and ends with what to hunt and harden. It stays at defender level: no exploitation steps, no payloads and no indicator lists. The vendors publish those for defenders, and their pages are in the sources.

The timeline, with the arithmetic shown

Every date below comes from a page we read in full, and each row says how firm the evidence is. Times are UTC where a source gives one. The diagram draws the same dates to scale.

Dated events, 5 to 30 September 2026, with the standing of each. Secondary press is marked; everything else was read at the source.

Date (2026)	What happened	How firm it is
Sat 5 Sep	eSentire's Threat Response Unit reports exploitation of CVE-2026-88771 against internet-facing NetScaler Gateways "as early as September 5th", with a web shell operated from that date in one intrusion.	One vendor, first-hand, its own customers. Not independently confirmed.
Early Sep	Mandiant and Google's threat intelligence group say the CVE-2026-88772 campaign has run "since at least early September".	First-hand. No exact date given.
Thu 10 Sep	All eight CVE IDs in the bulletin were reserved in one batch at 07:14:57 UTC, with NetScaler as the assigning body.	CVE.org record. Routine bookkeeping; it does not show what Citrix knew that day.
Thu 24 Sep	GreyNoise's sensor logs three sessions between 07:32:19 and 07:32:20 UTC that it later tags as CVE-2026-88771 attempts. They failed against the sensor.	First-hand, one sensor. An attempt, not a compromise.
Sat 26 Sep	watchTowr says publicly that rumours of unpatched NetScaler flaws are credible. Administrators report supplier calls advising shutdown.	Secondary reports. The X posts were not read.
Sun 27 Sep	Citrix publishes CTX697096 with fixed builds. The CVE records go public (16:02 and 16:09 UTC for the two exploited flaws). CISA adds both to KEV, due 30 September.	Primary: Citrix, CVE.org, CISA.
Mon 28 Sep	NCSC publishes a UK alert. Unit 42 counts 50,277 exposed instances that could be vulnerable, as of 27 September. watchTowr publishes an analysis of 88771.	Primary. Unit 42's count is vendor telemetry.
Tue 29 Sep	Mandiant and GTIG publish their post. eSentire updates its advisory. watchTowr publishes a write-up of 88772.	Primary.
Wed 30 Sep	Federal due date for both flaws, with forensic triage required.	Primary: the CISA KEV records.

The arithmetic. Calendar days, derived by us from the dates above.

Interval	Days	What it measures
5 Sep to 27 Sep	22	Earliest documented exploitation to the bulletin, fixed builds and KEV listing
10 Sep to 27 Sep	17	CVE IDs reserved to public disclosure. A batch reservation, not evidence of knowledge
24 Sep to 27 Sep	3	GreyNoise's sensor attempt to disclosure (3 days 8 hours, 07:32 to 15:51 UTC)
27 Sep to 30 Sep	3	KEV listing to the federal due date, the BOD 26-04 clock
5 Sep to 30 Sep	25	Earliest documented exploitation to the due date
27 Sep to 29 Sep	2	KEV listing to Mandiant's detailed hunting guidance

The fix and the disclosure arrived together. Citrix named fixed builds in its first publication and lists no workaround in it, so there is no gap between disclosure and a fix. The gap is between exploitation and disclosure. The bulletin itself says only that exploits "have been observed" on unmitigated deployments. It gives no date, no victim count and no actor.

What Mandiant observed, and what it did not

Headlines say Mandiant observed exploitation of both flaws and attackers spreading through internal networks. The post is narrower than that, and the difference matters to anyone deciding how worried to be.

What Mandiant and Google's threat intelligence group state in their 29 September post, and what they do not. Read in full; quotations are from the post.

Topic	Stated in the post	Not stated in the post
Which flaw	CVE-2026-88772, a zero-day, exploited "since at least early September". For CVE-2026-88771 it cites "vendor disclosures".	A start date. The post does not itself report seeing 88771 exploited.
Victims	Evidence that organisations in North America and Europe, in government, financial services, technology, education, and legal and professional services, were "likely impacted".	A count, names, or a split by country or sector.
How access was gained	Telemetry analysis suggests the flaw sits in the packet engine's handling of the DTLS handshake, which uses UDP/443. Google says it "does not possess exploit code".	Confirmation from code. The mechanism is inferred from telemetry.
Tooling	New PHP web shells including WHIPSHOT, and a Python tunnelling tool, SLAPSHOT. Web shell filenames "varied between victims".	Whether every victim received the same builds, or one operator ran every intrusion.
After access	In "at least one observed intrusion" the actor used the tunnelling tool for manual internal reconnaissance and credential theft.	How many intrusions, which credentials, what data left, how far anyone moved.
Who	"The threat actor", singular. No group name, country or motive.	Attribution of any kind.
Dwell time	Nothing.	How long any victim was compromised before detection.
After patching	Advises upgrading, and rotating credentials after the appliance is patched. Describes changes made to persist, applied with an appliance reboot.	Whether an upgrade removes them. The post does not say a patched system is safe.

Who said the rest. Mandiant Consulting's chief technology officer, Charles Carmakal, wrote on LinkedIn on 29 September that Mandiant is "aware of dozens of impacted organizations" and that CVE-2026-88772 was exploited "by advanced and suspected state-sponsored threat actors". An earlier post, dated by Cybersecurity Dive to Monday 28 September, said the actor had "moved laterally" into the internal networks of some targets. Those are a named executive's public statements. They are not in the technical post, and neither comes with a method, a list or a confidence level. We treat them as Mandiant's public position, not as findings we can check.

How many appliances? No source gives a count of compromised appliances. Exposure counts differ by method. Unit 42 counts 50,277 exposed instances that could be vulnerable, as of 27 September. Shadowserver, as reported by the press, shows more than 20,000 visible and potentially vulnerable, and about 23,000 with NetScaler fingerprints. BleepingComputer notes that nobody has said how many of those are honeypots, already patched or configured in a vulnerable way. As of its 28 September alert, NCSC said it was "working to understand the impact" on UK organisations, and we found no UK count.

Most of the firms quoted here sell something adjacent. Mandiant and Unit 42 sell incident response, eSentire managed detection, watchTowr exposure management, GreyNoise threat intelligence, and Citrix the appliances. That is not a reason to doubt any observation. It is a reason to keep each claim attached to the party that made it.

One toolkit, one actor, or a shared pattern?

The named malware makes the campaign sound like one operation. The sources describe something looser.

• Inside Mandiant's own set, filenames varied between victims, two different ways of making the appliance web server run the shells were seen in different intrusions, and several web shell variants were recovered.
• eSentire, describing attacks on CVE-2026-88771, reports two web shell variants, one passing as image requests and one as package files. It says the same technique and payload were tied to data theft at other organisations, and that at one victim the attacker connected onward to internal virtual desktops. It cites Google's names separately and does not say its shells are WHIPSHOT.
• GreyNoise's 24 September attempt, also against CVE-2026-88771, shows a different disguise for the web shell but the same broad approach to persisting on the appliance. It failed, so it shows a plan, not a compromise.

Our reading, and it is inference. The same family of techniques appears alongside both flaws, in three independent sources. That fits one capable group with two exploits, shared tooling, or copying. No source decides between them, and we will not. Two things follow for defenders. Hunting for the names WHIPSHOT and SLAPSHOT alone would miss variants, so hunt the behaviours in the checklist below. And the pool of attackers is widening. watchTowr published technical write-ups on 28 and 29 September, and press reports say the first came with a proof of concept. GreyNoise told The Hacker News that the additional activity it began seeing on 28 September had grown from reconnaissance into "mass exploitation across a multitude of independent actors and campaigns", with web shells deployed for "botnet recruitment and access brokering". That is a secondary report of GreyNoise's data, which we did not see. Mandiant's chief technology officer expects "broad and opportunistic exploitation".

Against briefing 143: the two on the clock are the two exploited

Briefing 143 argued that the three-day federal clock covers two of the eight flaws in the bulletin, and that on NVD's scale neither is the highest scored. Two days on, most of that stands. One part has moved, and the movement matters.

Claims in briefing 143, checked against the record on 30 September 2026. The KEV feed, the NVD records and the Citrix bulletin were re-read that morning.

Claim in briefing 143	Still holds?	What the record now shows
The clock covers two of the eight flaws.	Yes.	The KEV records for 88771 and 88772 still show a due date of 30 September and forensic triage required. The other six are not listed.
Those two are the two Citrix says are exploited.	Yes, now corroborated.	Mandiant for 88772, eSentire and GreyNoise for 88771. No source we read reports exploitation of the other six.
Neither is the highest scored.	Only on NVD's CVSS 3.1 scale.	On Citrix's v4.0 scale the pair is joint highest at 9.5. On NVD's scale 88771 scores 9.8 and 88772 scores 8.1.
Three flaws have no NVD score.	No longer.	NVD has since scored 88776 and 88777 at 9.8 and 88778 at 7.5.
Patch the product, not the list.	Yes, more so.	One build covers seven of the eight. 88778 also needs a configuration change. Mandiant's DTLS controls apply to 88772 only, and the bulletin offers no workaround for 88771.
The KEV record for 88771 carries 88772's weakness code and NVD link.	Yes, still.	Version 2026.09.29 of the feed still lists CWE-119 for 88771 and ends its notes with the link to 88772's NVD page.

What changes. The argument in 143 was that KEV lists what is exploited, not what is worst. That has held: the exploited pair were the right pair, and the clock sits on the right flaws. What the record now shows is what KEV cannot tell you. It says what to fix and by when. It does not say since when. The clock started when CISA listed the flaws, 22 days after the earliest documented exploitation.

The second change is about the score. The flaw at the centre of Mandiant's investigation is 88772, which NVD scores 8.1. That is sixth of eight on NVD's 3.1 scale, below four flaws that no source reports as exploited: 88773 at 10.0, and 88775, 88776 and 88777 at 9.8. Both Citrix's vector and NVD's mark its attack complexity as high, and Mandiant's chief technology officer calls the actors who used it advanced. A score describes the flaw. It does not describe who is attacking, or how much effort they will spend.

Patched is not clean

The comforting label in this story is "patched". In a vulnerability report it becomes "remediated" and the ticket closes. On the record so far, that is the wrong thing to close. Every party that speaks about compromise says so:

• CISA (alert of 27 September, revised 28 September) encourages checking for compromise before patching where possible, and adds that if you suspect compromise, "it is important to preserve forensic evidence prior to applying updates, as updates may result in loss of forensic visibility."
• Mandiant's chief technology officer: "Upgrading alone will not eradicate post-exploitation access or address stolen credentials."
• NCSC orders its steps as isolate and replace the appliance, investigate for compromise with the published indicators, and only then install the updates.
• CERT-EU "strongly advise to run a compromise assessment on any internet-facing appliance running an affected build". eSentire goes further and says any internet-facing appliance that was unpatched in early September should be treated as compromised until an integrity assessment shows otherwise.
• Citrix says its generic indicators "might fail to identify actual compromises". A clean scan is one input, not a clean bill.

Two more labels deserve suspicion. A "security appliance" sits at the boundary and is trusted to police it. Mandiant notes that these devices "sit outside the reach of endpoint detection and response (EDR) tools", and that several logs its detections depend on are not forwarded by default. And "IoC scan complete" describes an activity, not a result.

The federal rule is stricter than the label. BOD 26-04 says that where a KEV entry carries "& forensic triage", the agency must complete remediation or mitigation within the three days and also carry out a forensic triage of the asset. Both KEV records for these flaws carry that flag. CISA's implementation guidance puts evidence collection before patching, and targets the triage analysis at 24 to 48 hours and the escalation decision at 48 to 72 hours. It calls those timings recommended and says the requirement is that an adequate triage is performed. An agency that patches on the third day and does no triage has not met the directive, whatever its patching dashboard says.

The public hunting guidance arrived on day 2. Mandiant's post is dated 29 September. Citrix's console scanner and CISA's alert were available from 27 September.

Why did Citrix take so long? What the record supports

The Register asks the question in its subtitle, and several people quoted in the coverage answer it with confidence. The record does not yet support a confident answer either way. That is not a defence of the vendor. It is a statement of what has been published.

What is fixed on the record about the timing, and what nobody with first-hand knowledge has stated. Press quotations are marked.

Fixed on the record	Not stated
Exploitation was documented from 5 September (eSentire) and 24 September (GreyNoise).	When Citrix first learned of exploitation, or of the flaws.
Citrix's first public statement that we found, the bulletin, came on 27 September with fixed builds.	Whether a fix existed before it was published, or how long building and testing took.
Private warnings from CERTs, suppliers and researchers circulated from at least 26 September (press reports).	Who warned whom first, and on what evidence.
All eight CVE IDs were reserved in one batch on 10 September, with NetScaler as the assigning body.	What that implies. Reservation is routine.
Citrix told CyberScoop it "recently identified" the flaws and moved to "immediately develop and release" a new version.	What "recently" means in days.
Citrix declined The Register's questions on the scope of the attacks and on why it did not alert the public until Sunday.	Any figure for how many customers were compromised.

watchTowr's chief executive told the press the flaws were "discovered during incident response and forensic investigations at organizations already compromised", so that Citrix's awareness "predated public disclosure". That is an inference from a firm that sells exposure management and has a record of pointed public comment about the vendor. It may be right. The published dates show exploitation predating the bulletin. They do not show when the vendor knew. A cyber insurer, Coalition, has said publicly that Citrix stayed silent for more than 36 hours after word of exploitation began to circulate. That is a fair measure of the weekend, not of the 22 days.

One piece of context, from the KEV feed itself. NetScaler has been listed on four dates in 2026: 30 March, 26 August, 9 September and 27 September, the last with two CVEs. Three of those dates fall within 32 days. That describes the patching workload, not any single disclosure.

What to hunt and harden, at defender level

Mandiant, Citrix, NCSC and CISA publish the exact strings, paths and detection rules. This briefing does not repeat them, so use their pages for specifics. What follows is the order worth working in, and what each step is for.

What we could not verify

The question this leaves

CISA and the vendors did what a list can do. Two flaws were being exploited, and both went on a three-day clock on the day of the bulletin. The clock is a fair rule for the fix. It is a blunt one for the harm, because the harm began before the list existed.

So the question for your own process: if a NetScaler of yours was reachable from the internet on 5 September, what evidence do you hold today that it was not compromised, other than the fact that it now runs a fixed build?

Key facts