Kiteworks Tells Customers to Go Offline Ahead of Possible Zero-Day Attack
Kiteworks told customers on September 25, 2026, to shut down their Kiteworks systems over an imminent threat of cyberattack. Administrators were asked to take systems offline before the weekend, if not sooner. TechCrunch
Chief information security officer Frank Balonis said the company had received credible threat intelligence from law enforcement. That reporting indicated a threat actor may attempt to target some customer systems. Kiteworks said the precautionary shutdown would give it and its law enforcement partners time to work through the matter.
Kiteworks said it was not aware of any compromise of its systems. It described the advisory as preventative, not a response to a confirmed breach.
The September 25 email warned about potential zero-day attacks, meaning attacks that exploit flaws still unknown to the vendor and therefore without a fix. Kiteworks said it was concerned about exploitation of vulnerabilities currently unknown to the company.
The company said it has fixed all known vulnerabilities in software release 9.5.1 and recommends all customers run that version. The patch covers known issues. The shutdown addresses the remaining risk from unknown issues.
Timing was specific by region. For customers in Central Europe, Kiteworks recommended shutting down all systems on Saturday, September 26, from 4 a.m. to 10 a.m. heise online
Kiteworks, formerly named Accellion, makes tools for transferring large files and sensitive datasets over the internet. Those systems are typically run by the customers themselves, which is why the advisory was aimed at customer administrators and their maintenance windows.
The broader context here is the tradeoff in telling an installed base to go dark. Shutdown is crude but effective. It stops automated workflows, partner exchanges and internal data movement for the duration. For teams with round-the-clock pipelines, even a six-hour window means queueing work, notifying stakeholders and checking systems on restart. In my view, a vendor does not ask for that lightly, which says something about how seriously the threat intelligence was taken internally, even without seeing the underlying report.
Worth flagging for defenders, the checklist is short because there is no indicator to hunt for and no extra patch to verify. The steps that can be verified are confirming version 9.5.1 and controlling network access. Disconnect, confirm the build, limit incoming connections on restart, and watch login activity and outgoing data closely during return to service. For longer-term planning, setups that can isolate the file-transfer function quickly without stopping all business data flow will absorb this kind of advisory with less disruption, and that isolation is easier to build before it is needed.
