ShareFile's Silent Zero-Day: Inside Progress's Emergency Storage Zone Controller Shutdown

Introduction

On July 10, 2026, Progress Software asked ShareFile customers to do something vendors rarely request outright: shut down their Storage Zone Controller (SZC) servers, immediately. Account access went dark. The reason given was a “credible external security threat.” No CVE number. No technical detail. Four days later, Progress confirmed the cause — an authenticated path traversal flaw affecting every 5.x and 6.x release of SZC. A CVE identifier has been reserved for it. It still isn’t public.

Here is what our research team confirmed, why the early exposure numbers circulating online don’t apply to this incident, and how we built a Shodan-based fingerprint to identify at-risk instances while the vendor's own CVE record is still sitting in reserve.

The Five-Day Timeline

● July 10: Progress instructs customers to shut down SZC servers, citing a credible external security threat. Account access is temporarily disabled.

● July 11: A Progress knowledge-base update states there is no indication of unauthorized access.

● July 14: Progress confirms the vulnerability and ships patched versions.

The Vulnerability: Authenticated, but Still Dangerous

The flaw is a path traversal issue reachable by an authenticated administrative user. That authentication requirement matters — this is not a pre-auth remote code execution bug — but the resulting access is still severe. An attacker who already holds admin credentials can read arbitrary files accessible to the application’s service account, write attacker-controlled content to arbitrary directories, or enumerate the server’s file system layout.

● Affected versions: all 5.x and 6.x releases of ShareFile Storage Zone Controller.

● Patched in: 5.12.5 and 6.0.2, released July 14, 2026.

A CVE That Doesn't Exist Yet

Progress has reserved a CVE identifier for this vulnerability but does not plan to publish it for roughly two weeks, targeting around July 28. The company's stated rationale, per BleepingComputer, is that holding the record gives customers time to patch before technical detail becomes available to potential threat actors — and that this delay is standard practice for Progress.

Black Kite is treating that position as the operative signal. We tagged this exposure without a CVE reference and will attach the identifier the moment it publishes, rather than attributing a number to it prematurely.

Don't Confuse This With the April 2026 Vulnerabilities

SZC has been in the news before this year, and it's easy to conflate two unrelated stories. In April 2026, watchTowr Labs disclosed a pre-authentication chain — CVE-2026-2699 and CVE-2026-2701 — that Progress patched in version 5.12.4. The new path traversal flaw is a different vulnerability class, on a different patch cycle, requiring authentication the earlier chain didn't.

Table 1: Comparing the April 2026 pre-auth chain (CVE-2026-2699/CVE-2026-2701) with the new July 2026 path traversal vulnerability.

Some online commentary suggests attackers may have chained the April vulnerabilities to achieve pre-authentication remote code execution against the current target set. That link is unconfirmed. Progress has not connected the current threat to those earlier CVEs, and it should be treated as community speculation until the new CVE record publishes with technical detail.

No Confirmed Breach — Yet

As of the latest reporting, there is no indication of unauthorized access to customer accounts or data, and no active exploitation has been detected. That status can change quickly once technical detail becomes public, which is precisely the scenario Progress says it's trying to delay.

A Pattern Five Years in the Making

This isn't SZC's first run-in with path traversal. In 2021, CVE-2021-22941 combined a relative path traversal flaw with unauthenticated remote code execution — the same underlying vulnerability class as the current issue, in a separate incident five years apart. In 2023, CVE-2023-24489 landed in CISA's Known Exploited Vulnerabilities (KEV) catalog with confirmed active exploitation, back when the product still carried the Citrix name. Progress acquired ShareFile in 2024, which is why this week's disclosure is attributed to Progress Software rather than Citrix, even though the 5.x branch traces back to the Citrix era and continued under Progress's maintenance.

Why the "30,000 Exposed Instances" Number Doesn't Apply Here

The figure of roughly 30,000 internet-facing SZC instances, cited in some sources, comes from an April 2026 scan tied specifically to the earlier auth-bypass and RCE chain — not the new path traversal disclosure. Carrying that number forward into coverage of the current incident overstates a population that was never measured against this vulnerability. Any exposure estimate for the July 14 flaw needs its own verification, which is exactly what we built next.

Behind the FocusTag: Fingerprinting SZC on Shodan Before There Was a CVE

Storage Zone Controller is the on-premises half of ShareFile: the component customers host on their own infrastructure to manage where files are physically stored. Authentication stays in Progress's cloud, but the storage layer — and the vulnerability — lives on the customer's own server. That's an important distinction, because the ShareFile SaaS platform itself is not affected by this incident.

SZC carries three overlapping names depending on where you look. SZC is the external, marketing-facing product name. Storage Server describes the externally exposed web service the product runs. StorageCenter is the legacy, technical name baked into the installer package, file paths, and version strings — a holdover naming convention that predates the current branding and that Shodan's own detection template still uses to label these hosts.

That gap between marketing name and technical name is what made this fingerprint possible. Reviewing SZC's default web presence, we found that every installation ships with a static landing page baked in by the installer itself — historically packaged as StorageCenter_<version>.msi and deployed under C:\inetpub\wwwroot\ShareFile\StorageCenter\. That page is rarely touched or removed post-installation, which makes its markup a durable, version-independent signal rather than a fragile banner that changes release to release.

The default landing page bundled with every Storage Zone Controller installation. The image element's alt="StorageCenter" attribute and its images/storage-center.png source are the fingerprint Black Kite used to identify exposed instances on Shodan, independent of version or patch level.

We iterated the Shodan query against that fingerprint in three passes:

● http.title:"ShareFile Storage Server" "IIS" — 4,391 results. A broad starting point based on the product's Shodan-assigned title.

● http.html:"images/storage-center.png" — 330 results. Narrowing to the legacy image path tightened the population considerably.

● http.html:"alt=\"StorageCenter\"" -tag:honeypot — 3,170 results. Excluding honeypots from the alt-text match converges almost exactly with the honeypot-excluded count from the original title query — strong confirmation that both queries are capturing the same real population of exposed servers, not noise.

Because the fingerprint targets the product itself rather than a version string or CVE-specific artifact, Black Kite published the FocusTag®—“Progress ShareFile SZC [Suspected]”—using product-based tagging rather than version-based tagging. That decision reflects the reality on the ground: the CVE record isn't public, but the exposed population is identifiable today, and TPCRM programs shouldn't have to wait on a CVE number to know where they stand.

What We Still Don't Know

Whether the vulnerability was identified internally at Progress or reported by an external researcher — BleepingComputer has asked; a response is pending.
Whether Progress will publish additional technical detail alongside the CVE record.
Whether the July flaw is genuinely related to the April auth-bypass/RCE chain, or simply shares a superficial resemblance in vulnerability class.

The Bottom Line

A missing CVE number doesn't mean a missing risk. Progress has confirmed the vulnerability, shipped a patch, and explained why it's holding the identifier back — which means every unpatched 5.x and 6.x SZC instance is a known, named exposure regardless of whether it carries a CVE tag yet. Organizations running Storage Zone Controller should move to 5.12.5 or 6.0.2 now, verify administrative access controls given the authentication requirement, and treat any related third-party or vendor instances as in scope for review.

This is also a case study in why product-based intelligence has to move faster than CVE-dependent tracking. Black Kite's FocusTag® for this exposure was live, with a verified Shodan-based exposure count, before the vulnerability even had a public identifier — giving TPCRM programs a head start most CVE feeds can't offer.

What Questions Should TPRM Professionals Ask Vendors?

Any vendor running Progress ShareFile Storage Zone Controller on their own infrastructure should be able to answer the following without hesitation:

Are you running SZC, and on which branch? Confirm whether they're on the 5.x or 6.x line — both are affected — and get the exact version string, not just "we're patched."
Have you applied 5.12.5 or 6.0.2? Ask for the patch date, not just confirmation. "Patched" from two months ago doesn't cover this issue; it needs to be July 14, 2026 or later.
Is your SZC instance internet-facing? If yes, ask why. SZC's storage layer doesn't need to be publicly reachable in most architectures — unnecessary exposure is itself a finding.
Who holds administrative access, and how is it protected? The vulnerability requires an authenticated admin session. MFA on admin accounts, and a tight list of who actually holds that role, materially reduces the blast radius.
Have you reviewed logs for path traversal indicators since July 10? Ask specifically about unusual file reads/writes outside expected directories, not just "no alerts fired."
Did you shut down SZC when Progress requested it on July 10? A vendor that ignored or delayed that instruction is a bigger concern than the vulnerability itself.
Will you share the CVE ID and advisory once Progress publishes it? Progress has said this will happen within roughly two weeks of the disclosure — get a commitment now, before the record goes live and the conversation gets harder to start.
Are you tracking the April 2026 CVE-2026-2699/2701 chain separately? A vendor that conflates the two, or assumes one patch covers both, hasn't actually read the advisories.

Remediation Recommendations For organizations running SZC directly

Patch to 5.12.5 (5.x branch) or 6.0.2 (6.x branch) immediately. Don't wait for the CVE to publish — the vendor has already confirmed the flaw and shipped the fix.
Audit administrative accounts on SZC. Remove standing admin access that isn't operationally necessary, and enforce MFA on every account that keeps it.
Reassess whether SZC needs to be internet-facing at all. Where it doesn't, move it behind a VPN or restrict access to known management IPs.
Review file system logs for the period since July 10 for reads or writes outside expected storage paths — the vulnerability's signature is arbitrary file access via the service account.
Don't assume the April 2026 patch (5.12.4) covers this. That closed CVE-2026-2699/2701; this is a separate flaw on a separate patch.

For TPRM programs assessing third parties:

Identify which vendors in your ecosystem run ShareFile SZC on-premises — this is a hosting-model question, not just a "do you use ShareFile" question, since the SaaS side isn't affected.
Use Black Kite's FocusTag® "Progress ShareFile SZC [Suspected]" to flag vendors with internet-facing, fingerprinted instances without waiting on a CVE record to confirm exposure.
Request evidence of patching (version number, patch date), not a verbal confirmation.
Flag any vendor that ignored Progress's July 10 shutdown request as a process-maturity concern independent of the technical fix.
Revisit the assessment once the CVE publishes — Progress has indicated roughly two weeks from disclosure — and treat the current FocusTag as an early-warning signal, not the final word.

How Black Kite's FocusTag® Closes the Pre-CVE Gap

The core challenge with this incident isn't the vulnerability itself — it's timing. Progress confirmed the flaw and shipped a patch on July 14, but the CVE record won't publish until around July 28. That two-week gap is exactly where most CVE-dependent vendor risk programs go blind: no CVE number means no automated feed match, no ticket, no signal that a vendor needs to be checked.

Black Kite closes that gap with product-based tagging instead of version- or CVE-based tagging. The FocusTag® "Progress ShareFile SZC [Suspected]" was published using a verified Shodan fingerprint tied to the product itself — not to a CVE identifier that doesn't exist yet — which means:

TPRM teams get an actionable signal today, not in two weeks. Any vendor in your ecosystem running an internet-facing, fingerprinted SZC instance shows up now, independent of whether Progress has released technical detail.
The tag updates as the story develops. Once the CVE publishes, Black Kite will attach the identifier to this FocusTag rather than requiring a separate lookup — the exposure record and the eventual CVE stay linked to the same vendor population.
Exposure counts are verified, not inherited. Rather than relying on the widely cited but unrelated "~30,000 instance" figure from April's watchTowr disclosure, the FocusTag reflects a fresh, incident-specific Shodan verification.
Vendor conversations start with evidence, not a guess. Instead of emailing every third party that "might" run ShareFile, TPRM teams can go directly to the subset of vendors whose exposed infrastructure matches the confirmed fingerprint.

Progress ShareFile SZC FocusTag®, including recommended remediation actions and confidence level.

Strengthening TPRM Outcomes with Black Kite’s FocusTags®

The core challenge with this incident isn't the vulnerability itself — it's timing. Progress confirmed the flaw and shipped a patch on July 14, and says the CVE record will publish in roughly two weeks. Until then, most CVE-dependent vendor risk programs go blind: no CVE number means no automated feed match, no ticket, no signal that a vendor needs to be checked.

Black Kite closes that gap with product-based tagging instead of version- or CVE-based tagging. The FocusTag® "Progress ShareFile SZC" was published using a verified OSINT fingerprint tied to the product itself — not to a CVE identifier that doesn't exist yet — which translates directly into stronger TPRM outcomes:

Faster time-to-signal. TPRM teams get an actionable flag today, not in two weeks. Any vendor in your ecosystem running an internet-facing, fingerprinted SZC instance shows up now, independent of whether Progress has released technical detail.
Continuity as the story develops. Once the CVE publishes, Black Kite will attach the identifier to this FocusTag rather than requiring a separate lookup — the exposure record and the eventual CVE stay linked to the same vendor population.
Verified exposure, not inherited numbers. Rather than relying on the widely cited but unrelated "~30,000 instance" figure from April's watchTowr disclosure, the FocusTag reflects a fresh, incident-specific Shodan verification.
Targeted vendor outreach. Instead of emailing every third party that "might" run ShareFile, TPRM teams can go directly to the subset of vendors whose exposed infrastructure matches the confirmed fingerprint — better response rates, less noise.

About Focus Friday

Every week, we delve into the realms of critical vulnerabilities and their implications from a Third-Party Risk Management (TPRM) perspective. This series is dedicated to shedding light on pressing cybersecurity threats, offering in-depth analyses, and providing actionable insights.

See Black Kite's full CVE Database and the critical TPRM vulnerabilities that have an applied FocusTags® at https://blackkite.com/cve-database.