The past month has highlighted just how difficult zero-day vulnerability response is becoming, with Citrix NetScaler, Kiteworks, Fortinet, Palo Alto Networks and a succession of other major vendors bringing internet-facing infrastructure into the spotlight.
From vendors recommending emergency shutdowns to security teams deploying patches with almost no technical detail, the response to recent vulnerabilities suggests the cybersecurity industry is entering a new phase of crisis management. The combination of dormant vulnerabilities, increasingly capable threat actors and the growing use of AI is putting pressure on organisations to act faster than ever before.
Zero-days are changing how organisations respond
The month began with reports of active exploitation targeting Citrix NetScaler systems through two zero-day vulnerabilities, CVE-2026-88771 and CVE-2026-88772.
The reported response highlighted the challenges organisations face when vendors are slow to communicate the details of active attacks. Citrix initially provided limited public information before releasing patches addressing eight vulnerabilities, leaving defenders to make difficult decisions about their exposure and the urgency of remediation.
Meanwhile, data protection provider Kiteworks took a more unusual approach, reportedly advising customers to shut down affected systems for nine hours in response to intelligence about an imminent zero-day attack affecting approximately 1% of its customer base.
The contrast between these responses illustrates the difficult balance between maintaining business operations and taking potentially disruptive action to prevent a breach. For organisations handling sensitive or regulated information, the consequences of getting that decision wrong can be substantial.
Customers are no longer waiting to be told to shut systems down
Perhaps more interesting were two critical PHP vulnerabilities that prompted widespread precautionary action from users without vendors having to instruct customers to take their systems offline. This was seen happening a lot across New Zealand and Australian organisations.
Organisations increasingly appear willing to accept operational disruption rather than risk remaining exposed while waiting for a definitive advisory or patch.
This shift is significant. Security teams have traditionally balanced vulnerability severity against the likelihood of exploitation, the availability of mitigations and the potential impact of an emergency change. That process becomes much harder when there is uncertainty about whether an attack is imminent or whether a vulnerability has already been exploited.
The growing volume of criminal cyber activity, combined with concerns about how AI could accelerate vulnerability discovery and exploitation, is changing that calculation.
When the potential cost of waiting outweighs the cost of disruption, taking a system offline can become the most defensible decision available.
Fortinet challenges the traditional patching process
Fortinet added another complication by releasing patches through its normal process, followed days later by an advisory urging customers to install an upcoming update because of significant security concerns.
The unusual aspect was the limited technical detail initially available to help customers understand the underlying risk.
Normally, security teams examine vendor advisories to determine which products, configurations and components are affected. This allows them to prioritise vulnerable systems, assess whether their own environments are exposed and avoid unnecessary emergency deployments.
When a vendor signals that an update is urgently required but provides little information about the reason, that established process becomes difficult to follow.
In this case, organisations were reportedly prepared to accept the vendor’s warning and begin urgent patch deployment without the level of technical detail they would ordinarily expect.
That raises an important question for the vulnerability management industry. What happens to security services whose value depends on analysing vendor disclosures to determine whether a particular update affects a customer’s environment?
Companies such as ThreatSabre operate in a space where contextualising vulnerabilities and helping organisations prioritise remediation are important parts of the value proposition. When vendors withhold the information required to perform that analysis, third-party security tools and services have less to work with.
The problem is not necessarily that organisations should refuse to patch without detailed information. It is that the traditional model of evidence-based patch prioritisation becomes much harder when the evidence is unavailable.
Palo Alto Networks and the exposure of internet-facing infrastructure
Palo Alto Networks also faced a vulnerability described as requiring no authentication and being readily automatable, with access to a traffic-processing interface identified as a key prerequisite.
For internet-facing firewalls, that type of exposure is particularly concerning. Interfaces processing network traffic are fundamental to the operation of these devices, meaning that organisations cannot simply assume the vulnerable functionality is isolated from untrusted networks.
When a vulnerability is remotely exploitable, requires no authentication and can be exploited at scale, the time available to defenders may be extremely limited.
Add urgent patching activity involving F5, Juniper SRX and Cisco infrastructure, and the result is a challenging period for almost every organisation responsible for maintaining an internet perimeter.
Firewalls, application delivery controllers, VPN gateways and other edge devices are attractive targets because they sit at the boundary between trusted environments and the internet. A successful compromise can provide opportunities for initial access, traffic interception, credential theft or further movement into corporate networks.
These are also systems that organisations cannot always patch casually. Changes can affect connectivity, remote access, customer-facing services and critical business operations.
Is this the new normal?
The events of September and October 2026 point towards a difficult period for vulnerability management teams.
The traditional process of waiting for a vendor advisory, assessing exposure, testing a patch and deploying it through an established change-management process assumes that defenders have enough time and information to make those decisions.
That assumption is becoming increasingly difficult to sustain.
Vendors may have to respond to active exploitation before they have completed their investigations. Security teams may have to make decisions based on incomplete information. Organisations may increasingly choose to take systems offline rather than risk an incident, while vulnerability management providers face pressure to deliver meaningful advice when the underlying technical details are unavailable.
For the next 18 months, organisations may need to prepare for continued disruption as more previously undisclosed vulnerabilities are discovered by vendors and threat actors alike. Whether this period ultimately gives way to greater stability remains uncertain.
In the meantime, security teams should prepare for a world where emergency patching is no longer an occasional exception.
Organisations should prioritise internet-facing infrastructure, maintain accurate asset inventories, establish emergency change processes and ensure that backups and recovery procedures are tested. They should also agree in advance on who can authorise disruptive actions, including taking critical services offline when the risk justifies it.
The uncomfortable reality is that the time between a vulnerability becoming known and being exploited may be shorter than the time an organisation needs to assess, approve and deploy a fix.
For defenders, speed and preparedness are becoming just as important as technical capability.
