Kiteworks Tells Customers to Shut Down Systems on Law Enforcement Warning
Kiteworks urged customers to shut down their Kiteworks systems on September 25, 2026, warning of an imminent threat of cyberattack. The company asked administrators to take systems offline before the weekend, if not sooner. TechCrunch
Chief information security officer Frank Balonis said the company received credible threat intelligence from law enforcement indicating a threat actor may attempt to target some Kiteworks customer systems. Kiteworks said it recommended a precautionary shutdown window while it and its law enforcement partners work through the matter.
Kiteworks said it was not aware of any compromise of its systems. It described the advisory as preventative rather than a response to a confirmed breach.
The September 25 email warned customers to protect against potential zero-day attacks. Kiteworks said it was concerned about exploitation of vulnerabilities currently unknown to the company.
The company said it fixed all known vulnerabilities in software release 9.5.1 and recommends all customers use that release. The patch guidance covers known issues. The shutdown guidance addresses the residual risk from unknown issues.
Regional timing was specific. 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. Its customer systems are typically operated by the customers themselves, which is why the advisory was directed at customer administrators and their maintenance windows.
The broader context here is the operational calculus of asking an installed base to go dark. Shutdown is crude. It works. It breaks automated workflows, partner exchanges, and internal data movement for the duration of the outage. For teams that run around-the-clock pipelines, even a six-hour window requires queueing, stakeholder notice, and restart validation. In this author's view, a vendor does not recommend that lightly, which is itself useful signal about how the threat intelligence was graded internally, even without seeing the underlying reporting.
Looking at what this means for defenders, the playbook is uncomfortable because there is no indicator to hunt for and no additional patch to verify. The verifiable steps are a version baseline on 9.5.1 and a network control. Disconnect, confirm build, restrict ingress on restart, and watch authentication and egress telemetry closely during return to service. Worth flagging for longer-term planning, architectures that can isolate transfer functions quickly without halting all business data flow will absorb this kind of advisory with less pain. That capability is worth building before it is needed, and preemption of this sort, when it succeeds, leaves little to dissect beyond continuity restored.
