>> All posts

CVE-2026-2699: ShareFile Storage Zones Controller improper access control

The short version: Customer-managed ShareFile Storage Zones Controller (SZC) — the on-premises component that brokers ShareFile storage — has an improper-access-control flaw (CVE-2026-2699) that lets an unauthenticated attacker reach restricted configuration pages. From there, an attacker can change system configuration and, potentially, reach remote code execution. A proof-of-concept is public and it carries a high exploitation probability, though it isn't in CISA's KEV catalog yet. Steady hands — patch, and get the controller off the open internet.

At a glance

FactDetail
Our severity takeHigh — unauthenticated config access with an RCE path; watch for KEV escalation
CVSS v3.1 (CNA — Progress)9.8 — Critical · AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (NVD analysis pending)
EPSS49.42% · 98.8th percentile (2026-07-17)
In CISA KEV?No — not listed at time of writing (a public proof-of-concept exists)
Known exploited?Not confirmed at time of writing
Vulnerability typeCWE-284 improper access control (execution-after-redirect) → restricted config access → config change / potential RCE
Requires authenticated session?No — pre-authentication
AffectedProgress ShareFile Storage Zones Controller 5.0.0 through 5.12.3
Fixed in5.12.4 or later

What you need to know

The Storage Zones Controller has admin/configuration pages that are supposed to require authentication. An execution-after-redirect weakness means the server hands back the protected content even though it issues a redirect toward the login page — so an unauthenticated request that ignores the redirect and reads the response body reaches the restricted configuration surface anyway.

  • How they find it — internet-wide scanning surfaces exposed ShareFile SZC and panel interfaces.
  • How they use it — request the protected configuration endpoint directly; the redirect is cosmetic, and the configuration page is served without a valid session.
  • What it leads to — the ability to alter system configuration, which the vendor notes can lead to remote code execution. A public proof-of-concept exists, and the flaw is often discussed alongside a companion issue, CVE-2026-2701.

How serious we see it

High — and positioned to climb.

It's unauthenticated and network-reachable, the config surface it exposes is powerful, and there's a public PoC plus a high EPSS — all of which argue for treating it seriously now. We stop just short of Critical because the remote-code-execution outcome is described as potential (a path via configuration change) rather than a single-request, guaranteed RCE, and because it isn't yet in KEV or confirmed exploited in the wild. That's a distinction to watch, not to lean on: if in-the-wild use or a reliable RCE chain is confirmed, this moves up. The reassuring part is that it's specific and fixable — a defined version range, a published fix, and quick to confirm.

Recommendations

Straight from the vendor's advisory:

  1. Patch now. Upgrade customer-managed ShareFile Storage Zones Controller to 5.12.4 or later.
  2. Get the controller off the open internet. Restrict SZC management/configuration access to trusted networks; it should not be broadly reachable.
  3. Hunt for tampering. Review the controller's configuration and logs for unauthorized changes and unexpected access to admin/config endpoints.
  4. If you find indicators, respond. Rotate credentials and secrets tied to the storage zone, and validate the integrity of the controller host.
  5. Confirm your exposure first. Verify whether you run a customer-managed SZC, which version, and whether it's internet-facing.

How BreachRisk sees it

BreachRisk discovers internet-facing ShareFile Storage Zones Controller interfaces from little more than your domain, fingerprints the instance, and flags exposure tied to this flaw. Where testing is authorized, BreachRisk can safely confirm whether the configuration endpoint is reachable without authentication — the difference between "this looks like an affected SZC" and a verified exposure — as a bounded check rather than a configuration change.

That outside-in view is what you want for an access-control bug with a public PoC: the exposed controller is already mapped, so you can prioritize the upgrade before someone tests the redirect for you.

References

See your cyber risk, proven.