On July 10, 2026, Progress Software did something remarkable. Acting on a tip about a "credible external security threat" — before confirming a specific vulnerability — Progress disabled cloud access for every ShareFile account tied to a Storage Zone Controller and told those customers to physically power down the Windows servers running them. Not "apply this patch," but “shut it off.” Days later, the investigation identified the underlying problem: a high-severity zero-day, with patched versions released alongside the public disclosure.That's extraordinary. A major vendor took its own service and its customers' production infrastructure completely dark before publicly identifying the specific vulnerability involved.
Firstly, it's commendable, decisive and safety-first. Progress deserves credit for taking that step.
The shutdown wasn't an overreaction. The legacy architecture of its Storage Zone Controller solution appears to have left few practical alternatives and will likely continue to do so.
Few Alternatives: Scar Tissue Meets the AI Clock
To be clear, the security response itself was exemplary. Progress acted before the underlying vulnerability was publicly disclosed, accepted service disruption over customer risk, and communicated clearly. The interesting question isn't whether they responded correctly—it's why the architecture required such an extreme response in the first place.
Progress has lived this before. Through 2023 and 2024 it dealt with the MOVEit fallout, where Cl0p mass-exploited a zero-day in its file transfer software into one of the largest supply-chain breaches on record.
That lesson lands harder now. Improvements in exploit automation, including AI-assisted vulnerability research, is shortening the time between vulnerability disclosure and attempted exploitation. Proof-of-concept code emerges quickly, while automated internet scanning allows attackers to identify exposed systems at scale. The window between disclosure and compromise continues to shrink.
The Architecture Problem: The Worst of Both Worlds
What makes this ShareFile design particularly punishing is that it requires customers to have two distinct attack surfaces with limited or no control over either.
Attack Surface 1: a vendor-operated SaaS control plane holding security-sensitive identity and authorization data. ShareFile's cloud handles authentication, permissions, and collaboration, so the vendor's platform holds user identities, access relationships, and authentication state. It's a target you don't operate and can't harden.
Attack Surface 2: a Windows web server on your own Internet perimeter. To keep files on-premises, customers deploy a Storage Zone Controller — an internet-exposed Windows server running the vendor's code.
Both a foothold and a bridge: Importantly, the Storage Zone Controller is not just a file gateway. In many deployments, it is a Windows server connected to Active Directory, file shares, and collaboration platforms. If compromised, it becomes both a foothold and a bridge into higher-value internal company systems.
- In customer deployments, ShareFile's documentation describes wiring up access to both internal SharePoint servers and Network File Shares via Active Directory domain membership.
- The SaaS and on-prem attack surfaces are connected by design. Per Progress's architecture docs, a “storage zones controller configured for standard zones must accept in-bound connections from the ShareFile cloud." This is important; the ShareFile SaaS platform communicates directly with customer on-prem servers. It creates an architectural trust relationship between the cloud service and an internet-facing server residing in a customer environment. Any compromise of that trust relationship would become a high-value avenue for attackers seeking access to customer environments.
So the customer holds two attack surfaces: a vendor-operated SaaS control plane and a high-value Windows server exposed as part of its own Internet perimeter. All while ultimately depending on the vendor to secure one and to produce fixes for the other.
An Unnecessary Trade-off
Customers deploy a Storage Zone Controller: not for more attack surface, but as a way to have data sovereignty — keeping files in their own environment, under their own governance and residency rules, instead of a vendor's cloud. That's a legitimate goal.
However, that control carries meaningful costs. To keep files within its own environment, a customer deploys a vendor-supplied Windows server on its perimeter, potentially integrates it with Active Directory and internal content sources, and depends on the vendor to diagnose vulnerabilities and produce fixes. Because the controller must ultimately make files available to authorized users, a sufficiently privileged compromise of the application or host may expose file contents in plaintext.
It is data custody purchased by adding a high-value attack surface to the customer’s environment. When an urgent threat emerged, the affected infrastructure was located on the customer’s network—but remediation still depended on the vendor.
End-to-end encryption offers a different model. When the service operator never possesses the keys required to decrypt file contents, compromising only the service or storage layer does not automatically expose plaintext. Control derives from cryptography rather than solely from where the encrypted bytes reside.
That's the SendSafely model. Our end-to-end encryption is designed so that SendSafely does not possess the keys required to decrypt your files. Want custody of the encrypted bytes too? Backend your SendSafely instance with an S3 bucket you control — the encrypted data sits in storage you own and govern, with no Windows web server, no domain-joined foothold, nothing on your perimeter to defend. Data control without the high-risk attack surface — exactly what customers were trying to buy with a Storage Zone Controller in the first place.
End-to-end encryption does not eliminate every attack. Metadata, identities, availability, and endpoint compromise remain important concerns. But it fundamentally changes the consequences of server compromise because the platform itself never possesses the plaintext.
The uncomfortable takeaway
The lesson isn't that ShareFile had a vulnerability. Every mature software platform eventually will. The lesson is that this architecture required customers to expose a trusted, internet-facing Windows server inside their own environment—and when uncertainty arose, the safest response was simply to turn it off.
This isn't unique to ShareFile. Many hybrid file-sharing architectures make similar trade-offs between data residency and operational complexity. ShareFile simply provides a very visible case study because the response was so public.
This event should prompt the real question: Why are we having to host this at all?
Our next post takes that up: why being forced to self-host infrastructure you can't secure is a losing game across the whole file transfer industry — and how end-to-end encryption and serverless architecture finally let you stop.