Progress Software’s July 10, 2026 email to ShareFile customers carried one instruction and almost no explanation: shut down the server hosting the Storage Zone Controller now, before any patch existed for whatever was wrong.
Quick take
The July 10 shutdown order went out before Progress had named, patched, or published a CVE for the flaw behind it.
Progress restored ShareFile cloud access at 5 p.m. ET on Sunday, July 12, while telling customers to keep Storage Zone Controllers powered off.
On July 14, Progress confirmed a path traversal flaw in Storage Zone Controller versions 5.x and 6.x and shipped patches 5.12.5 and 6.0.2.
Progress said its investigation found no evidence of unauthorized access to ShareFile customer accounts or data.
The ShareFile Storage Zone Controller shutdown left administrators with exactly one continuity path documented in the vendor’s own communication: keep using ShareFile through the cloud service, and accept that anything routed through the on-premises controller stayed unreachable until Progress said otherwise.
That gap between order and explanation matters because two separate ShareFile vulnerabilities are now in play, and conflating them leads to the wrong recovery decision.
Back in April 2026, Progress disclosed CVE-2026-2699 and a companion flaw, CVE-2026-2701, which could be chained by an unauthenticated attacker into remote code execution against internet-facing Storage Zone Controllers. Progress patched that chain in the months before the July shutdown order.
The July 10 email did not reference either CVE. Progress instead described a “credible external security threat” targeting Storage Zone Controllers, with no version list, no indicator of compromise, and no timeline beyond a promise to follow up within 24 hours.
Four days later, on July 14, Progress updated its guidance: a high severity path traversal vulnerability in Storage Zone Controller versions 5.x and 6.x let an authenticated administrative user read arbitrary files, write attacker-controlled content to arbitrary directories, and enumerate the server’s filesystem. Fixed versions 5.12.5 and 6.0.2 became available the same day.
Two Different ShareFile Flaws, One Shutdown Order
The distinction below is the one worth checking against your own patch inventory, because the April flaw and the July flaw have different attacker prerequisites and different fixed versions.
| Attribute | April 2026 chain (CVE-2026-2699 / CVE-2026-2701) | July 2026 disclosure |
|---|---|---|
| Authentication required | Unauthenticated attacker | Authenticated administrative user |
| Affected versions | 5.12.3 and prior | 5.x and 6.x, fixed in 5.12.5 and 6.0.2 |
| Severity score published | 9.8 CRITICAL, CVSS 3.1 | Not published at time of the July 14 update |
| Linked by Progress to the shutdown order | No — Progress has not tied the current incident to these CVEs | Yes — named as the cause in the July 14 update |
Reading the table against the timeline explains why early outside analysis guessed wrong: without a named CVE, both journalists and defenders had to reason from precedent, and the closest precedent was the April chain.
What Continuity Looked Like During the ShareFile Storage Zone Controller Shutdown
Progress’s own statement to The Register is the clearest record of the continuity boundary: cloud access to ShareFile accounts using Storage Zone Controllers was restored at 5 p.m. ET on Sunday, July 12, but “Storage Zone Controllers must remain turned off while we complete our investigation”.
Practically, that split cloud identity and authentication from on-premises file access. Customers could sign into ShareFile again, but any files served through their own Storage Zone Controller stayed unreachable until the server came back up.
No configuration workaround or interim patch existed at the point the shutdown order was issued, which is why “shut it down” was the only mitigation Progress offered for several days.
The SANS Internet Storm Center’s July 13 recording flagged a second problem: Progress’s email had promised an update within 24 hours, that window had already passed, and the public ShareFile status page still listed the issue as unresolved. For a continuity plan, that meant treating “cloud access restored” and “incident resolved” as two different milestones, not one.
Watch out
Don’t assume the July shutdown reused the April CVE-2026-2699/CVE-2026-2701 chain just because it’s the only prior public Storage Zone Controller disclosure — Progress explicitly did not link the two, and the confirmed July flaw needed an authenticated admin session, not an anonymous attacker.
Security Arsenal’s July 10 technical note inferred an “external, unauthenticated network access via the SZC web interface” attack vector before any vendor confirmation existed, based on the pattern of past file-transfer appliance bugs rather than evidence specific to this incident. That inference did not match what Progress confirmed on July 14, which is a useful reminder that pre-disclosure threat write-ups describe plausible mechanisms, not verified ones.
Reddit speculation captured by The Register followed the same logic, guessing at “an unauthenticated RCE being exploited in the wild” from the severity of the shutdown instruction alone. Neither guess lines up with the authenticated path traversal mechanism Progress ultimately confirmed.
Recovery Evidence to Retain Before Powering Back On
Before bringing a Storage Zone Controller back online, keep a written record that ties the restart decision to the vendor’s actual disclosure rather than to the shutdown email’s vague language.
- Confirm the installed build matches the patched release: 5.12.5 for the v5 line or 6.0.2 for the v6 line, not just “a recent update”.
- Keep the original July 10 shutdown email and the July 14 follow-up together as the incident timeline of record, since Progress reserved a CVE for the July flaw but had not published it as of the July 14 update.
- Retain Progress’s written statements that its investigation found no evidence of unauthorized access to ShareFile customer accounts or data.
- Check the ShareFile status page directly rather than treating restored cloud sign-in as proof the on-premises issue is closed.
- If the controller was internet-facing before the shutdown, review IIS worker process activity for shell-spawning children before trusting its pre-shutdown state.
Progress has not published the reserved CVE identifier for the July path traversal flaw, and neither Progress nor the outside coverage reviewed here states whether the “credible external security threat” that triggered the July 10 order was ever actually exploited against a customer.
That gap is the one to price before treating the incident as closed: a confirmed, patched vulnerability is not the same claim as a confirmed absence of exploitation, and the available statements only support the latter as “no evidence found,” not “no compromise occurred”.
Before flipping a Storage Zone Controller back on, confirm the installed build number against 5.12.5 or 6.0.2 and file that check next to Progress’s no-evidence-of-compromise statement as the recovery record for this incident.