The fix for the ShareFile Storage Zone Controller shutdown is two version numbers: 5.12.5 and 6.0.2. Progress Software confirmed on July 14 that a high-severity path traversal flaw in the Storage Zone Controller (SZC) — the on-premises file server component of ShareFile — is what forced the shutdown order, and that installing one of those two builds is what clears a controller to go back online.
Quick take
Progress patched the July zero-day in Storage Zone Controller versions 5.12.5 and 6.0.2 — install one of those before powering a controller back on.
The shutdown order applies only to self-hosted Storage Zone Controllers; standard cloud-only ShareFile accounts kept working throughout.
Progress says it has no evidence of unauthorized account or data access, but that statement does not cover the controllers themselves, which sit on customer networks.
A separate, earlier flaw, CVE-2026-2699, is already fixed in 5.12.4 and is not the vulnerability behind this shutdown.
Progress’s own guidance answers the isolate-versus-migrate question directly: keep the ShareFile Storage Zone Controller offline until it runs 5.12.5 or 6.0.2, then bring it back — nothing in the vendor’s advisory or the confirmed vulnerability points toward migrating to a different storage architecture.
What actually happened, in order
Progress emailed ShareFile customers running self-hosted Storage Zone Controllers on July 10, instructing them to manually power down the Windows servers hosting the software over a “credible external security threat” the company did not describe. It disabled cloud access for those accounts at the same time, and its status page listed Storage Zone Controller as “not operational” as of a 12:12 p.m. EDT update that day.
Cloud access came back before the root cause did. Progress told customers that ShareFile cloud service access was restored by 5 p.m. ET on July 12, but that Storage Zone Controllers had to stay powered off while the investigation continued.
Throughout the initial phase, Progress repeated one line: it has “no evidence of unauthorized access to any ShareFile customer account or data, and we have not identified any active threat”. That statement covers ShareFile accounts and cloud data — it says nothing about whether an on-premises controller itself was touched, since those run on customer infrastructure Progress doesn’t monitor.
Progress confirmed the mechanism on July 14: a high-severity path traversal vulnerability affecting all 5.x and 6.x releases of Storage Zone Controller, letting an authenticated administrative user read arbitrary files reachable by the application’s service account, write attacker-controlled content to arbitrary directories, or enumerate the server’s filesystem layout.
“Our investigation then revealed a vulnerability that we promptly patched before it was publicly known,” Progress told BleepingComputer, describing how a tip about a possible threat led to the discovery.
Progress reserved a CVE identifier for the July flaw but said it would publish the number two weeks later, telling BleepingComputer that withholding disclosure gives customers time to patch before attackers get the same detail — standard practice for the company.
Two other vulnerabilities that are not this one
Watch out
Being current on 5.12.4 does not mean you were protected from the July incident — that version closes CVE-2026-2699, a separate, already-patched flaw, not the path traversal disclosed on July 14.
Confirm your build against both fixes before assuming a controller is safe to restart.
NVD’s public record for CVE-2026-2699 describes a distinct, already-closed issue: an unauthenticated attacker reaching restricted Storage Zone Controller configuration pages, with potential to change system configuration and achieve remote code execution, rated 9.8 on the CVSS 3.1 scale under Progress’s own CNA scoring. Affected versions run through 5.12.3, and the fix landed in 5.12.4.
That vulnerability’s disclosure record predates July’s shutdown, and Progress has not linked the two incidents. Treat CVE-2026-2699 as a distinct, resolved bug worth confirming you’ve already patched — not as coverage for the path traversal flaw that triggered the shutdown.
The pattern itself isn’t new. In 2023, when Storage Zone Controller still belonged to Citrix, attackers exploited CVE-2023-24489, an unauthenticated access-control flaw affecting versions up to 5.11.24 and the 5.12.x line up to 5.12.4 — and Citrix’s response was the same move Progress just repeated: cut unpatched controllers off from the ShareFile cloud.
| Incident | Affected versions | Fixed in | Nature |
|---|---|---|---|
| CVE-2023-24489 (2023, Citrix era) | up to 5.11.24 and 5.12.x up to 5.12.4 | 5.12.4 | Unauthenticated access control flaw |
| CVE-2026-2699 | up to 5.12.3 | 5.12.4 | Unauthenticated config-page access, CVSS 9.8, potential RCE |
| July 2026 shutdown flaw | all 5.x and 6.x | 5.12.5 / 6.0.2 | Authenticated path traversal, arbitrary file read and write |
Deciding isolate, migrate, or keep offline
For any organization currently running a self-hosted Storage Zone Controller, the decision Progress’s own advisory supports is narrow: keep it powered off until it is rebuilt on 5.12.5 or 6.0.2, then restart — the evidence does not justify a full migration to a different file-sharing architecture on its own.
Migration becomes a separate conversation only if your controller was internet-facing during the exposure window and you find signs of prior compromise, since that shifts the question from patching to incident response.
- Confirm your build number against 5.12.4 (patches CVE-2026-2699) and 5.12.5 or 6.0.2 (patches the July path traversal flaw) before assuming you’re covered.
- If the controller was reachable from the internet, preserve IIS and application logs before any rebuild or restart.
- Check web folders for unfamiliar .aspx files and storage paths you did not configure — signs consistent with a webshell on this product class.
- Watch the ShareFile status page and Progress’s customer notices for the CVE identifier, due roughly two weeks after the July 14 disclosure, and confirm it names your build as unaffected once published.
None of this requires assuming compromise. Progress’s position, as of its confirmation, is that it has no indication customers were breached — but that assessment is the vendor’s own, not an independently verified one.
What the evidence doesn’t establish
The evidence doesn’t establish who reported the “credible external security threat” that started this, whether the path traversal flaw was being actively exploited before Progress patched it, or how many organizations had internet-facing controllers during the exposure window.
It also doesn’t establish whether the July flaw is related to the vulnerabilities Progress fixed earlier in the year, since the company has explicitly declined to draw that link.
Before you restart
The one number worth checking against your own environment is the build: 5.12.5 on the 5.x line, or 6.0.2 on 6.x, are the versions Progress says close the flaw behind this shutdown. Anything short of that, including a controller already on 5.12.4, is not patched for the July issue.
If your controller was internet-facing at any point before July 10, treat the log-preservation step as mandatory rather than optional, and hold off on the restart until that review is done — a clean-looking filesystem is not the same as a confirmed-clean one.