starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

"run external program" should not be settable via the WebUI/API #16974

New issue

Open

opened 2026-02-22 03:34:40 -05:00 by deekerman · 12 comments

deekerman commented

2026-02-22 03:34:40 -05:00

Owner

Originally created by @majora2007 on GitHub (Jun 22, 2025).

qBittorrent & operating system versions

qBittorrent: 5.0.3 x64
Operating system: Windows 10
Qt: 6.7.3

What is the problem?

When qbittorrent webui/api are enabled, setting "run external program" is allowed to be set. If your password is broken, a hijacker can quickly install a script on your machine.

I believe this setting should be modifiable only via the app and not via the webui.

Steps to reproduce

No response

Additional context

Log(s) & preferences file(s)

N/A

Originally created by @majora2007 on GitHub (Jun 22, 2025). ### qBittorrent & operating system versions qBittorrent: 5.0.3 x64 Operating system: Windows 10 Qt: 6.7.3 ### What is the problem? When qbittorrent webui/api are enabled, setting "run external program" is allowed to be set. If your password is broken, a hijacker can quickly install a script on your machine. I believe this setting should be modifiable only via the app and not via the webui. ### Steps to reproduce _No response_ ### Additional context ![Image](https://github.com/user-attachments/assets/1e1ee394-2cde-4b8d-9cd1-17980d7f0984) ### Log(s) & preferences file(s) N/A

deekerman added the

Security

WebAPI

labels

2026-02-22 03:34:40 -05:00

deekerman commented

2026-02-22 03:34:43 -05:00

Author

Owner

@Vagelis1608 commented on GitHub (Jun 23, 2025):

I would like to point out that then there would be no way to set it on a headless installation, like mine.

Set a better password.

@Vagelis1608 commented on GitHub (Jun 23, 2025): I would like to point out that then there would be no way to set it on a headless installation, like mine. Set a better password.

deekerman commented

2026-02-22 03:34:45 -05:00

Author

Owner

@majora2007 commented on GitHub (Jun 24, 2025):

Headless is a valid constraint. I still believe that this is a pretty large security issue. Perhaps this could be configured via a settings for advanced users to allow setting these fields.

@majora2007 commented on GitHub (Jun 24, 2025): Headless is a valid constraint. I still believe that this is a pretty large security issue. Perhaps this could be configured via a settings for advanced users to allow setting these fields.

deekerman commented

2026-02-22 03:34:45 -05:00

Author

Owner

@beigexperience commented on GitHub (Jun 24, 2025):

What if there is an env var that you would need to set through the container orchestration or whatever is launching this if not in a container that would allow this function to be settable via the web ui?

@beigexperience commented on GitHub (Jun 24, 2025): What if there is an env var that you would need to set through the container orchestration or whatever is launching this if not in a container that would allow this function to be settable via the web ui?

deekerman commented

2026-02-22 03:34:45 -05:00

Author

Owner

@glassez commented on GitHub (Jun 25, 2025):

What if there is an env var that you would need to set through the container orchestration or whatever is launching this if not in a container that would allow this function to be settable via the web ui?

In this case, would it make sense to set the "run external program" value itself through an environment variable, completely prohibiting doing it through the WebAPI?

@glassez commented on GitHub (Jun 25, 2025): > What if there is an env var that you would need to set through the container orchestration or whatever is launching this if not in a container that would allow this function to be settable via the web ui? In this case, would it make sense to set the "run external program" value itself through an environment variable, completely prohibiting doing it through the WebAPI?

deekerman commented

2026-02-22 03:34:45 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Jun 25, 2025):

Keep in mind that:

WebUI isn't enabled by default. EDIT: True only for GUI builds.
When enabled, WebUI access requires authentication by default
Until user explicitly sets their own password qbt generates a random password each time the client starts.

The above limit the exploitability of a running client.

Is it worth it to hide some dangerous APIs under an explicit cmdline/env var option? Maybe. If someone wants to implement it, IMO, we shouldn't reject it.
If implemented, then I suggest: For the current series the default is to continue allowing the API but displaying a future deprecation notice both in the log and in the relevant field in the preferences UI. In the next series, the default will be to restrict these APIs and require the presence of this cmdline/env.

In this case, would it make sense to set the "run external program" value itself through an environment variable, completely prohibiting doing it through the WebAPI?

Probably a valid approach too.

@sledgehammer999 commented on GitHub (Jun 25, 2025): Keep in mind that: 1. WebUI isn't enabled by default. EDIT: True only for GUI builds. 2. When enabled, WebUI access requires authentication by default 3. Until user explicitly sets their own password qbt generates a random password **each time** the client starts. The above limit the exploitability of a running client. Is it worth it to hide some dangerous APIs under an explicit cmdline/env var option? Maybe. If someone wants to implement it, IMO, we shouldn't reject it. If implemented, then I suggest: For the current series the default is to continue allowing the API but displaying a future deprecation notice both in the log and in the relevant field in the preferences UI. In the next series, the default will be to restrict these APIs and require the presence of this cmdline/env. >In this case, would it make sense to set the "run external program" value itself through an environment variable, completely prohibiting doing it through the WebAPI? Probably a valid approach too.

deekerman commented

2026-02-22 03:34:45 -05:00

Author

Owner

@glassez commented on GitHub (Jun 25, 2025):

WebUI isn't enabled by default

This is not true for headless installations which are more often used via WebUI.

@glassez commented on GitHub (Jun 25, 2025): > 1. WebUI isn't enabled by default This is not true for headless installations which are more often used via WebUI.

deekerman commented

2026-02-22 03:34:45 -05:00

Author

Owner

@HanabishiRecca commented on GitHub (Jun 26, 2025):

In this case, would it make sense to set the "run external program" value itself through an environment variable, completely prohibiting doing it through the WebAPI?

I always told that. Ability to run arbitrary code via remote access is a notoriously dangerous practice. Related: #20932
No matter how strong your passwords are. One random auth exploit is all it takes.

People should only be able to set that via local GUI, by editing config manually, or by other external means (CLI flags, env variables etc.).

@HanabishiRecca commented on GitHub (Jun 26, 2025): > In this case, would it make sense to set the "run external program" value itself through an environment variable, completely prohibiting doing it through the WebAPI? I always told that. Ability to run arbitrary code via remote access is a notoriously dangerous practice. Related: #20932 No matter how strong your passwords are. One random auth exploit is all it takes. People should only be able to set that via local GUI, by editing config manually, or by other external means (CLI flags, env variables etc.).

deekerman commented

2026-02-22 03:34:45 -05:00

Author

Owner

@Vagelis1608 commented on GitHub (Jun 26, 2025):

CLI flags or config edits would work, yes.
Basically, disable setting it from the WebUI but still have a way to set it on headless installations, where the GUI isnt available.

@Vagelis1608 commented on GitHub (Jun 26, 2025): CLI flags or config edits would work, yes. Basically, disable setting it from the WebUI but still have a way to set it on headless installations, where the GUI isnt available.

deekerman commented

2026-02-22 03:34:45 -05:00

Author

Owner

@majora2007 commented on GitHub (Jul 8, 2025):

Any consensus on this? I do believe using a config or system environment to enable this, and leaving disabled via webui, is the best path forward.

@majora2007 commented on GitHub (Jul 8, 2025): Any consensus on this? I do believe using a config or system environment to enable this, and leaving disabled via webui, is the best path forward.

deekerman commented

2026-02-22 03:34:45 -05:00

Author

Owner

@HanabishiRecca commented on GitHub (Jul 8, 2025):

Well, users always were able to edit the config manually.
The question is: should we simply remove it now, or some additional ways needed first?

@HanabishiRecca commented on GitHub (Jul 8, 2025): Well, users always were able to edit the config manually. The question is: should we simply remove it now, or some additional ways needed first?

deekerman commented

2026-02-22 03:34:45 -05:00

Author

Owner

@beigexperience commented on GitHub (Jul 9, 2025):

I think warnings in the gui and logs for a few versions should be fine. In some version later have it off by default, You can keep the web bits as they are just grayed out/disabled until an env var/config is set(I'm guessing the env var's name should be plainly spelled out near the disabled checkbox)

@beigexperience commented on GitHub (Jul 9, 2025): I think warnings in the gui and logs for a few versions should be fine. In some version later have it off by default, You can keep the web bits as they are just grayed out/disabled until an env var/config is set(I'm guessing the env var's name should be plainly spelled out near the disabled checkbox)

deekerman commented

2026-02-22 03:34:48 -05:00

Author

Owner

@majora2007 commented on GitHub (Sep 18, 2025):

Any update on the team's thoughts on this and a path forward?

@majora2007 commented on GitHub (Sep 18, 2025): Any update on the team's thoughts on this and a path forward?