ShareFile Shutdown: Reporting a Breach With No CVE, No Patch, No IOCs

On the evening of 9 July 2026, Progress Software emailed a subset of its ShareFile customers with an instruction that reads like a fire drill: manually power off the Windows servers hosting your Storage Zone Controllers. Not "apply this update." Not "block this IP." Physically shut the box down. The email became public the next day when an administrator posted it to Reddit's r/sysadmin, and by 12 July the ShareFile status page listed Storage Zone Controller customers as "not operational." Progress said it was responding to a "credible external security threat" and that it had "no indication of unauthorized access to any ShareFile accounts or data." What it did not say: which vulnerability, which threat actor, which indicators to look for, or when a patch would land. There is none yet.

That combination — a hard shutdown order with no CVE, no patch, and no indicators of compromise — is the worst possible starting position for the people who now have a regulatory clock running against them. This article is about that gap: why a file-transfer edge appliance is the last place you want to go dark, and how you build a defensible NIS2 or DORA breach report when the vendor has handed you nothing to report with.

What Progress actually said (and what it didn't)

The affected component is narrow but important. A Storage Zone Controller (SZC) is not the ShareFile cloud. It is an on-premises Windows/IIS server that a customer runs themselves so that regulated files can stay on their own storage while ShareFile's cloud handles sharing and orchestration. By design the SZC sits at the network edge, reachable from the internet — that is how the cloud plane talks to it. Cloud-only ShareFile tenants are unaffected; the organisations in scope are precisely the ones who chose self-hosting for data-residency or compliance reasons, which means the ones holding the most sensitive files.

Per the BleepingComputer report (10 July 2026) and The Hacker News coverage the same day, Progress disabled affected accounts "out of an abundance of caution," told customers the cloud-side disable was not sufficient — the host itself had to be powered off — and promised an update within 24 hours. The instruction to check for "unfamiliar .aspx files" was the only technical breadcrumb, and it is a loud one. It points directly at a web shell.

Why a file-transfer edge box is the worst place to go dark

Progress is the company that owned MOVEit when Cl0p turned a single zero-day into the largest mass-exfiltration event of 2023, hitting more than 2,700 organisations. It is not the first time ShareFile's Storage Zone Controller has been in the crosshairs either: CVE-2023-24489, an AES-CBC padding-oracle flaw (CVSS 9.1) that let an unauthenticated attacker fully compromise the SZC, was added to CISA's KEV catalog in August 2023 after real-world exploitation.

And there is a much fresher chain. In February 2026, watchTowr disclosed CVE-2026-2699 and CVE-2026-2701, a pre-authentication RCE chain against SZC branch 5.x:

• CVE-2026-2699 (CVSS 9.8) is an execution-after-redirect auth bypass (CWE-698) on /ConfigService/Admin.aspx: the code calls Response.Redirect(path, false), which emits a 302 but never terminates page execution, so admin functionality runs for a caller who simply ignores the redirect header.
• CVE-2026-2701 (CVSS 9.1) chains from there: repoint the "Network Share Location" to the IIS webroot, then upload a ZIP to /upload.aspx with unzip=true, which extracts files keeping their extensions — landing an .aspx web shell that normal uploads (renamed to extension-less GUIDs) would never allow.

Progress patched that chain in StorageCenter 5.12.4 on 10 March 2026. Here is the part that matters for July: a patch closes the door, it does not evict a guest. Any SZC compromised before March and patched afterwards still carries whatever .aspx was dropped in the meantime — which is exactly why Progress is telling even patched customers to hunt for unfamiliar web shells. We have written this same sentence about UniFi, SharePoint, and Zimbra this quarter. The pattern does not change: the scanner reads a green, patched banner while an implant answers on the side.

The 72-hour problem: reporting a breach you can't see

Now the operational bind. If you are an essential or important entity under NIS2, or a financial entity under DORA, the moment you "become aware" of a significant incident a statutory clock starts — and "we powered off a data-holding appliance because our vendor told us to" is very hard to argue is not awareness.

Regime	First deadline	What it demands	Full-report deadline
DORA (financial entities)	4h initial notification after classifying as major	Nature of incident, affected services	Intermediate at 72h, final at 1 month
NIS2 (Art. 23)	24h early warning	Whether malicious, cross-border impact	72h notification with initial IOCs + impact; final report at 1 month
GDPR (Art. 33)	72h to supervisory authority	Nature, categories, likely consequences	Without undue delay

Read the NIS2 72-hour line again. The 72-hour notification must include indicators of compromise and an initial impact assessment. But in this incident there is no CVE, Progress has published no IOCs, and the one thing you were told to do — power the box off — is the fastest way to destroy the volatile evidence you would need to derive your own. A financial entity in scope of both DORA and NIS2 hits the 4-hour DORA clock first, with even less to say.

Auditor, six months from now: "Walk me through what left your Storage Zone Controller between 9 and 12 July." You: "We can't. The vendor never issued a CVE or IOCs, and we powered the server off before imaging it, per their instruction." Auditor: "So your 72-hour NIS2 notification asserted 'no data exfiltration' based on what evidence?"

That is not a hypothetical you want to improvise. "No indication of unauthorized access" is the vendor's line about its own cloud plane; it is not a finding about your on-prem box, and a regulator will not accept it as one.

Power off ≠ forensics: what you actually lose

Shutting down is the right containment call — an internet-facing box that may be running a web shell should not stay online. But containment and evidence are different jobs, and the shutdown order silently trades the second for the first. When the SZC powers off you lose the IIS worker process memory, the live TCP connection table, any staged archive still in a temp path, and the process tree that would tell you whether a shell spawned cmd.exe. The disk survives; the story of what was happening does not.

The one record that a power-off cannot erase is the one that was never on the host: the network egress. Whether gigabytes of customer files left that SZC to an ASN you have never talked to before is written on the wire, not in a log the attacker could clear or a RAM image you just discarded. Organisations that only have host-side telemetry on their edge appliances discover this in the worst order — they realise, mid-report, that the only witness they needed was the one they never deployed.

Remediation

There is no patch for the July threat as of publication, so this runbook assumes the credible-threat posture Progress described and folds in the known February chain, which is the most likely mechanism.

1. Am I affected? Only self-hosted Storage Zone Controllers are in scope — cloud-only ShareFile tenants are not. Inventory every SZC and check its build. Branch 5.x below 5.12.4 is vulnerable to the pre-auth chain; v6 is not affected by CVE-2026-2699/2701. Confirm which are internet-reachable.

2. Patch — exact fixed version. Upgrade branch 5.x to StorageCenter 5.12.4 (released 10 March 2026) or move to any v6 release. Do this after the compromise hunt below — patching first can overwrite artefacts.

3. Can't patch now? Compensating controls. Follow Progress's guidance and power the SZC off — but image the disk (and, if feasible, capture memory) before shutdown so you retain forensic state. If you cannot image, at minimum export IIS logs, the connection table, and recent files. Pull the SZC off the public internet; restrict the cloud-to-SZC path to Progress's published ranges only.

4. Hunt for compromise. Map to MITRE ATT&CK and look for:

• Unfamiliar .aspx files anywhere under C:\inetpub\wwwroot\ShareFile\StorageCenter\...\files\ul-*\ or in the webroot generally — the web-shell artefact (T1505.003, Web Shell).
• 302 responses from /ConfigService/Admin.aspx with response bodies larger than ~10,000 characters — the execution-after-redirect auth-bypass signature (T1190, Exploit Public-Facing Application).
• Requests to the misspelled endpoint /ConfigService/api/StroageZoneConfig — used to leak the encrypted Zone Secret.
• POST to /upload.aspx carrying unzip=true, and any "Network Share Location" reconfigured to point at the webroot instead of external storage.
• Sustained outbound volume from the SZC to never-before-seen ASNs, or unusual TLS sessions — the exfiltration tell (T1567, Exfiltration Over Web Service). This is the finding you will need for the NIS2 report.

5. Eradicate + verify. Removing the .aspx and patching is not enough. Because the chain leaks and decrypts the Zone Secret (the HMAC-SHA256 signing key), treat it as compromised: rotate the Zone Secret and any credentials the SZC service account could reach, then rebuild the host from a known-good image rather than cleaning in place. Only after patching to 5.12.4/v6 and rotating secrets should you certify the box clean — and record that certification as evidence, not just an admin's word.

Where this leaves you — and where Zero Hunt fits

The July ShareFile incident is not really a patching story. It is an evidence story: a regulator will ask what happened, and the honest answer for most victims is "we don't have the artefacts to say." That gap is the problem Zero Hunt's third pillar exists to close.

Continuous, scheduled and change-triggered validation means an internet-facing SZC is not something you remember to check after a vendor email — a new edge asset triggers a full campaign within the hour, and every finding, scan, and remediation is mapped across 32 frameworks (NIS2 including Title 13, DORA including the TLPT RTS, ISO 27001, SOC 2 and 28 more) and ECDSA-signed with chain-of-custody at write time. When the 72-hour NIS2 notification comes due, you are not reconstructing a story from a powered-off box; you are exporting a signed, time-stamped record from the Trust Center that already maps one finding to every regime that needs it — cross-framework mapping that removes the redundant work of answering DORA, NIS2 and GDPR separately.

And the witness the power-off destroys is the one Zero Hunt's second pillar keeps. The AI Traffic Analysis model — a proprietary deep-learning engine with four parallel inference heads (suspicious traffic, malware classification, attack-type identification, application fingerprinting), running on the appliance GPU at 2.7+ Gbit/s with no cloud callback — sees the SZC's egress as it happens. Bulk file movement to an unfamiliar ASN, a beacon on an .aspx shell, an odd-hour TLS session from a box that historically only ingests: those are visible on the wire while the activity is live, not inferred from a disk you were told to shut off. When the auditor asks what left the building, that is the difference between "we can't say" and a signed answer.

Related reading: when a rogue admin survives the patch, and the NIS2 known-CVE evidence gap. See how continuous validation and signed evidence fit together on the platform.