Progress ShareFile: Emergency Server Shutdown Over a Credible Threat

An Order You Do Not See Often: Turn the Servers Off

On July 10, 2026, Progress Software sent an urgent email to ShareFile administrators and updated its status page. The message was blunt. Any organization running a ShareFile Storage Zone Controller on its own Windows server needed to shut that server down right away, and not turn it back on until Progress said it was safe. Progress described the reason as a credible external security threat.

Progress did more than warn people. It disabled cloud access to ShareFile accounts that use Storage Zone Controllers, and it told customers that turning off cloud access was not enough on its own. The physical or virtual server hosting the controller had to be powered off as well. The order first reached the wider public when a customer posted the email to the r/sysadmin community on Reddit that same day.

As of the latest updates, there is no patch, no assigned CVE, and no named threat actor. Progress said it had no sign of unauthorized access to any ShareFile account or data, and stressed that the shutdown was a precaution while it investigated with inside and outside security experts. On July 12, Progress told affected customers that access to the ShareFile cloud service had been restored, but that the Storage Zone Controllers themselves must stay off until the review is finished.

What a Storage Zone Controller Actually Is

ShareFile is a managed file sharing and transfer product. Many customers let Progress host their files in the cloud. Others want their files to stay on their own storage for privacy, data residency, or compliance reasons. A Storage Zone Controller is the piece that makes that second option work. It runs on a Windows server the customer controls, keeps the files local, and still connects to the ShareFile cloud for login, user management, sharing, and collaboration.

To do that job, the controller has to be reachable from the internet. That places it right at the network edge, which is exactly where attackers like to look. An internet-facing server that handles sensitive files is a high-value target for ransomware crews and data extortion groups. The decision to order a full shutdown, rather than a config change or a firewall rule, points to a serious flaw, most likely one that lets an attacker run code on the server before logging in and bypass the ShareFile cloud gateway to hit the box directly.

A Product With a Rough History

This is not the first hard week for ShareFile, and the pattern matters for risk teams sizing up the vendor.

In April 2026, the research firm watchTowr Labs published details and a proof-of-concept for two critical, chainable flaws in ShareFile Storage Zone Controllers: CVE-2026-2699, an authentication bypass rated 9.8, and CVE-2026-2701, a remote code execution flaw rated 9.1. Chained together, they let an unauthenticated attacker slip past the login screen, change storage settings, and upload a malicious ASPX webshell that lands in the web root where it can be reached over the internet. Progress had already fixed the chain in version 5.12.4, released to 5.x customers on March 10, 2026. When watchTowr scanned for exposed systems around that time, it found close to 30,000 reachable ShareFile instances, and the Shadowserver Foundation counted several hundred that were clearly internet-exposed. Progress has not confirmed the cause of the July event, and no CVE has been tied to it, but the earlier chain shows the kind of attack this architecture is exposed to.

Go back further and the story rhymes. In 2023, under Citrix ownership, ShareFile carried CVE-2023-24489, an improper access control bug rated 9.8 that let unauthenticated attackers upload files and run code because of small errors in how the product handled AES encryption. CISA added it to its Known Exploited Vulnerabilities catalog in August 2023 after it was hit in the wild, and GreyNoise watched exploitation attempts spike. The fix shipped in version 5.11.24.

There is one more piece of context that risk teams should hold onto. Progress Software is also the parent of MOVEit Transfer, the managed file transfer product at the center of the 2023 Cl0p mass exploitation event that reached more than 2,700 organizations through a single vulnerability. File transfer and file sharing platforms keep drawing this kind of attention because they sit at the edge and hold sensitive data, the same profile that made the Accellion FTA and Barracuda ESG appliances such damaging targets.

Timeline of the July 2026 Event

What Third-Party Risk Teams Should Do Now

This is a supply chain and third-party risk event as much as a technical one. Most organizations will not run ShareFile themselves, but plenty of their vendors do, and a vendor's exposed controller can put shared data at risk. Here is a practical order of work.

1. Find exposed vendors through attack surface scanning

Use passive scanning tools such as Shodan and Censys to spot vendors with exposed ShareFile Storage Zone Controllers. Useful searches include the HTML page title "ShareFile Storage Server" paired with a vendor's domain names or ASN, and a search of SSL and TLS certificates for the string "sharefile" tied to vendor domains. Keep one thing in mind: a vendor that already followed the shutdown order will show up as offline in these tools, so an offline result is not proof of a problem. It may mean the vendor did the right thing.

To run this at scale, the script below takes a text file of vendor domains and asks Shodan whether any of them expose a ShareFile Storage Zone Controller to the public internet. It pages through every match, writes a CSV summary, and saves the raw Shodan records as JSON. You need curl, jq, and a Shodan API key with search access. Click to expand it.

#!/usr/bin/env bash
#
# shodan_sharefile_check.sh
# -------------------------------------------------------------------------
# Third-Party Risk Management helper: given a text file of vendor domains,
# query Shodan to find any that expose a Progress/Citrix ShareFile
# "Storage Zone Controller" to the public internet.
#
#
# Requirements:
#   - curl
#   - jq
#   - A Shodan API key with SEARCH access (a paid/membership plan; the
#     free tier cannot use the /host/search endpoint or hostname: filters).
#     Each domain searched consumes ~1 Shodan query credit.
#
# Usage:
#   1. Put one domain per line in a file called "domains" (default) e.g.:
#         vendor-a.com
#         vendor-b.net
#   2. Enter your Shodan API key below (SHODAN_API_KEY=...) OR export it
#      as an environment variable OR let the script prompt you for it.
#   3. Run:   ./shodan_sharefile_check.sh
#      Or:    ./shodan_sharefile_check.sh /path/to/domains
# -------------------------------------------------------------------------

set -uo pipefail

SHODAN_API_KEY_HARDCODED="XXXXXXXXXXXXXXXXXXXXXXXXXXX"
# ==========================================================================

# ---- Configuration -------------------------------------------------------
DOMAINS_FILE="${1:-domains}"        # first arg, or ./domains by default
RATE_LIMIT_SECONDS=1                # Shodan allows ~1 request/second
MAX_PAGES=20                        # safety cap on pages/domain (100 hosts/page,
                                    # 1 query credit/page). 20 => up to 2000 hosts.
RUN_STAMP="$(date +%Y%m%d_%H%M%S)"
OUTPUT_CSV="sharefile_findings_${RUN_STAMP}.csv"
OUTPUT_JSON="sharefile_findings_${RUN_STAMP}.json"
# Newline-delimited scratch file; each line is one matching host as raw
# Shodan JSON (with the queried domain merged in). Slurped into OUTPUT_JSON
# at the end so we emit a single well-formed JSON array.
JSON_TMP="$(mktemp)"
trap 'rm -f "$JSON_TMP"' EXIT

# The ShareFile Storage Zone Controller fingerprint. Combined with a
# hostname: filter per domain below. You can broaden/narrow this if needed.
FINGERPRINT='http.title:"ShareFile Storage Server"'

# ---- Preflight checks ----------------------------------------------------
for bin in curl jq; do
    if ! command -v "$bin" >/dev/null 2>&1; then
        echo "ERROR: required tool '$bin' is not installed." >&2
        exit 1
    fi
done

# Resolve the API key: hard-coded var  ->  exported env var  ->  prompt.
SHODAN_API_KEY="${SHODAN_API_KEY_HARDCODED:-${SHODAN_API_KEY:-}}"
if [[ -z "$SHODAN_API_KEY" ]]; then
    read -r -s -p "Enter your Shodan API key: " SHODAN_API_KEY
    echo
fi
if [[ -z "$SHODAN_API_KEY" ]]; then
    echo "ERROR: no Shodan API key provided." >&2
    exit 1
fi

if [[ ! -f "$DOMAINS_FILE" ]]; then
    echo "ERROR: domains file '$DOMAINS_FILE' not found." >&2
    echo "Create it with one vendor domain per line." >&2
    exit 1
fi

# Validate the key and show remaining query credits before we spend any.
api_info=$(curl -sG "https://api.shodan.io/api-info" \
    --data-urlencode "key=$SHODAN_API_KEY")
if echo "$api_info" | jq -e '.error' >/dev/null 2>&1; then
    echo "ERROR: Shodan API key rejected: $(echo "$api_info" | jq -r '.error')" >&2
    exit 1
fi
credits=$(echo "$api_info" | jq -r '.query_credits // "unknown"')
echo "Shodan key OK. Query credits available: $credits"
echo

# ---- CSV header ----------------------------------------------------------
echo "domain,ip,port,hostnames,org,product,http_title,last_seen" > "$OUTPUT_CSV"

# ---- Main loop -----------------------------------------------------------
found_total=0

# Read domains, skipping blanks and comment lines (#...).
while IFS= read -r raw_domain || [[ -n "$raw_domain" ]]; do
    # trim whitespace / CR (in case the file came from Windows)
    domain="$(echo "$raw_domain" | tr -d '\r' | xargs 2>/dev/null)"
    [[ -z "$domain" ]] && continue
    [[ "$domain" == \#* ]] && continue

    query="$FINGERPRINT hostname:$domain"
    printf '==> Checking %-40s' "$domain"

    # Shodan returns at most 100 results per page and requires the "page"
    # parameter to retrieve the rest. Walk pages until we've collected every
    # match (or hit MAX_PAGES) so domains with many instances aren't truncated.
    # Raw match objects for this domain accumulate here, one JSON per line.
    domain_matches="$(mktemp)"
    page=1
    total=0
    api_err=""
    truncated=0
    while :; do
        response=$(curl -sG "https://api.shodan.io/shodan/host/search" \
            --data-urlencode "key=$SHODAN_API_KEY" \
            --data-urlencode "query=$query" \
            --data-urlencode "page=$page")

        # Handle API-level errors (bad plan, rate limit, etc.)
        if echo "$response" | jq -e '.error' >/dev/null 2>&1; then
            api_err=$(echo "$response" | jq -r '.error')
            break
        fi

        [[ "$page" -eq 1 ]] && total=$(echo "$response" | jq -r '.total // 0')
        page_count=$(echo "$response" | jq -r '.matches | length')

        # Append this page's raw match objects to the per-domain accumulator.
        echo "$response" | jq -c '.matches[]' >> "$domain_matches"

        collected=$(wc -l < "$domain_matches")
        # Stop when this page was empty, or we've gathered everything Shodan
        # reported, or we've hit the page cap (in which case flag truncation).
        if [[ "$page_count" -eq 0 || "$collected" -ge "$total" ]]; then
            break
        fi
        if [[ "$page" -ge "$MAX_PAGES" ]]; then
            truncated=1
            break
        fi
        page=$((page + 1))
        sleep "$RATE_LIMIT_SECONDS"
    done

    if [[ -n "$api_err" ]]; then
        echo "API ERROR: $api_err"
        rm -f "$domain_matches"
        sleep "$RATE_LIMIT_SECONDS"
        continue
    fi

    collected=$(wc -l < "$domain_matches")

    if [[ "$collected" -gt 0 ]]; then
        if [[ "$truncated" -eq 1 ]]; then
            echo "*** EXPOSED: $collected of $total result(s) — truncated at MAX_PAGES=$MAX_PAGES; raise it for the rest ***"
        else
            echo "*** EXPOSED: $collected result(s) ***"
        fi
        found_total=$((found_total + collected))
        # Emit one CSV row per matching host and print a short summary.
        jq -r --arg d "$domain" '
            [ $d,
              (.ip_str // ""),
              (.port // "" | tostring),
              ((.hostnames // []) | join(";")),
              (.org // ""),
              (.product // ""),
              (.http.title // "" | gsub("[\r\n,]"; " ")),
              (.timestamp // "")
            ] | @csv' "$domain_matches" >> "$OUTPUT_CSV"

        # Preserve the full raw Shodan artifact for each matching host,
        # tagging it with the domain we queried. One JSON object per line.
        jq -c --arg d "$domain" '{queried_domain: $d} + .' \
            "$domain_matches" >> "$JSON_TMP"

        jq -r '
            "      - " + (.ip_str // "?") + ":" + (.port|tostring) +
            "  hostnames=" + ((.hostnames // []) | join(",")) +
            "  org=" + (.org // "?")' "$domain_matches"
    else
        echo "clean (no exposed ShareFile controller found)"
    fi

    rm -f "$domain_matches"
    sleep "$RATE_LIMIT_SECONDS"
done < "$DOMAINS_FILE"

# ---- Summary -------------------------------------------------------------
# Slurp the per-host JSON lines into a single JSON array. If nothing was
# found, still emit a valid empty array so downstream tools don't choke.
if [[ -s "$JSON_TMP" ]]; then
    jq -s '.' "$JSON_TMP" > "$OUTPUT_JSON"
else
    echo "[]" > "$OUTPUT_JSON"
fi

echo
echo "-------------------------------------------------------------------"
echo "Done. Here are the total exposed ShareFile Storage Zone Controller hosts: $found_total"
echo "Full results written to: $OUTPUT_CSV"
echo "Raw Shodan artifacts (JSON) written to: $OUTPUT_JSON"
echo
echo "NOTE: A 'clean' result only means no *internet-exposed* controller"
echo "matched this fingerprint under that domain's known hostnames. It does"
echo "NOT prove the vendor doesn't run ShareFile internally. Combine this"
echo "with direct vendor outreach for full TPRM coverage."

2. Send a short, direct question to your critical vendors

Do not wait for the annual review cycle. Send a short, targeted questionnaire to your Tier 1 and critical vendors and ask two plain questions. First, do you run the on-premises ShareFile Storage Zone Controller? Second, if you do, did you follow the July 10 order to shut the servers down? This is the kind of moment that continuous monitoring, rather than a once-a-year questionnaire, is meant to catch.

3. Require evidence of an incident review before restart

For any vendor that runs the affected software, ask them to describe what they did in response. Because the shutdown preserves the machine state, vendors should review their system, application, and IIS logs before they bring the servers back online. Ask them to hunt for unauthorized .aspx webshells in web directories, which is a common sign of compromise for this kind of server. A vendor that cannot describe this review has not really closed the loop.

4. Set up a backup way to move files

Find any important business process that depends on an affected vendor for file transfer, then work with the business owner to set up a safe, temporary alternative until Progress clears the software. A short outage in a file exchange path can stall billing, onboarding, or reporting, so it helps to know the workaround before you need it.

Third-Party Risk Management Lessons

• Edge appliances deserve their own inventory. Internet-facing file transfer and file sharing servers are among the most attacked systems in any vendor's estate. Track which vendors run them, and which products they use, so you can move fast when the next advisory lands.
• A vendor's track record is a risk signal. ShareFile has now had serious flaws in 2023 and 2026, and its parent also owns MOVEit. Repeated critical issues in the same product line belong in your risk rating for that vendor.
• "No patch yet" is a real state you must plan for. This event had no fix and no CVE for days. Your vendor contracts and playbooks should cover what happens when the answer is "power it off and wait," not just "apply the update."
• Availability is a security problem too. Telling a vendor to shut down a production server protects data but can break a workflow you rely on. Plan for both the confidentiality and the availability side of the same event.

FAIR Risk Quantification

A FAIR analysis of this event should treat the exposed Storage Zone Controller as a shared point of failure across every vendor that runs one. The chance of a loss goes up with the number of internet-facing controllers in your vendor portfolio, and the size of the loss depends on how sensitive the files each vendor handles for you are. Because one flaw in one product can trigger many vendor events at once, the losses are correlated rather than independent, which is exactly the systemic pattern that makes edge file transfer software so costly when it fails. For more on putting a number on this kind of event, see our look at the true cost of a third-party breach.