ShareFile Storage Zones Recovery Needs More Than A Restart

Progress temporarily disabled ShareFile access for customers using Storage Zones Controllers and told them to power down the Windows servers after receiving information about a credible external threat. The public status incident ran from July 10 to July 14, 2026. Progress later said it found a high-severity path-traversal vulnerability affecting controller versions 5.x and 6.x, released patches directly to customers, and began restoring access.

Progress says it has no evidence that a ShareFile customer account or customer data was accessed and says it did not identify an active threat. The public record still lacks a CVE, a technical advisory for the July flaw, public indicators, and the recovery instructions that were sent to account owners. Administrators should follow those direct instructions, preserve evidence, validate the controller and its storage boundary, and record what remains unknown before returning file exchange to normal.

Progress's public status page opened an investigation at 12:12 p.m. EDT on July 10, reporting that ShareFile customers with Storage Zones Controllers were not operational. The company told affected customers that it had disabled access and asked them to manually shut down the servers hosting the controllers. In statements reported by SecurityWeek, Progress described a credible external security threat and said the shutdown was an additional precaution for customer data.

By 5 p.m. EDT on July 12, Progress told SecurityWeek that it had restored customer access to the ShareFile cloud service but that Storage Zones Controllers had to remain off while the investigation continued. It also said at that stage that it had no evidence of unauthorized access to a customer account or data and had not identified an active threat. This intermediate state matters: cloud sign-in availability was not permission to bring the customer-managed data path back online.

On July 14, the status incident moved to resolved and said controller access was being restored, with recovery instructions provided directly to account owners. Progress told The Hacker News that the investigation identified a high-severity vulnerability affecting versions 5.x and 6.x, that patched versions had been released, and that controllers could return to operation after patching. The outlet reported the flaw as path traversal. Progress again said it had no evidence of customer-account or data access and no identified active threat.

Storage Zones Controller is the customer-managed half of a hybrid file-sharing design. Progress documentation says it lets organizations keep files on an on-premises network share or supported third-party storage while using the ShareFile service for sharing and control. For a standard zone, the cloud handles sign-in and authorization, while the client communicates with the controller for uploads and downloads and the controller writes files to the local storage location.

That architecture puts the controller between external users, the ShareFile control plane, employee authentication, and a private file repository. Progress says a standard zone needs an external address and a certificate trusted by user devices and ShareFile servers. It recommends placing controllers inside the network behind DMZ protections, encrypting communications, patching the hosts, using perimeter and local firewalls, and limiting capabilities.

A path-traversal vulnerability at this boundary deserves more attention than a generic web-server defect. Depending on the code path and permissions, traversal can expose or alter files outside an intended directory. Progress has not publicly documented the July flaw's reachable paths, authentication requirements, write capability, operating-system context, or exploit sequence. Those details must stay unknown in a public assessment rather than being filled in from older ShareFile bugs.

Earlier in 2026, Progress published a separate advisory for CVE-2026-2699 and CVE-2026-2701 in Storage Zones Controller 5.x. The company said the first flaw could expose restricted configuration pages to an unauthenticated remote attacker and the second could lead to remote code execution. Progress advised version 5 customers to move to 5.12.4 or any version 6 release and said it had received no reports that those flaws were exploited.

The July incident is not proof that those CVEs were exploited. The new vendor statement describes a high-severity path-traversal vulnerability across both 5.x and 6.x, while the February advisory said version 6 was not affected by the earlier pair. The product scope alone shows that the July issue is different. Administrators should retain the old CVEs in historical exposure review, but should not copy their mechanics, indicators, or fixed versions into the July incident record.

This also means version 5.12.4 or an arbitrary version 6 build is not an adequate July acceptance criterion. Those were the public February thresholds. For the July recovery, use the patched installer and instructions that Progress delivered directly to the customer's account owner or support channel. Record the file hash, signer, source, installed version, installation time, and support case so the decision remains auditable even though the public status page does not name the builds.

Before changing the controller, preserve the state required by the organization's incident plan. That normally includes a time-synchronized copy of relevant Windows event logs, IIS and application logs, endpoint-security telemetry, configuration, running services and scheduled tasks, network connection history, and the deployed web and application directories. Capture volatile data first when the response team considers it necessary. Evidence handling should follow internal legal, privacy, and forensic requirements.

Then follow Progress's direct sequence. Confirm the controller stays isolated until the approved patch and prerequisites are ready. Validate the package source and signature, take the supported configuration backup, patch every controller in the zone, restart only where instructed, and verify the installed build from the host. In a high-availability design, do not assume the secondary received the change because the primary did. Each server needs its own version evidence and health result.

Return traffic in stages. Test ShareFile authorization, employee sign-in, upload, download, file preview where used, connector access, antivirus or DLP integration, storage permissions, and logging. Watch for unexpected outbound connections, new files or services, unusual access to the backing share, and errors that suggest cloud metadata and local storage have diverged. Do not use ShareFile's reconcile function as a routine recovery shortcut: its documentation warns that reconcile can permanently erase cloud metadata for files missing from local storage.

Progress's repeated statement that it found no evidence of customer-account or data access is a material fact and should be included in every incident summary. It narrows the confirmed impact and prevents unsupported breach claims. The company also said it did not identify an active threat. Those statements do not disclose how many controllers were examined, which telemetry was available, or whether they rule out activity confined to a customer-managed host.

An organization therefore needs its own decision standard. If the controller was exposed, if logs are missing, if endpoint protection alerted, if web directories changed, or if the host made unexplained connections, escalate to the incident-response team and Progress support. A patch closes the vulnerable path; it does not remove persistence, restore a changed configuration, or reconstruct deleted evidence. Rebuilding from a known-good base may be appropriate when compromise is confirmed or trust cannot be re-established, but that decision should follow supported recovery guidance and the organization's forensic findings.

NIST's current incident-response guidance treats recovery as part of risk management rather than a simple return to uptime. For this event, that means documenting the source of the alert, containment time, evidence preserved, affected versions, patch provenance, host validation, data-access findings, residual unknowns, and the authority that approved reconnection. If later Progress disclosures add a CVE, indicators, or revised recovery steps, the case can then be reopened against a reliable record.

Progress documentation says Storage Zones Controller 5 is approaching end of life. It also says restricted storage zones are already in end of maintenance, are not supported in version 6, and are tentatively scheduled to become unavailable on November 30, 2026. Those constraints can leave an organization choosing between an older controller line and a zone model that no longer receives fixes.

Separate the emergency patch from the migration decision, but start both. Identify which zones are standard or restricted, where files and metadata live, which connectors reach network shares or SharePoint, what identity dependencies exist, and which external names expose the controllers. Map owners for the ShareFile tenant, Windows hosts, certificates, storage, backups, DLP, antivirus, and business workflows. A product upgrade without that dependency map can restore the same opaque boundary on a newer build.

For supported standard zones, keep controllers behind reviewed edge controls, restrict service and storage permissions, monitor changes to application directories and configuration, and maintain tested configuration backups. For legacy restricted zones, obtain a supported migration plan from Progress and test how permissions, metadata protection, external sharing, and user access will change. The useful outcome is not only a patched server. It is a smaller, supportable file-sharing boundary with an owner and a recovery path.