Some NetScaler operators were told to shut their appliances down a day before any advisory existed, and the organisations that could act on that call had settled two things in advance.
—
On 26 September 2026, some NetScaler administrators received urgent private warnings. One described it plainly: “We got a call from our IT supplier’s security team, they couldn’t give any details but they advised to shut our Netscalers down immediately.” Others reported contact from law enforcement, CERTs and national cybersecurity agencies. At that point there was no CVE, no vendor advisory and nothing for a scanner to find, only an operational instruction with little explanation. BleepingComputer reported the sequence the following day.
The signal reaches well beyond Citrix customers. The first actionable warning about a critical, actively exploited flaw arrived through relationships rather than through a published advisory, and it asked for a business decision (take remote access offline) before any detail was available to justify it. Any organisation running internet-facing remote-access or application-delivery appliances can now expect to face that decision again, and whether it hears early at all depends on channels most risk programmes do not map.
What happened before Citrix published fixes
The Dutch National Cyber Security Centre, NCSC-NL, reportedly sent a pre-notification to organisations in the Netherlands. It said a European partner CERT had supplied information about two vulnerabilities, either of which could independently lead to remote code execution. No CVE identifiers had been assigned and Citrix had not published an advisory. The notice reportedly said Citrix had discovered the flaws while investigating incidents in customer environments and had submitted a notification under the EU Cyber Resilience Act. Asked to confirm, NCSC-NL declined, saying it could not provide information to organisations outside its constituency.
On 27 September, Citrix confirmed that two critical flaws, CVE-2026-88771 and CVE-2026-88772, had been exploited as zero-days and released fixed builds. Its security bulletin says exploitation of both on unmitigated deployments had been observed. The first flaw allows unauthenticated arbitrary command execution through improper input validation and affects all NetScaler ADC and NetScaler Gateway deployments, including their default configuration. The second can lead to remote code execution or denial of service when DTLS is enabled; Citrix says DTLS is enabled by default on VPN virtual servers.
The risk that matters sits in the interval before that bulletin. A warning can reach one organisation through its supplier or national CSIRT while another, running the same appliance, waits for a public advisory. That difference is set by relationships and reach, not by the quality of a vulnerability scanner.
The reporting window and the reach of a warning
The European Commission’s Cyber Resilience Act reporting rules have applied since 11 September 2026. Manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents. For an actively exploited vulnerability, the rules require an early warning within 24 hours of awareness, a notification within 72 hours, and a final report no later than 14 days after a corrective measure is available. A manufacturer reports through the CRA Single Reporting Platform to the CSIRT of its main establishment and simultaneously to ENISA. The receiving CSIRT shares the notification without delay with CSIRTs in other countries where the product is on the market. The obligations also cover products already on the EU market.
That route creates a structural possibility: national CSIRTs can hold information about active exploitation before a vendor’s public advisory exists. The NetScaler episode offers an early look at what such a period can feel like to an operator. The reported Dutch notice mentioned a CRA notification, but the public account does not establish that the Act produced this particular pre-notification, or trace every step by which the warning reached recipients. The lesson does not depend on that. Mandatory early reporting to a network of national CSIRTs makes this kind of interval more likely to recur, not less.
What is visible is how unevenly an early signal can travel. The reported NCSC-NL notice was intended for its constituency. An IT supplier could call its own customer. A security firm, watchTowr, said it was “rapidly reacting to rumors” and that, although details were scarce, “the information is credible.” None of those channels offered the same reach or certainty as a published vendor bulletin. Yet each could give its recipients time to prepare before fixes and technical details appeared. The Dutch notice reportedly framed its purpose in exactly those terms: because NetScaler upgrades can cause downtime, it was meant to give organisations time to get ready. It also warned that exploitation attempts could increase once patches and technical details were released, so organisations outside the early channels may begin preparing just as attacker interest rises.
For CIOs and CISOs, the practical question is whether those channels lead to someone who can act. Membership in a national CSIRT constituency, contact with relevant sector bodies, and clear escalation duties in supplier or MSP contracts form a relationship map. A generic alert inbox cannot make up for a warning that never reaches the organisation. Nor is receipt enough if the person answering the call has no route to the people who can weigh the business impact.
The decision to make before the detail exists
NetScaler appliances commonly sit at the internet-facing edge, providing remote access and application delivery. Compromise can give an attacker a foothold at the perimeter and a path towards internal systems without first compromising an internal endpoint. In this case, the reported early message was unusually stark: shut the appliances down, without details. The choice it posed was equally concrete. Keep remote access running while an actively exploited flaw may be present, or interrupt a service on information that has not yet been publicly confirmed.
That is a business-continuity decision, not simply a request for a technical team to interpret an alert. Senior management should agree in advance what makes a private warning credible enough to restrict or take an internet-facing remote-access service offline. The trigger might depend on who supplied the warning, whether it describes active exploitation, and whether it identifies a service the organisation actually runs. Those are questions to settle while teams can examine the source and their own exposure calmly, with people accustomed to judging emerging security signals working alongside the people responsible for the service.
The authority to act should be just as clear. A CIO, CISO, head of business continuity, supplier-contract owner and board risk committee have different roles in accepting an outage, testing the warning and understanding its consequences. Management needs an identified decision owner, a route for urgent escalation and a fallback access path that can support the business if the primary service is withdrawn. Those arrangements allow an organisation to use a credible but incomplete warning without treating every rumour as an instruction to shut down.
Once the advisory is available, the immediate guidance is to patch as soon as possible and reduce Internet exposure where operationally possible if patching cannot happen immediately. That work still matters. An earlier discussion of NetScaler edge appliances addressed what happens when a patch window is missed. This episode raises an earlier decision: whether the organisation can act during the interval when its best warning may be a call from a trusted contact, while the vendor’s public explanation is still to come.