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…

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…

OnionShare is an open source tool that lets you securely and anonymously share files, host websites, and chat with friends using the Tor network. Prior to 2.6.4, OnionShare CLI/Desktop does not enforce the Receive mode disable_files setting in cli/onionshare_cli/web/receive_mode.py, where ReceiveModeRequest._get_file_stream() writes multipart file[] data to disk despite the text-only setting. This issue is fixed in version 2.6.4.

These are all security issues fixed in the python3-onionshare-2.6.4-1.1 package on the GA media of openSUSE Tumbleweed.