Onionshare cli: OnionShare Receive mode writes uploaded files even when file uploads are disabled (CVE-2026-54707)
### Summary OnionShare CLI/Desktop 2.6.3 does not enforce the Receive mode `disable_files` setting at the file upload sink. When a Receive service is configured as a text-message-only endpoint (`--disable-files` / "Disable uploading files"), a remote sender who can reach the OnionShare service can still send a crafted multipart request containing `file[]`; OnionShare writes the uploaded bytes to disk before the route handler skips file accounting. This affects the shipped `onionshare-cli` Python package and the desktop application because both use the same `onionshare_cli.web.receive_mode` request-streaming implementation. ### Details Tested repository: `https://github.com/onionshare/onionshare` at commit `8cc75e1d7e88bd31f7276733449d412bf71c8999`. Affected product evidence: - `cli/pyproject.toml` declares `onionshare_cli` version `2.6.3`. - `desktop/pyproject.toml` declares `onionshare` version `2.6.3` and depends on `onionshare_cli` from `../cli`. - `cli/setup.py` publishes `onionshare-cli` and includes `onionshare_cli.web` plus templates/static resources. - `desktop/setup.py` publishes `onionshare` and exposes both `onionshare` and `onionshare-cli` console scripts. Reachable default/common paths: - CLI Receive mode is exposed through `--receive` (`cli/onionshare_cli/__init__.py:55-57`). - The `--disable-files` option is documented and stored in mode settings (`cli/onionshare_cli/__init__.py:156-160`, `cli/onionshare_cli/__init__.py:254-261`). - Desktop Receive mode exposes the same setting via the "Disable uploading files" checkbox and stores it as `receive.disable_files` (`desktop/onionshare/tab/mode/receive_mode/__init__.py:89-99`, `desktop/onionshare/tab/mode/receive_mode/__init__.py:246-254`). - User documentation says "Disable uploading files" should "only allow submitting text messages, like for an anonymous contact form" (`docs/source/features.rst:64`). - Advanced documentation lists `--disable-files` and `disable_files` as the option to disable receiving files (`docs/source/advanced.rst:162-163`, `docs/source/advanced.rst:455`). Root cause: - The Receive template hides the file input when `disable_files` is set (`cli/onionshare_cli/resources/templates/receive.html:51-56`), but this is only UI-side. - The `/upload` route skips `request.files.getlist("file[]")` and file accounting when `disable_files` is enabled (`cli/onionshare_cli/web/receive_mode.py:96-135`). However, by this point Werkzeug has already parsed the multipart body and invoked the custom stream factory. - `ReceiveModeRequest.__init__()` treats every `POST /upload` or `POST /upload-ajax` as an upload request and creates a receive directory regardless of `disable_files` (`cli/onionshare_cli/web/receive_mode.py:369-391`). - `ReceiveModeRequest._get_file_stream()` creates a writable `ReceiveModeFile` for each uploaded part without checking `self.web.settings.get("receive", "disable_files")` (`cli/onionshare_cli/web/receive_mode.py:517-540`). - `ReceiveModeFile` opens `<receive_mode_dir>/<secure_filename>.part`, writes attacker-controlled bytes, then renames the `.part` file to the final filename (`cli/onionshare_cli/web/receive_mode.py:272-285`, `cli/onionshare_cli/web/receive_mode.py:320-346`). False-positive screening performed: - `secure_filename()` is used at `cli/onionshare_cli/web/receive_mode.py:111-113` and `cli/onionshare_cli/web/receive_mode.py:527-528`, so the confirmed issue is not path traversal; the file is written under the configured receive data directory. - The UI hiding the file input is bypassable by direct multipart POST. - Route-level `if not disable_files` only affects later accounting/status/webhook behavior; it does not prevent the stream sink from creating and writing the file. - Default non-public onion services require the sender to know the onion address and private key unless the user opts into public mode. This limits exposure but does not enforce the user-selected "text only" security policy for authorized senders or public contact-form deployments. - A control case with `disable_text=True` showed submitted text was not written as a message file, demonstrating the harness was exercising the settings boundary. Affected versions / patched versions: - Affected versions: unknown; confirmed in version `2.6.3` at commit `8cc75e1d7e88bd31f7276733449d412bf71c8999`. Earlier versions were not tested during this audit. - Patched versions: 2.6.4 Severity: Rationale: `AV:N` because the Receive endpoint is reached over the OnionShare HTTP service; `AC:L` because a crafted multipart POST is straightforward once the service is reachable; `PR:L` because the sender generally needs the OnionShare URL/private key unless the receiver intentionally runs public mode; `UI:N` because no further receiver interaction is required after service startup; `S:U` because the same local application writes the file; `C:N` because this PoC does not read data; `I:L` because the attacker writes unwanted files in a mode configured to
AI Analysis
Technical Summary
OnionShare CLI/Desktop 2.6.3 does not properly enforce the 'disable_files' setting in Receive mode at the file upload sink. Although the UI hides the file upload input and route handlers skip file accounting when 'disable_files' is enabled, the underlying request processing still creates and writes uploaded files to disk. This occurs because Werkzeug parses the multipart body and invokes the custom stream factory before the application checks the 'disable_files' setting. The vulnerability allows an attacker who can reach the OnionShare service to upload files despite the intended restriction. The issue was confirmed at commit 8cc75e1d7e88bd31f7276733449d412bf71c8999 and affects versions prior to 2.6.4. The root cause is a logic flaw where file streams are created and written without checking the 'disable_files' flag, leading to unwanted file writes in a mode configured to disallow them.
Potential Impact
An attacker with access to the OnionShare Receive endpoint can upload arbitrary files even when file uploads are disabled, causing unwanted files to be written to the receiver's disk. This does not allow reading or modifying existing files, nor does it disclose data. The impact is limited to integrity (I:L) and availability (A:L) because the attacker can write files but cannot read data or execute code. The vulnerability requires knowledge of the OnionShare address and private key unless the service is run in public mode, limiting exposure. The severity is rated medium with a CVSS score of 5.4.
Mitigation Recommendations
A patch is available in OnionShare version 2.6.4 that fixes this issue by properly enforcing the 'disable_files' setting at the file upload sink. Users should upgrade to version 2.6.4 or later to remediate this vulnerability. Until patched, users should avoid running the Receive mode with 'disable_files' enabled in environments where untrusted senders can reach the service. No other mitigations are documented or necessary once patched.
Onionshare cli: OnionShare Receive mode writes uploaded files even when file uploads are disabled (CVE-2026-54707)
Description
### Summary OnionShare CLI/Desktop 2.6.3 does not enforce the Receive mode `disable_files` setting at the file upload sink. When a Receive service is configured as a text-message-only endpoint (`--disable-files` / "Disable uploading files"), a remote sender who can reach the OnionShare service can still send a crafted multipart request containing `file[]`; OnionShare writes the uploaded bytes to disk before the route handler skips file accounting. This affects the shipped `onionshare-cli` Python package and the desktop application because both use the same `onionshare_cli.web.receive_mode` request-streaming implementation. ### Details Tested repository: `https://github.com/onionshare/onionshare` at commit `8cc75e1d7e88bd31f7276733449d412bf71c8999`. Affected product evidence: - `cli/pyproject.toml` declares `onionshare_cli` version `2.6.3`. - `desktop/pyproject.toml` declares `onionshare` version `2.6.3` and depends on `onionshare_cli` from `../cli`. - `cli/setup.py` publishes `onionshare-cli` and includes `onionshare_cli.web` plus templates/static resources. - `desktop/setup.py` publishes `onionshare` and exposes both `onionshare` and `onionshare-cli` console scripts. Reachable default/common paths: - CLI Receive mode is exposed through `--receive` (`cli/onionshare_cli/__init__.py:55-57`). - The `--disable-files` option is documented and stored in mode settings (`cli/onionshare_cli/__init__.py:156-160`, `cli/onionshare_cli/__init__.py:254-261`). - Desktop Receive mode exposes the same setting via the "Disable uploading files" checkbox and stores it as `receive.disable_files` (`desktop/onionshare/tab/mode/receive_mode/__init__.py:89-99`, `desktop/onionshare/tab/mode/receive_mode/__init__.py:246-254`). - User documentation says "Disable uploading files" should "only allow submitting text messages, like for an anonymous contact form" (`docs/source/features.rst:64`). - Advanced documentation lists `--disable-files` and `disable_files` as the option to disable receiving files (`docs/source/advanced.rst:162-163`, `docs/source/advanced.rst:455`). Root cause: - The Receive template hides the file input when `disable_files` is set (`cli/onionshare_cli/resources/templates/receive.html:51-56`), but this is only UI-side. - The `/upload` route skips `request.files.getlist("file[]")` and file accounting when `disable_files` is enabled (`cli/onionshare_cli/web/receive_mode.py:96-135`). However, by this point Werkzeug has already parsed the multipart body and invoked the custom stream factory. - `ReceiveModeRequest.__init__()` treats every `POST /upload` or `POST /upload-ajax` as an upload request and creates a receive directory regardless of `disable_files` (`cli/onionshare_cli/web/receive_mode.py:369-391`). - `ReceiveModeRequest._get_file_stream()` creates a writable `ReceiveModeFile` for each uploaded part without checking `self.web.settings.get("receive", "disable_files")` (`cli/onionshare_cli/web/receive_mode.py:517-540`). - `ReceiveModeFile` opens `<receive_mode_dir>/<secure_filename>.part`, writes attacker-controlled bytes, then renames the `.part` file to the final filename (`cli/onionshare_cli/web/receive_mode.py:272-285`, `cli/onionshare_cli/web/receive_mode.py:320-346`). False-positive screening performed: - `secure_filename()` is used at `cli/onionshare_cli/web/receive_mode.py:111-113` and `cli/onionshare_cli/web/receive_mode.py:527-528`, so the confirmed issue is not path traversal; the file is written under the configured receive data directory. - The UI hiding the file input is bypassable by direct multipart POST. - Route-level `if not disable_files` only affects later accounting/status/webhook behavior; it does not prevent the stream sink from creating and writing the file. - Default non-public onion services require the sender to know the onion address and private key unless the user opts into public mode. This limits exposure but does not enforce the user-selected "text only" security policy for authorized senders or public contact-form deployments. - A control case with `disable_text=True` showed submitted text was not written as a message file, demonstrating the harness was exercising the settings boundary. Affected versions / patched versions: - Affected versions: unknown; confirmed in version `2.6.3` at commit `8cc75e1d7e88bd31f7276733449d412bf71c8999`. Earlier versions were not tested during this audit. - Patched versions: 2.6.4 Severity: Rationale: `AV:N` because the Receive endpoint is reached over the OnionShare HTTP service; `AC:L` because a crafted multipart POST is straightforward once the service is reachable; `PR:L` because the sender generally needs the OnionShare URL/private key unless the receiver intentionally runs public mode; `UI:N` because no further receiver interaction is required after service startup; `S:U` because the same local application writes the file; `C:N` because this PoC does not read data; `I:L` because the attacker writes unwanted files in a mode configured to
CVSS v3.1
Score 5.4medium
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
OnionShare CLI/Desktop 2.6.3 does not properly enforce the 'disable_files' setting in Receive mode at the file upload sink. Although the UI hides the file upload input and route handlers skip file accounting when 'disable_files' is enabled, the underlying request processing still creates and writes uploaded files to disk. This occurs because Werkzeug parses the multipart body and invokes the custom stream factory before the application checks the 'disable_files' setting. The vulnerability allows an attacker who can reach the OnionShare service to upload files despite the intended restriction. The issue was confirmed at commit 8cc75e1d7e88bd31f7276733449d412bf71c8999 and affects versions prior to 2.6.4. The root cause is a logic flaw where file streams are created and written without checking the 'disable_files' flag, leading to unwanted file writes in a mode configured to disallow them.
Potential Impact
An attacker with access to the OnionShare Receive endpoint can upload arbitrary files even when file uploads are disabled, causing unwanted files to be written to the receiver's disk. This does not allow reading or modifying existing files, nor does it disclose data. The impact is limited to integrity (I:L) and availability (A:L) because the attacker can write files but cannot read data or execute code. The vulnerability requires knowledge of the OnionShare address and private key unless the service is run in public mode, limiting exposure. The severity is rated medium with a CVSS score of 5.4.
Mitigation Recommendations
A patch is available in OnionShare version 2.6.4 that fixes this issue by properly enforcing the 'disable_files' setting at the file upload sink. Users should upgrade to version 2.6.4 or later to remediate this vulnerability. Until patched, users should avoid running the Receive mode with 'disable_files' enabled in environments where untrusted senders can reach the service. No other mitigations are documented or necessary once patched.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-v833-3823-cmhp
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-54707"]
- Ecosystems
- ["PyPI"]
- Database Specific Severity
- MODERATE
- Cvss Version
- 3.1
Threat ID: 6a6cf7f2bf32cb7a342b4077
Added to database: 07/31/2026, 19:30:58 UTC
Last enriched: 07/31/2026, 20:19:59 UTC
Last updated: 09/13/2026, 22:01:35 UTC
Views: 26
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.