Object moved

If you squint and look at the CISA KEV list, you might think it's made up exclusively of vulnerabilities in file transfer solutions. While this would be wrong (and you shouldn’t squint, it’s bad for your eyes), file transfer solutions do play a decent role in the CISA KEV list due to how fondly threat actors, APT groups, and ransomware gangs alike perceive them. The following represent industry-defining historical incidents: - The MOVEit breach in 2023, - [Cleo Harmony, VLTrader and LexiCom in 2024,](https://labs.watchtowr.com/cleo-cve-2024-50623/) or, - [Fortra’s GoAnywhere, with mysterious active exploitation in 2025](https://labs.watchtowr.com/is-this-bad-this-feels-bad-goanywhere-cve-2025-10035/). Today, we find ourselves analyzing the journey we took to discover multiple vulnerabilities in Progress ShareFile, ultimately chained together to achieve Pre-Authenticated Remote Code Execution - and sharing more memes. ### What is Progress ShareFile? A software suite that was previously owned by Citrix but later acquired by Progress in 2024. In ShareFile’s own words: > ShareFile software gives you a structured, secure space to work with clients - share files, collect signatures, request data, and manage to-dos in one place, improving collaboration and the experience around it. At first glance at the software’s descriptions and signup process, one might assume that ShareFile is a SaaS-based company, which is typically out of our scope. You would be partially right; however, ShareFile maintains an on-premises, extended solution called its “Storage Zone Controller”. The Storage Zone Controller in ShareFile is a customer-managed gateway that keeps your files in your own storage (on-prem or cloud) while still using ShareFile’s SaaS interface. It handles secure file transfers, authentication, and policy enforcement, letting you control where data is stored while ShareFile manages access and sharing. So it’s like SaaS in that you can authenticate and manage your files; actually, the data isn’t stored within ShareFiles infrastructure. It can be configured to be hosted on the local file system, SMB servers, cloud bucket storage, etc. This is likely important for customers who, for whatever reasons, cannot use ShareFiles infra, such as data sovereignty, regulatory requirements, and just security hygiene. To get an idea of how prevalent this Storage Zone Controller is, a quick Internet search reveals circa 30,000 instances. ### What Are We Rambling About Today? In this post, we’ll walk through vulnerabilities we discovered in Progress ShareFile that allowed us to achieve pre-auth RCE on what was, at the time of research, fully patched to latest. Today, we’ll be discussing, analyzing and chaining the following: - CVE-2026-2699 / WT-2026-0006 - Authentication Bypass - CVE-2026-2701 / WT-2026-0007 - Remote Code Execution ShareFile comes in two major branches for applications hosted within an IIS setup: - Branch 6.x - Built using .NET Core - Branch 5.X - Built using ASP.NET Although our research did at different points focus on both branches, both vulnerabilities discussed today are specific to branch 5.X - specifically, we identified these new vulnerabilities within version `StorageCenter_5.12.3` which was the latest version at the time of writing. These vulnerabilities were resolved in version `5.12.4` , release to ShareFile customers on branch 5.x on March 10, 2026. ### Dissecting The ShareFile Storage Zone Controller We set out with the goal of trying to achieve a complete compromise of a ShareFile Storage Zone Controller from a Pre-Authenticated perspective, that's right, today we’re talking about Remote Code Execution. The installation is straightforward in that the files are present in the IIS directory `C:\inetpub\wwwroot\ShareFile` and the application is registered under the IIS “Default Web Site”. Before continuing, it's vital to get set up. We extracted and decompiled all the applications' `.dll` files into their respective C# code. Post installation, a configuration page is launched from `localhost` to authenticate the ShareFile instance to its connected SaaS user. To clarify, ShareFile has a cloud offering, which is their “SaaS”, this is Progress’s main interface and infrastructure for managing files. Accounts can be created through their website without a sales approval process. We configured this and set up the Storage Zone Controller to work as if it were running within a production environment. This includes: - Authenticating and connecting the Zone Controller to the Progress SaaS - Creating a Primary Zone which hosts the files on a local file server (Not Progress’s SaaS environment). With all web applications, it's imperative to understand where we, as attackers, can interact with the application's code from an external, pre-authenticated perspective. .NET applications such as this have a variety of ways in which interaction can be achieved, for example, with ShareFile, there are: - ASHX, ASMX, and ASPX extension files, which execute scripted code. It is also possible for additional code to be introduced and referenced in these files through compiled DLLs. - Routes such as REST endpoints defined within the `web.config` that is also backed by the DLL’s code Whenever looking at large .NET applications such as this, we typically go through the motions of our methodology by first looking at the easier-to-read, script files (`ashx`, `aspx`, `asmx` etc) before we look through the large `dll` files which will contain things such as REST API. Before diving into the code itself, it's important to see how the application responds when each script file/endpoint is requested. Usually, with questions in mind, such as: What status code is returned? What is the content length? What is the content type?. Keep in mind the application is a living, agile thing, and poking it can reveal traits not obvious in the code. ### There’s No Authentication Bypass Here? WT-2026-0006 (CVE-2026-2699) - Authentication Bypass Vulnerability To start, we list out all of the `.aspx` files within the application and send requests to the server to observe the response. The list of endpoints is: ``` /AdvancedStatus.aspx /cifs/upload-streaming-2.aspx /cifs/upload.aspx /ConfigService/Admin.aspx /ConfigService/Login.aspx /ConfigService/Networking.aspx /ConfigService/PreFlightCheck.aspx /ConfigService/SMTPConfig.aspx /ConfigService/UpdatePassphrase.aspx /documentum/upload-streaming-2.aspx /documentum/upload.aspx /heartbeat.aspx /ProxyService/rest/storagecenter.aspx /rest/queue.aspx /sp/upload-streaming-2.aspx /sp/upload.aspx /thumbnail.aspx /upload-resumable-1.aspx /upload-resumable-2.aspx /upload-resumable-3.aspx /upload-singlechunk.aspx /upload-streaming-1.aspx /upload-streaming-2.aspx /upload-threaded-1.aspx /upload-threaded-2.aspx /upload-threaded-3.aspx /upload.aspx ``` We’re looking for differentials that might encourage a closer look, typically endpoints that don’t redirect to authentication or return status codes 401 or 403. We quickly observed that the configuration endpoints that we set up the application earlier with, such as `/ConfigService/Login.aspx` return a HTTP Status Code 403 (Forbidden), it is only accessible if you try to access it from the host itself (the `localhost` 127.0.0.1). Whilst perusing through the status code and responses of each endpoint, we come across what can only be described as an anomaly for `/ConfigService/Admin.aspx` . See if you can spot what it is? ``` HTTP/1.1 302 Found Cache-Control: private,no-store Pragma: no-cache Content-Type: text/html; charset=utf-8 Location: /ConfigService/Login.aspx?callerpage=Admin Server: Microsoft-IIS/10.0 Access-Control-Allow-Origin: * Access-Control-Max-Age: 540 Access-Control-Allow-Headers: Content-Type Access-Control-Allow-Methods: GET, POST, PATCH, DELETE, OPTIONS, HEAD Strict-Transport-Security: max-age=31536000 X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block X-Frame-Options: DENY Date: Mon, 23 Mar 2026 01:59:44 GMT Content-Length: 22448 Object moved

Object moved to here.

"> ShareFile - Where Companies Connect [... Truncated ...] ``` When accessing the endpoint through a browser, you’re redirected via the `Location` header to authenticate via `Login.aspx` which 403’s as mentioned before (it's only for `localhost` access). What is anomalous here is the rather large `Content-Length` and the content displayed in the body (we’ve truncated this). This is quite peculiar and not something we’ve seen before, not at least within a .NET application. For those unfamiliar, a behavior that was neither common nor unheard of was present in PHP applications. In certain circumstances, developers might have implemented functionality that checks for authentication and redirects the user, but forget to `die()`, resulting in the rest of the script and its accessible functionality executing. This is known as “CWE-698: Execution After Redirect (EAR)”. Friends of the Internet, we have what we need to begin - an authentication bypass. ### Ok, But, What? Well, let's walk through this. If you're so inclined to test this through your browser, you can modify the HTTP response with whatever tool you please, drop the `Location` header, and see that the admin panel renders. Enterprise-grade doo doo doo babyshark~ The above shows what is visible after removing the redirecting `Location` header, allowing the rest of the body to be rendered in the browser. Functionality is presented to us that can be interacted with without authentication, but we’ll get to that. First, let's work out, at a code level, what has gone wrong here. Looking through the source of the file `Admin.aspx` we can see references to a class `"ConfigService.Admin"` . As always, the code for this class is in the DLL files we decompiled earlier. ``` protected void Page_Load(object sender, EventArgs e) { this._logger.LogDebug("Page_Load Enter", Array.Empty

Related coverage

Worried this affects your company?