httprpc: incomplete rTorrent 0.16.9 trust fix — `default` case still blocks `load.start`

[de666]

Please complete the following tasks.

• Web browser cache cleared
• Link provided to install script if applicable
• Not using broken rtinst install script
• Web browser, ruTorrent, PHP and OS version provided

Tell us about your environment

https://github.com/crazy-max/docker-rtorrent-rutorrent
Browser not relevant

Tell us how you installed ruTorrent

https://github.com/crazy-max/docker-rtorrent-rutorrent

Describe the bug

Description

The v5.3.0 fix for rTorrent 0.16.9 compatibility (commit 87315d6) is incomplete.

External clients that use plugins/httprpc/action.php as their RPC endpoint (Prowlarr, Sonarr,
Radarr, Transdrone, NZB360, etc.) still receive the following error when trying to add torrents:

rTorrent returned error code 0: Command "load.start" is not allowed for untrusted connections

Steps to reproduce

1. configure and run https://github.com/crazy-max/docker-rtorrent-rutorrent
2. configure and run prowlarr
3. configure rutorrent as a client inside prowlarr through httprcp
4. try to add any torrent from prowlarr

Expected behavior

Torrent is added correctly

Additional context

Background: rTorrent 0.16.9 trust model

rTorrent 0.16.9 introduced a trusted/untrusted XMLRPC connection security model based on the
UNTRUSTED_CONNECTION SCGI header flag. When set to 1, rTorrent restricts the connection to
a whitelist of allowed commands, blocking anything not explicitly listed — including load.start,
load.raw.start, and others commonly used by external clients.

The flag is set in php/xmlrpc.php (line ~109):

$reqheader = "CONTENT_LENGTH\x0".$contentlength."\x0"."CONTENT_TYPE\x0"."text/xml\x0"
           . "SCGI\x0"."1\x0UNTRUSTED_CONNECTION\x0".($trusted ? "0" : "1")."\x0";

The $trusted parameter propagates from rXMLRPCRequest::send($data, $trusted),
rXMLRPCRequest::run($trusted), and rXMLRPCRequest::success($trusted).

What the v5.3.0 fix addressed

The fix correctly changed all ->success(false) calls to ->success(true) throughout
action.php, covering all the named modes (list, start, stop, pause, remove, etc.)
used by the ruTorrent UI itself.

What was missed

There is one remaining call that still passes false — the default case, which handles
raw XMLRPC pass-through:

default:
{
    if(isset($HTTP_RAW_POST_DATA))
    {
        $result = rXMLRPCRequest::send($HTTP_RAW_POST_DATA, false); // ← still untrusted

This is exactly the code path used by external clients like Prowlarr, Sonarr, and Radarr.
These clients do not use the named modes — they send raw XMLRPC payloads directly, which are
handled exclusively by this default case. As a result, commands like load.start are still
rejected by rTorrent 0.16.9 even after upgrading to ruTorrent v5.3.0.

How I found this

The error first appeared when Prowlarr (configured to use plugins/httprpc/action.php as the
RPC endpoint) stopped being able to add torrents after upgrading to rTorrent 0.16.9.

Tracing the request path:

• Prowlarr sends a raw XMLRPC payload to plugins/httprpc/action.php
• Since the payload does not match any named $mode, it falls through to the default case
• rXMLRPCRequest::send($HTTP_RAW_POST_DATA, false) is called, setting UNTRUSTED_CONNECTION: 1
• rTorrent 0.16.9 rejects load.start as it is not on the untrusted whitelist

The named modes (start, stop, etc.) work correctly after the v5.3.0 fix because they all
use ->success(true). Only the raw pass-through path remains broken.

Why marking this as trusted is correct and safe

The default case is only reachable by clients that have already passed through nginx
authentication (HTTP basic auth or similar) configured by the image. The trusted/untrusted
distinction in rTorrent 0.16.9 is designed to separate unauthenticated external network
connections from trusted local ones — not to filter commands within an already-authenticated
PHP proxy. Marking this connection as untrusted is therefore inconsistent with how all other
modes in the same file are treated.

Fix

One-line change in plugins/httprpc/action.php:

- $result = rXMLRPCRequest::send($HTTP_RAW_POST_DATA, false);
+ $result = rXMLRPCRequest::send($HTTP_RAW_POST_DATA, true);

Affected clients

Any client configured to use /plugins/httprpc/action.php as the RPC endpoint and sending
raw XMLRPC payloads, including:

• Prowlarr
• Sonarr (with rTorrent integration)
• Radarr (with rTorrent integration)
• Transdrone / Transdroid
• NZB360
• Any other *arr or automation tool using raw XMLRPC

Workaround (until fixed)

Add the following to a custom init script (mapped into /etc/cont-init.d/ for
crazy-max/docker-rtorrent-rutorrent, or equivalent for other setups):

ACTION_PHP="/var/www/rutorrent/plugins/httprpc/action.php"

if grep -qF 'success(false)' "$ACTION_PHP" || grep -qF 'send($HTTP_RAW_POST_DATA,false)' "$ACTION_PHP"; then
    sed -i 's/success(false)/success(true)/g' "$ACTION_PHP"
    sed -i 's/send(\$HTTP_RAW_POST_DATA,false)/send(\$HTTP_RAW_POST_DATA,true)/g' "$ACTION_PHP"
    echo "httprpc action.php patched"
else
    echo "httprpc action.php already patched, skipping"
fi

References

• rTorrent 0.16.9 release: https://github.com/rakshasa/rtorrent/releases/tag/v0.16.9
• ruTorrent v5.3.0 partial fix: 87315d6

[xirvik]

@de666 have you tried 5.3.1?

[de666]

@de666 have you tried 5.3.1?

I didn't try directly version 5.3.1 but I tried to patch action.php only with

sed -i 's/success(false)/success(true)/g'

and without

sed -i 's/send(\$HTTP_RAW_POST_DATA,false)/send(\$HTTP_RAW_POST_DATA,true)/g'

and it didn't work
that's why I assume there is something missing in the patch for 5.3.0 and 5.3.1 since there are no modification in action.php about how the plugin manages the load.start command

[xirvik]

I recommended you don't change the default to trusted. It will "work" but it defeats the whole security model. You never know if you are going to pay for the convenience.

nginx auth only helps with trusting the user, but it doesn't help trusting the software the user is running - we all run software that hasn't been vetted and hope that some other layer has sanity checks in place. A problem with using AI to troubleshoot these things is that they always make up excuses to justify cutting corners. You don't want a hacked prowlarr to find an unsecure rtorrent.

Let's be careful here and spend a bit of time getting it right... take a look at #3047 , please give it a shot. Does it work for you? If not, can you share example payloads (they will be logged) that should work but don't?

[de666]

Also I had the same doubts about make the default case trusted, I ask Claude about that and the response seemes to be reasonable for me but your way of whitelisting the load.start command is indeed a lot better.
I just hope there are no other commands (not whitelisted) *arrs can use which can lead to the same issue.
Anyway mine was a workaround and I just wanted to point out something which has to be addressed other than the actual patch which is not covering that use case (which I believe could be quite common for the other users).
Is there a simple way to test it?
Can I use it to patch directly version 5.2.0?

[de666]

@xirvik just for the record it seems that *arrs can use the following methods:

system.client_version, d.multicall2, load.start, load.normal, load.raw_start, load.raw, d.custom1.set, d.priority.set, d.directory.set, d.views.push_back_unique, d.erase, d.name

so if you plan to make some sort of patch to handle this you have to add all the listed commands
I will try to test your patch with the listed methods above and let you know if it works
thanks for now!

[de666]

@xirvik just for the record it seems that *arrs can use the following methods:

system.client_version, d.multicall2, load.start, load.normal, load.raw_start, load.raw, d.custom1.set, d.priority.set, d.directory.set, d.views.push_back_unique, d.erase, d.name

so if you plan to make some sort of patch to handle this you have to add all the listed commands I will try to test your patch with the listed methods above and let you know if it works thanks for now!

nevermind, I just realize all the other methods but d.directory.set are already marked as trusted by rtorrent

[xirvik]

@de666 Can you try this?

xirvik@114eec6

The "sanitize" mode is of course the relevant one now .

[de666]

@de666 Can you try this?

xirvik@114eec6

The "sanitize" mode is of course the relevant one now .

It works, at least with prowlarr and load.start method
Thank you!

[fffe]

It works, at least with prowlarr and load.start method Thank you!

Are you sure?

If you're on a recent version Prowlarr shouldn't be able to set priorities, labels, or directories (the patch strips all trailing commands).

If you're on an older version, the commands to set priorities, labels & directories are run separately and will fail the safe list check for untrusted connections.

[de666]

@fffe You're right, I obviously didn't test it properly. I tried again starting from
https://github.com/crazy-max/docker-rtorrent-rutorrent/releases/tag/5.3.1-0.16.10-r0
and it doesn't seem to work.
I get the following error from prowlarr when I try to test the connection with rtorrent.

prowlarr  | [Warn] ProwlarrErrorPipeline: Invalid request Validation failed:
prowlarr  |  -- : Failed to get the list of torrents: rTorrent returned error code 0: Command "d.complete" is not allowed for untrusted connections.

and I have the following in rutorrent logfile

[2026-04-28 11:29:49] xmlrpc-proxy: untrusted: system.client_version
[2026-04-28 11:29:49] xmlrpc-proxy: untrusted: d.multicall2

@xirvik tell me if you need other tests

[xirvik]

@xirvik tell me if you need other tests

Appreciate you helping here. I plan to spend some hours on this next week; report every single issue you find. I expect this to take a few iterations to get right, since we're going the whitelist route.

That's acceptable IMHO, I prefer to find the real life scenarios we care about and by default disable everything else.

People who just want and open proxy and whatever happens happens can also configure that, but the default needs to be a best-effort secure plugin.

[xirvik]

@de666 Take a look at xirvik@cd05700 if you have a chance please.