Security · 26 Aug 2026 · Rob Nidschelm

SABnzbd’s Password Could Be Bypassed. A Download Could Plant the Code That Ran Next.

SABnzbd 5.1.2 closes two routes to code execution and carries forward a fix for a separate critical authentication bypass. The three vulnerabilities are different, but they expose the same architectural problem: data from an untrusted request or download was allowed to influence a trusted operation.

One flaw lets an unauthenticated caller reach protected configuration handlers and ultimately run commands. Another lets metadata inside a downloaded PAR2 file move content outside its job folder, where a carefully placed Python pickle can be loaded as trusted state. The third makes the logout endpoint issue a valid logged-in session.

Public technical details reproduce all three conditions. There is no confirmed evidence of malicious exploitation, and none of the three 2026 vulnerabilities currently has a CVE identifier. That distinction matters: the exposure is real and the path has been demonstrated, but public proof of concept is not the same as observed attacks.

One release, three separate failures

The release notes group the issues together, but operators need to evaluate each one separately. The web-interface flaws depend on an untrusted party being able to reach SABnzbd. The download-processing flaw can matter even when the interface remains local.

1. A public API mode became an authorisation decision

GHSA-rgqj-28c2-gxwp is rated critical at 9.8. The researcher confirmed it in SABnzbd 5.1.1, while the project’s release notes describe 5.1.1 and earlier as affected. The exact introducing version has not been established. Version 5.1.2 contains the fix.

The root cause is an authorisation-context mix-up. Some protected WebUI handlers rely on an API-key check. That check reads the attacker-controlled mode parameter and allows public API operations such as version queries. SABnzbd had already dispatched the request to a different, privileged handler, but the public-mode exception was still accepted there.

The demonstrated chain used that bypass to change configuration, point the scripts folder at /bin, select the shell as a pre-queue script and submit job metadata that became command arguments. The command ran with the permissions of the SABnzbd process.

• Prerequisites: the WebUI must be reachable by an untrusted party; the demonstrated chain used the default config_lock=0; the command-execution proof used a Unix-like system with /bin/sh.
• Fixed version: 5.1.2.
• Workaround: prevent untrusted access to the WebUI until the update can be applied.
• Evidence: public, reproducible technical detail; no confirmed malicious exploitation.

2. A download escaped its own job

GHSA-75g3-96fr-7p2r is rated high at 7.5. The unsafe PAR2 filename-recovery caller exists in versions 3.1.0 through 5.1.1. The route became reachable under default post-processing settings in 3.4.0 and remained so through 5.1.1. Version 5.1.2 fixes it.

A filename recovered from PAR2 metadata was joined to a destination path without verifying that the result remained inside the current job directory. The researcher reproduced a direct traversal under default post-processing settings, causing downloaded content to be moved outside its originating folder.

The more consequential chain crossed a second trust boundary. SABnzbd stores verification state in another job’s __ADMIN__/__verified__ file and later loads it with unrestricted Python pickle.load(). By making one attacker-controlled job place a malicious pickle into another job’s trusted state directory, the researcher achieved command execution when the target job later began verification.

The full code-execution chain is more demanding than the underlying traversal. It requires two attacker-controlled jobs, a predictable target directory, the target administration directory to exist and favourable processing order. The researcher reproduced the ordering automatically by assigning the planting job a higher priority, but did not demonstrate that malicious NZB metadata alone could force that priority in an untouched Sonarr or Radarr deployment.

The finding is also a warning about incomplete remediation. The project previously fixed CVE-2021-29488 by adding path containment to the original PAR2 caller. A separate recovery path did not enable that protection and later became active by default. The old fix protected the route it targeted; the parallel route remained outside it.

• Prerequisites: SABnzbd must process an attacker-controlled NZB or download. The basic traversal works under default post-processing settings. The RCE chain has additional cross-job timing and predictability requirements.
• Fixed version: 5.1.2.
• Workaround: the vendor says there is no configuration change that prevents this issue. Update is the only mitigation.
• Evidence: the researcher published detailed reproduction evidence; no confirmed malicious exploitation.

3. Logging out created a logged-in session

GHSA-xrfq-jhgh-wqch is rated critical at 9.4. It affects SABnzbd 5.1.0 and earlier and was fixed in 5.1.1, so 5.1.2 also contains the correction.

An unauthenticated request to the logout route returned valid session-cookie values. A caller who could reach the password-protected WebUI could request that endpoint, reuse the issued cookies from the same IP address and gain full access without knowing the configured username or password.

• Prerequisites: the WebUI must be reachable by the attacker and SABnzbd’s built-in username and password must be the relevant access control.
• Fixed version: 5.1.1; upgrading to 5.1.2 includes the fix.
• Workaround: remove untrusted access to the WebUI. The project also documents lowering external access to Full API or below when an immediate update is impossible.
• Evidence: a public proof of concept is included in the advisory; no confirmed malicious exploitation.

Exposure decides which flaw matters

SABnzbd says its WebUI is local-only by default and that External internet access defaults to No access. An installation that retains those defaults is not remotely exposed to the two WebUI flaws. A separate reverse proxy that performs authentication before traffic reaches SABnzbd also changes the path.

That reassurance does not cover the malicious-download issue. A local SABnzbd instance can still accept material from a public indexer or another source the operator does not fully trust. The relevant boundary is no longer the WebUI. It is the point where downloaded metadata becomes a filesystem destination and then trusted application state.

What operators should do now

• Upgrade SABnzbd to 5.1.2. The project supports direct upgrades from version 3.0.0 and newer.
• Confirm that the WebUI is not directly reachable from the internet or an untrusted network. Do not treat SABnzbd’s own password as the only perimeter control.
• If the interface was exposed while relying on built-in authentication, change the SABnzbd username and password, API key, Usenet server passwords, indexer API keys used in RSS feeds and authentication data for notification services.
• Review reverse-proxy and container publishing rules. A local-only application can become externally reachable through a port mapping, proxy route or overly broad trusted-network definition.
• Treat untrusted NZBs and public indexers as input capable of reaching the filesystem, not merely as catalogue data.

The important boundary was not where it looked

The most useful lesson is not that download software should stay off the internet, although it should. It is that the dangerous boundary can move. In one flaw, a parameter intended to describe an API operation became permission to run a different handler. In another, a filename escaped its job and became trusted serialized state. In the third, an endpoint meant to end a session created one.

Each transition looked ordinary inside one component. The security failure appeared only when the transitions were composed.