CVE-2026-54707 Overview
CVE-2026-54707 is an authorization flaw in OnionShare, an open source tool that shares files, hosts websites, and enables chat over the Tor network. Versions prior to 2.6.4 fail to enforce the Receive mode disable_files setting. The affected code path in cli/onionshare_cli/web/receive_mode.py writes multipart file[] uploads to disk even when the operator configured a text-only receive service. The issue maps to [CWE-863: Incorrect Authorization] and is fixed in OnionShare 2.6.4.
Critical Impact
Remote users with access to a Receive-mode onion service can upload arbitrary files to the host despite an explicit text-only configuration, bypassing an operator-controlled security setting.
Affected Products
- OnionShare CLI versions prior to 2.6.4
- OnionShare Desktop versions prior to 2.6.4
- Deployments using Receive mode with the disable_files setting enabled
Discovery Timeline
- 2026-07-31 - CVE-2026-54707 published to NVD
- 2026-08-01 - Last updated in NVD database
Technical Details for CVE-2026-54707
Vulnerability Analysis
OnionShare's Receive mode accepts uploads from remote clients over a Tor hidden service. Operators can configure the service as text-only by enabling disable_files, restricting submissions to text messages. The ReceiveModeRequest._get_file_stream() method in cli/onionshare_cli/web/receive_mode.py handles incoming multipart form data.
The method does not consult the disable_files flag before opening a stream for uploaded file[] parts. As a result, the server writes attached files to the configured upload directory even when the operator disabled file receipt. The text-only guarantee presented in the user interface is not enforced at the request-handling layer.
Root Cause
The root cause is a missing authorization check in _get_file_stream(). The function accepts and persists multipart file content without validating the current mode settings. The disable_files flag is honored elsewhere in the UI and validation logic but not in the stream handler that materializes uploads to disk, producing the [CWE-863] mismatch between intended policy and enforced policy.
Attack Vector
An attacker who can reach the Receive-mode onion service and authenticate with the required credentials submits an HTTP POST request containing a multipart/form-data body with one or more file[] fields. The server, despite being configured for text-only submissions, writes the attachments to the receive directory. Exploitation requires network access to the service and low-privilege authentication, but no user interaction on the operator side.
No verified public proof-of-concept code is available. See the GitHub Security Advisory GHSA-v833-3823-cmhp and the fix commit for the authoritative technical description.
Detection Methods for CVE-2026-54707
Indicators of Compromise
- Unexpected files appearing in the OnionShare receive directory on hosts configured with disable_files enabled.
- HTTP request logs from the OnionShare Flask server showing POST requests containing Content-Disposition: form-data; name="file[]" fields against text-only receive services.
- OnionShare event history entries recording file uploads on services the operator believed were text-only.
Detection Strategies
- Inventory hosts running OnionShare and compare installed versions against 2.6.4 to identify vulnerable installations.
- Audit the OnionShare configuration for services with disable_files set to true and verify their upload directories for unexpected artifacts.
- Correlate outbound Tor process activity with new files written to ~/OnionShare or the configured data_dir.
Monitoring Recommendations
- Enable file integrity monitoring on the OnionShare data directory and alert on new file creation.
- Log and review multipart form submissions handled by the OnionShare CLI in verbose mode for services intended to be text-only.
- Track OnionShare process invocations and command-line arguments through endpoint telemetry to identify unauthorized Receive-mode services.
How to Mitigate CVE-2026-54707
Immediate Actions Required
- Upgrade OnionShare CLI and Desktop to version 2.6.4 or later on all systems.
- Stop any running Receive-mode services configured with disable_files until the upgrade is complete.
- Review the OnionShare receive directory for files that arrived while the vulnerable version was in use.
Patch Information
The issue is fixed in OnionShare 2.6.4. The corrective change is described in the GitHub Security Advisory GHSA-v833-3823-cmhp, applied in commit a090e97, and shipped in the v2.6.4 release. The patch enforces the disable_files setting in ReceiveModeRequest._get_file_stream() so multipart file parts are rejected on text-only services.
Workarounds
- Do not rely on the disable_files setting on vulnerable versions; assume file uploads are possible on any Receive-mode service.
- Restrict access to Receive-mode services by sharing the onion address and credentials only with trusted parties until patched.
- Run OnionShare inside a sandbox or dedicated user account with a restricted upload directory to limit the impact of unintended file writes.
# Verify the installed OnionShare version and upgrade
onionshare-cli --version
pip install --upgrade onionshare-cli>=2.6.4
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
