Someone on Torrent Sites Kept Fucking with My Sonarr
- ID
- 36199
- Status
- summarized
- Published
- 16 Oct 2026, 3:21 AM
- Fetched
- 16 Oct 2026, 2:35 PM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://thereallo.dev/blog/someone-on-torrent-sites-kept-fucking-with-my-sonarr-setup
- Source URL
- https://hnrss.org/best
Summary
- Score
- 6.8
- Created
- 16 Oct 2026, 2:36 PM
- Tags
- Audience
- developers
What happened
Someone uploaded a fake South Park episode named 'South Park S29E03 1080p WEB H264-MeGusta.exe' with 2,392 seeders; Sonarr grabbed it and retried the failed import every 90 seconds, while qBittorrent marked it finished with total_downloaded: 0. The author blocklisted it, then re-downloaded and reverse-engineered it: the file is 887 MB, but only 118 KB is a real x64 PE, with 886,653,736 bytes of overlay junk, XOR-based decompiler obfuscation, and a last-64-byte footer containing a ChaCha20 nonce/payload size config for in-memory execution.
Why it matters
If you run Sonarr, qBittorrent, or any automated download/import pipeline, do not rely on release-name matching or qBittorrent's 'finished' flag; this case had 2,392 seeders and total_downloaded: 0 while Sonarr kept retrying a .exe import every 90 seconds. Add extension/blocklist checks and alert on repeated import failures so automation does not keep ingesting malicious junk. No Malaysia/SEA-specific hook appears in the text.
Discussion angle
How should *arr/Sonarr and similar automation handle .exe or zero-byte 'finished' downloads? The write-up's footer shows a ChaCha20 payload hidden in an 887 MB overlay, so what minimal validation would catch this before import?