Kiteworks: Vendor Recommends Shutdown on September 26—What Is Known So Far

On September 25, 2026, Kiteworks asked its customers by email to shut down all Kiteworks systems on Saturday, September 26, from 4:00 a.m. to 10:00 a.m. (Central European Time). According to the letter from CISO Frank Balonis, the vendor has received indications from law enforcement agencies that an attack on Kiteworks systems may be imminent that weekend. Customer support cited protection against potential zero-day attacks as the reason for the shutdown. heise online confirmed the authenticity of the message with support by phone.

Timeline

All times are Central European Summer Time (CEST). Where no time is given, no reliable time information is available.

1. Fri, September 25

   Advisory to customers

   CISO Frank Balonis informs customers by email about indications from law enforcement agencies of a possible attack that weekend and recommends a six-hour shutdown. According to the advisory, all known vulnerabilities are fixed in version 9.5.1.

2. Fri, September 25

   Initial media reports

   heise online reports that Kiteworks Support confirmed the authenticity of the message and cited protection against potential zero-day attacks as the reason for the shutdown. TechCrunch, BleepingComputer, Computer Weekly, and others follow shortly afterward.

3. Fri, September 25, 5:41 p.m.

   BKA does not comment

   heise adds: The BKA declines to comment for investigative reasons. The BSI does not respond, while the FBI declines to comment to TechCrunch.

4. Fri, September 25

   Statement and press release

   Kiteworks describes the shutdown as a precautionary measure with no known compromise. The press release cites “federal intelligence authorities” as the source and lists unaffected subsidiaries, including totemo. The vendor shuts down instances hosted by Kiteworks itself.

5. Sat, September 26, 4:00 a.m. to 10:00 a.m.

   Shutdown window

   The window takes place simultaneously worldwide: 2:00 a.m. to 8:00 a.m. UTC, 12:00 p.m. to 6:00 p.m. in Sydney, and Friday 10:00 p.m. to Saturday 4:00 a.m. in New York.

6. Sat, September 26, 10:00 a.m.

   End of the window

   The window stated in the customer email ends. The formal lifting of the recommendation follows on September 27.

7. Sun, September 27

   Recommendation lifted

   Kiteworks adds to the press release: The shutdown recommendation is lifted for all customers, and systems may resume operation. Hosted instances are back in service. Customers self-hosting Advanced Forms should contact support.

8. As of Mon, September 28

   Still unresolved

   No public advisory, no CVE number, no new version, no indicators, no information about the vulnerability, and no reports of a successful or attempted attack.

What is known

The recommendation applies worldwide; the email gives the time window for all time zones from AEST to PDT. Kiteworks advises shutting down systems before the start of the window, including systems that are not reachable from the internet.

Almost everything else remains unclear: there is no public security advisory, no CVE number, no patch, and no indication of which products or versions are affected. The press release cites “federal intelligence authorities” as the source, presumably U.S. federal agencies; which ones are unknown. As of September 28, there is no entry under Security Updates or in Kiteworks’ GitHub advisories; the most recent GitHub entry is dated May 27, 2026. Publicly available are the statement quoted above and the press release from September 25.

Kiteworks CISO Frank Balonis gave TechCrunch the same statement verbatim. The BKA declined to comment to heise for investigative reasons, and the BSI did not respond. The FBI declined to comment to TechCrunch, while a CISA spokesperson declined to comment publicly. According to TechCrunch, a customer in the healthcare sector immediately took its server offline, causing noticeable operational disruptions: doctors could reach their patients only with delays at times. According to a security researcher quoted by TechCrunch, at least 1,000 Kiteworks systems are reachable from the internet; BornCity reports that more than 1,000 organizations received the warning.

The press release differs from the customer email on one point: it refers to a nine-hour shutdown window, while the customer advisory refers to six hours. According to the press release, the recommendation applies only to self-operated installations (on-premises, AWS, Azure). According to the vendor, its subsidiaries Zivver, DRACOON, totemo, ownCloud, WAMNET, Maytech, Bonfy.ai, and 123FormBuilder are not affected.

The advisory to customers

In addition to the warning, the customer email from September 25 includes a schedule for each time zone and instructions for clusters. Converting the times to UTC yields the same 2:00 a.m. to 8:00 a.m. UTC window for all regions.

For clusters with multiple servers, Kiteworks specifies a fixed sequence:

1. Enable maintenance mode under System Setup > Maintenance Mode so users can no longer access the system.

2. Create a backup: Take a snapshot of each node or back up the Kiteworks database (System Setup > Cluster Configuration > System Configuration). Only one database backup is retained; each new backup replaces the previous one.

3. Record roles: Under System Setup > Locations, the Assigned Roles column shows which nodes have the Application role; the primary Application node is marked with an asterisk. Record the nodes and their IP addresses, as they are needed for the restart.

4. Shut down in this order: First all nodes without the Application role, then the remaining Application nodes, and finally the primary Application node. This can be done through the Shut Down tab of the respective node or through the hypervisor console (such as VMware or AWS) if the Kiteworks interface is no longer accessible.

5. Restart in reverse order through the hypervisor, because the admin console becomes accessible only once enough nodes are running (Appendix E of the Administrator Guide): first the primary Application node, then the remaining Application nodes one at a time and only after the preceding node is fully running, so that the database servers can form a quorum. Then restart the storage servers, followed by the remaining roles (Repositories Gateway, Search, SFTP, Antivirus), and finally the web servers.

6. Disable maintenance mode once all nodes are green in the Cluster Health Dashboard on the admin console status page.

When asked, Kiteworks Support also confirmed that none of Kiteworks’ subsidiaries are affected.

Possible causes: theories

Until Kiteworks publishes details, the cause remains unclear. The following explanations are hypotheses that can be derived from the known facts; some are also discussed in comments on the heise report. None has been confirmed.

Three facts narrow the possibilities. First, the warning names a fixed time window rather than an indefinite shutdown until a patch is available. Second, even systems not reachable from the internet are to be taken offline. Third, the window falls at the same time worldwide (2:00 a.m. to 8:00 a.m. UTC), rather than during local nighttime in each region. A classic vulnerability exploitable over the internet would not explain the first two points: disconnecting the system from the internet would protect against it, and should continue until a patch is available.

1. Authorities know of a planned date

Law enforcement agencies occasionally learn of the timing of a planned campaign in advance, for example from monitored communications of an attacker group or seized infrastructure. Mass exploitation of file-sharing products typically occurs in a short, coordinated window, often on weekends or holidays when fewer staff are on duty. Kiteworks is the successor to Accellion, whose File Transfer Appliance was attacked in exactly this way in 2020 and 2021, at the time attributed to the Clop group: data was exfiltrated through several vulnerabilities, after which the affected organizations were extorted.

The narrowly defined weekend window supports this theory. Against it is the objection raised by several commenters at heise: the warning went to all customers, so attackers are likely to know about it and can simply postpone the attack. However, a delay would give the vendor time to develop a patch.

2. The vendor does not yet know the vulnerability itself

It is also possible that, apart from the tip from authorities, Kiteworks has no technical details, meaning it knows neither the affected component nor a patch or configuration change it can recommend. In that case, shutting down is the only measure that works without knowledge of the vulnerability, and the fixed end time is a compromise customers are more likely to accept. heise commenters speculate that the vendor could leave individual systems online as bait during the window to observe the attack. There is no evidence of this.

Supporting this theory is that neither an advisory nor a mitigation has been named. Against it is that Kiteworks says it works with Mandiant and, when authorities issue a warning, indicators are generally at least available.

3. A previously planted backdoor with a time trigger

The recommendation to shut down internal systems as well fits a scenario in which the attack does not come from outside but has already been prepared on the appliances: for example, a backdoor from an earlier compromise that activates at a fixed time or contacts a command-and-control server. A system that is switched off cannot execute anything at that time.

Supporting this theory is that internet reachability plays no role in this scenario. Against it is that, in such a case, a vendor would be more likely to recommend checking for compromise and reinstalling than restarting after six hours.

4. Compromise on the vendor side

Another path to internal systems is through connections initiated by the appliance to the vendor, such as for updates, license verification, or remote maintenance. If such a channel is compromised, a firewall does not protect against inbound traffic. In this scenario, the shutdown would give the vendor a window to clean up its own infrastructure, replace keys or certificates, and permit connections again only afterward.

The uniform worldwide time supports this theory, as it fits a coordinated action on the vendor side. Against it is that the vendor would be more likely to recommend blocking outbound connections rather than shutting systems down completely.

5. A supporting measure for a law enforcement operation

Finally, it is conceivable that authorities are taking action against attacker infrastructure during the same period and want to prevent attackers from striking quickly in response. This would explain the short window and the role of law enforcement. The BKA’s refusal to comment for investigative reasons points to ongoing investigations, but does not prove this scenario.

Criticism of the communication

Skepticism predominates in the heise comments, and the objections are factually understandable: without information about the vulnerability, it is impossible to assess whether disconnecting from the internet by firewall would have been sufficient. A time window without an announced patch leaves unclear what applies after 10:00 a.m. And a warning sent only by email to customers does not reach all operators, for example those at partners, service providers, or after staffing changes. Regardless of which theory is correct, anyone operating Kiteworks should review logs after bringing systems back up and monitor the vendor’s channels until an advisory is available.

After the window: What operators can do now

Kiteworks lifted the shutdown recommendation on September 27 but has not published technical details. It is therefore impossible to assess whether or how the threat was eliminated. The following steps make sense when bringing systems back up and afterward:

1. Check the version: Is version 9.5.1 running on all nodes? According to the vendor, all known vulnerabilities are fixed in it.

2. Check cluster status: All nodes should be green in the Cluster Health Dashboard, and maintenance mode should be disabled.

3. Review logs: Examine logins, administrator actions, and unusual file downloads around the shutdown window, especially on systems that were not shut down or were shut down late.

4. Restrict accessibility: Where possible, block internet access to the administration interface and expose only required services.

5. Advanced Forms: Anyone self-hosting the module should clarify the restart with Kiteworks Support beforehand.

6. Monitor channels: Monitor Kiteworks’ Security Updates, GitHub advisories, Newsroom, and customer emails until an advisory with technical details is available.