Research

The weekend Kiteworks told customers to switch off

Kiteworks, a secure file-transfer vendor, advised customers to switch their systems off after a threat warning. Days later, it said a vulnerability found during the shutdown had been fixed and services could resume.

Warm-paper illustration of an unplugged file-transfer appliance beside waiting envelopes and a notice, representing work paused with the service.

In this article

AssessmentHigh

Published29 September 2026

UpdatedOctober 1, 2026

On 25 September 2026, Kiteworks advised customers to shut their servers down temporarily. The company provides secure file and data exchange, which customers use to send and collect sensitive material. Switching off would interrupt those legitimate transfers too.

The company cited a threat warning from a federal agency. It described the intelligence as credible and recommended a pause to guard against a possible attack. At the time of the notice, customers had no public vulnerability identifier, repair instructions or attack path corresponding to that warning.

1 A request to the whole customer base

The 25 September public advisory specified a nine-hour pause. Customers running their own systems on premises, on AWS or on Azure had to switch them off themselves; Kiteworks would handle its hosted environments. The advice applied to Kiteworks systems and explicitly excluded subsidiary brands including ownCloud, DRACOON and Zivver.

The early notice was shorter: BleepingComputer and SANS recorded six hours, while the contemporaneous public announcement specified nine. Time-zone conversion cannot explain the extra three hours, and the available material gives no reason.

The recommendation even covered systems without direct internet exposure. An administrator considering blocking only a public entry point would need to know how the attack could reach the application. The notice did not disclose that route, leaving customers little basis for deciding from their network configuration that they could safely make a smaller change.

In The Record's reporting, watchTowr's Jake Knott described asking an entire customer base to shut down production systems without a public CVE, patch or technical detail as highly unusual. He also cautioned that a vendor would not make that request on speculation alone. Kiteworks CISO Frank Balonis explained the credible federal intelligence warning and the precautionary nature of the advice. Customers were being asked to interrupt their work with limited detail available to assess the risk for themselves.

2 The vulnerability was found during the shutdown

On 27 September, an update to the original advisory lifted the shutdown recommendation. The following day, Kiteworks published a separate account of its findings. It said it had discovered a previously unknown critical vulnerability, repaired it and added protection across all environments. All customer systems could return to service, the company said.

The newly discovered flaw was confined to a feature enabled by fewer than 1% of customers, a much smaller group than those initially told to stop. That scope emerged during the shutdown; the investigation had not reached it when the warning arrived. Fewer than 1% describes feature enablement. Whether the flaw could be triggered, and whether data was read, still depends on specific configurations and records.

A threat warning and shutdown advice on 25 September, discovery and repair during the shutdown, then restoration advice on 27–28 September; fewer than 1% refers to feature enablement. — The sequence described in the company announcements. Fewer than 1% refers to customers with the feature enabled.

Another notice gives a clue to the feature's identity. The 27 September update specifically told self-hosted Advanced Forms customers to contact support. SecurityWeek's follow-up also pointed to Advanced Forms, drawing on a customer email reproduced online. The website provides a definite support instruction; the separate 28 September restoration announcement itself does not name the feature.

Kiteworks' forms documentation describes collecting data and feeding it into file sharing, email, MFT, SFTP and API workflows. Pausing an entry point like this can affect the people and applications waiting for that material. Which work stops depends on the business connections the customer has made.

3 What changes before the server comes back

What can a nine-hour shutdown change? The company has not published the original intelligence or explained whether it could reliably have narrowed the affected group, leaving too little to judge whether Friday offered a better choice. A more answerable question is what needs to happen during the pause before customers can switch back on.

SANS commentary on 25 September raised two practical considerations. Ed Skoudis supported prompt action on credible intelligence and argued that organizations should be able to stop services deliberately. Lee Neely pointed out that an attacker could change the timing. One accepts disruption now; the other asks whether the threat will still be there when the machines return.

A powered-down server stops handling new requests and leaves legitimate users without service. Restarting the same program nine hours later leaves the flaw in place, available to an attacker who returns another day. Repairing it, or establishing conditions for safe restoration, makes the interruption useful to the eventual recovery.

Kiteworks says it repaired the flaw and added protection during that interval, and reported no indication of compromise. Customer logs, monitoring coverage and a full investigation method remain unpublished, and no publicly documented intrusion can be identified as having been stopped by the shutdown. Whether an adversary acted as anticipated, and whether monitoring could see it, affects that assessment. Customers still need to confirm that the repair reached their own machines before switching them back on.

4 Which repair does 9.5.1 describe?

The 25 September advisory recommended 9.5.1 for issues already known. The flaw announced on 28 September was newly found during the shutdown. The notices do not explain how the later repair was delivered—a particular build, hotfix or another deployment action—or give a complete build number to check. Seeing 9.5.1 on the appliance therefore still cannot confirm that the additional repair is complete.

Customers managing their own systems can give Kiteworks support the installed version, full build information and whether Advanced Forms is enabled, then ask what their machine still needs and how to confirm the repair is complete. Self-hosted Advanced Forms customers have an explicit instruction on the website to contact support. Customers in vendor-hosted environments can also request confirmation for their own environment.

After obtaining that confirmation, use your own test accounts and non-sensitive files to check submissions, receipt, permissions and onward delivery. Check queued and retried work for missed or duplicate sends too. This establishes whether the business workflow has recovered; successful delivery alone cannot confirm that the vulnerability was repaired.

If a machine's repair is still unconfirmed, retain the temporary restrictions agreed with the vendor and arrange for the affected work. Avoid restoring an old snapshot with unknown repair status just to get service back quickly. Whether a single component can be paused requires advice for the actual deployment. The attack path has not been disclosed, leaving no basis for recommending one substitute for every customer.

The general shutdown advice was lifted on 27 September, so circulating the old notice can obscure the restoration update. Customers with suspicious access or data anomalies should still preserve their records and investigate. Repairing software does not account for earlier activity or retrieve information that may already have been sent out.

5 Could the next shutdown be smaller?

In its restoration statement, Kiteworks thanked customers who had given up a weekend at short notice and worked through the night. A single notice becomes on-call work, coordination, shutdowns and restarts when it reaches a customer. The vendor can publish a restoration message; customers still have to bring their own work back.

A smaller interruption next time requires administrators to identify enabled features, disable them separately where possible and understand which access path that blocks. The vendor needs to explain those operations from the implementation. Public material does not establish that disabling forms alone would have been sufficient this time; clear component inventories and dependencies could at least help customers assess the affected scope faster during the next warning.

Customers also need a plan for the work that remains when a service stops. Know who must be notified, which material can wait and which tasks already have approved alternative channels. The work does not disappear with the secure-transfer tool. Moving it to personal email or an unmanaged shared drive can expose the information that the shutdown was intended to protect.