New issue
Advanced search Search tips
Starred by 10 users

Issue metadata

Status: Accepted

  • Only users with EditIssue permission may comment.

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

utorrent: various JSON-RPC issues resulting in remote code execution, information disclosure, etc.

Project Member Reported by, Jan 31 Back to list

Issue description

[merging utorrent issues into one bug]

By default, utorrent create an HTTP RPC server on port 10000 (uTorrent classic) or 19575 (uTorrent web). There are numerous problems with these RPC servers that can be exploited by any website using XMLHTTPRequest(). To be clear, visiting *any* website is enough to compromise these applications.

uTorrent web (

As the name suggests, uTorrent Web uses a web interface and is controlled by a browser as opposed to the desktop application. By default, uTorrent web is configured to startup with Windows, so will always be running and accessible. For authentication, a random token is generated and stored in a configuration file which must be passed as a URL parameter with all requests. When you click the uTorrent tray icon, a browser window is opened with the authentication token populated, it looks like this:

While not a particularly strong secret (8 bytes of std::random_device), it at least would make remote attacks non-trivial. Unfortunately however, the authentication secret is stored inside the webroot (wtf!?!?!?!), so you can just fetch the secret and gain complete control of the service.

$ curl -si http://localhost:19575/users.conf
HTTP/1.1 200 OK
Date: Wed, 31 Jan 2018 19:46:44 GMT
Last-Modified: Wed, 31 Jan 2018 19:37:50 GMT
Etag: "5a721b0e.92"
Content-Type: text/plain
Content-Length: 92
Connection: close
Accept-Ranges: bytes

localapi29c802274dc61fb4        bc676961df0f684b13adae450a57a91cd3d92c03        94bc897965398c8a07ff    2       1

This requires some simple dns rebinding to attack remotely, but once you have the secret you can just change the directory torrents are saved to, and then download any file anywhere writable. For example:

# change the download directory to the Startup folder.

# download a torrent containing calc.exe

I wrote a working exploit for this attack, available here:

The authentication secret is not the only data accessible within the webroot - settings, crashdumps, logs and other data is also accessible. As this is a complete remote compromise of the default uTorrent web configuration, I didn't bother looking any further after finding this.

uTorrent Classic (

By default utorrent Classic creates a JSON RPC server on port 10000, it's not clear to me that this was intentionally exposed to the web, as many endpoints crash or interfere with the UI. Here are some example actions that websites can take:

Nevertheless, browsing through the available endpoints I noticed that the /proxy/ handler is enabled and exposed by default, and allows any website to enumerate and copy any files you've downloaded. To be clear, any website you visit can read and copy every torrent you've downloaded. This works with the default configuration.

This requires brute forcing the "sid" which is a small integer that is incremented once for each torrent, this can be brute forced in seconds.


$ curl -sI 'http://localhost:10000/proxy/0/?sid=2&file=0&callback=file'
HTTP/1.1 200 OK
Content-Type: audio/mpeg
Server: BitTorrentProxy/1.0
Connection: close
Accept-Ranges: bytes
ETag: "8FD54C339FE8B8A418CE2299AF2EADD9B1715D7A"

file is the index in a multi-file torrent (here there is just one file) and callback is a javascript callback. This means any website can find out what you've downloaded, and then just copy it from you - all the data.

I made a simple demo, screenshot of how it's supposed to look attached. It's really slow, but demonstrates that a website can enumerate and read any data you've downloaded via uTorrent.

Here is how I reproduced:

* On a fresh Windows 7 VM, install utorrent 3.5 (44294). Accept all default settings.
* File -> Add torrent from URL..., enter
* When the torrent is finished (it's only about 5MB), visit this URL in Chrome:
* Click "Start Attack"
* Wait a few minutes.

The page should have figured out the size and file type, and gives an option to steal the files. See screenshot attached.


The utorrent binary disables ASLR and /GS. This is a really bad idea. (Note that the binary is UPX packed, but this doesn't change any security properties).


I noticed that utorrent is using unmodified mersenne twister to generate authentication tokens and cookies, session identifiers, pairing keys, and so on. The PRNG is seeded with GetProcessId(), GetTickCount() etc. That is already not great quality seed data, but mersenne twister makes no guarantees that someone who can view sample output can't reconstruct the state of the PRNG.

This is actually one of the FAQs on the mersenne twister site:

This allows anyone to reconstruct things like pairing keys, webui session cookies, etc, etc. You can sample unlimited prng output, so this is a serious design flaw.


Finally, a minor issue - the documentation for the "guest" account feature says many actions are disabled for security, but I tested it and that it plain isn't true:

$ curl -si 'http://guest@localhost:10000/gui/?action=getsettings&callback=error&btapp='
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 16572
Content-Type: text/javascript
Set-Cookie: GUID=6yY1pkIHHMvvHo8tgOYu; path=/
Cache-Control: no-cache

{"build":44090,"settings": [

Perhaps this got broken at some point, but this feature is web-accessible, so this should probably be fixed (or suitable warnings added). I can't imagine many users enabled this, but those that did probably expected the security boundaries described in the documentation to be enforced.

This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available, the bug report will become
visible to the public.

Windows 7-2017-12-04-16-36-51.png
119 KB View Download
Windows 7-2018-01-31-12-19-19.png
77.2 KB View Download
Project Member

Comment 1 by, Jan 31

Labels: -Reported-27-Nov-2017 Reported-2017-Nov-27
Project Member

Comment 2 by, Jan 31

Issue 1460 has been merged into this issue.
Project Member

Comment 3 by, Jan 31

Issue 1440 has been merged into this issue.
Project Member

Comment 4 by, Jan 31

Labels: CCProjectZeroMembers
Because we're coming up to the 65 day mark, I sent a friendly reminder to

I'm a little worried they haven't asked for any feedback on fixes and we're just a month away from 90 days, when exploitation is so trivial.

Project Member

Comment 5 by, Jan 31

I heard back, "The team is confident that a build will distributed to the public before the 90 day window closes. A build with the fixes will be made available to you for testing before a public release."

So, fingers crossed.
Project Member

Comment 6 by, Feb 13

uTorrent sent me a beta build of uTorrent Classic, it no longer opens port 10000 by default, just what looks like an ephemeral port.

The ephemeral port appears to check the Host header, so DNS rebinding is no longer possible. You can still POST and GET various commands and initiate the pairing.

It also looks like the sid is no longer easy to guess, I guess this fixes the proxy issue.

They say this will be rolled out later this week.
Project Member

Comment 7 by, Feb 13

I think there is still a lot of unnecessary remote attack surface, but I don't have any way to break the new build right now. I might return and look later.

It seems like the utorrent homepage is A/B testing redirecting to for some people, so maybe the plan is to deprecate Classic for Web in future.
Project Member

Comment 8 by, Feb 15

(Note: ASLR is still not enabled in the new version).
Project Member

Comment 9 by, Feb 20

Labels: -Restrict-View-Commit
Status: Fixed
Looks like this is public now:
Project Member

Comment 10 by, Feb 20

Status: Accepted
It turns out that BitTorrent just made added an additional token to uTorrent Web, and was still vulnerable to the same attack.

Previously, a request would look like this:

But now, they added a second token, so it looks like this: just have to fetch that token as well, which comes from:

Therefore, this issue is still exploitable. The vulnerability is now public because a patch is available, and BitTorrent have already exhausted their 90 days anyway. I see no other option for affected users but to stop using uTorrent Web and contact BitTorrent and request a comprehensive patch, we've done all we can to give BitTorrent adequate time, information and feedback and the issue remains unsolved.
Is this present in the pre 3.x versions of uTorrent?  The torrenting community largely eschews 3.0+ because the only apparent work post-
 2.2.1 has been to add advertisements, bloating 2.2.1's 391KB of torrenting perfection into a 1MB+ monstrosity.  The last meaningful exploit that wasn't introduced by these 3.x additions was fixed in version 1.6.1, which was released in 2007.  1.6.1, 1.8.5, 2.0.4, and 2.2.1 are all recommended clients for this nearly unparalleled level of security to go with their stability and performance.  

I've run your tests against 2.2.1 and only come up with the pairing and PIN requests bringing up popups that the requests were received.  The crash and info leakage don't work as they do for 3.5.

Shouldn't this issue have the Deadline-Exceeded label?
Some websites tried to persuade people that setting Preferences → Advanced → net.discoverable = false resolves the problem. But it isn't true. This setting just disables port 10000. But you can execute the same actions using port which uTorrent uses for all incoming connections. For example, I use port 45705 for incoming connections, and a simple GET request to crashes the program.
Project Member

Comment 14 by, Feb 22

Yes, you can scan for the port and still discover it with JavaScript. Just disabling port 10000 does not resolve it.
>a simple GET request to<port>/fileserve/?callback=error crashes the program.

This does nothing to 2.2.1.
Project Member

Comment 16 by, Feb 22

As far as I know, old versions are not security supported - I wouldn't recommend using them. I haven't looked, and as the vendor wouldn't patch it anyway, it doesn't seem useful to audit old versions.

Could you reconsider a look?  uTorrent is a bit of a special case considering it was sold off and its current "support" consists mostly of adding new and unique vulnerabilities, contrasted to the old versions which were feature complete and haven't seen an exploit discovered in 11 years.  This is why the old versions are still widely used.  The current software landscape shows nothing that even come close to a complete replacement: alternative clients are either full of bugs or missing many features.  Many have been in development for over 10 years and still haven't managed to equal even 1.6.1 in stability, feature set, ease of use, and security.

Bittorrent Inc. adding vulnerabilities in 3.x is nothing new and up to now it hasn't had a lick of impact on users of pre 3.x versions.  This one you've found is different as it seems 2.x has this RPC server.  If 2.x is found to be vulnerable to an offshoot of this attack but previous versions not, then 1.8.5 would now wear the crown of the best torrent client.
I'll second that request for an audit of 2.2.1 for this vulnerability. v3+ is considered bloatware by many torrent users, & numerous private trackers still whitelist 2.2.1. if 2.2.1 is vulnerable to this method, that is worth knowing, & if it is not, that is worth knowing too.

v3+ has always been a ball of security holes, that's one of the reasons so many people stuck with 2.2.1 version.

Just because an app version is deprecated, doesn't mean its security issues (or lack thereof) aren't important.
It does not make sense to check for long time unsupported versions because they have other "holes", and with SSL they do not work normally.

Comment 20 Deleted

It may be a long unsuported version, but at least in the tracker world, it is the most popular/used uTorrent version.  
I'm not sure if across all private trackers that 2.x quite beats 3.x, but its popularity is up there and for some trackers it's definitely the case:

442 KB View Download
Stats from one tracker, 2.2.1 is the 2nd most used client at 15% (rtorrent at 25%).  The next most used uTorrent client is uTorrentMac 1.8.7 at whopping 2.2%, and followed by uTorrent 3.5.1 at 2.1%.  
K as a utorrent 2.2.1 user for many years I am interested in this, so as all the info and the exploits are here so we can reproduce I have gone ahead and done so. I am in no way a professional, but all the notes are there to reproduce. 
First, the utorrent web is not installed on 2.2.1 by default so nothing with utorrent web works on 2.2.1 by default, verified port is ignored and commands so no one can download stuff on your pc.   
Second, Utorrent classic port 10000 is on by default on 2.2.1, can be disabled but does not fix problem just shifts it to default connection port. The Crash test page does not crash utorrent 2.2.1, and Trigger device transfer is ignored as feature not implemented on 2.2.1. All other options open a pop-up on utorrent if you want to allow or ignore (seems like the people that made utorrent knew about this probability and made that as a safety net) you also have an option for always deny as a check box, so no entry. The last exploit that makes it possible for people to get list of your download and download them from you states "invalid request", and after a minute it gives "This page is waiting for a dns update, and will then contact utorrent. This could take a while, get a coffee." left it running for 40+ minutes (got me couple of coffees) and still same thing posted image with errors that states the utorrent 2.2.1 is responding with a 400 Bad Request error leaving me to believe that 2.2.1 immune to this attack. I and manny other would like you guys at google to verify our findings.
226 KB View Download

Comment 25 Deleted

Something I did not mention is that utorrent 3.* is a fork not the same as 2.*, as they are developed by different group.

Comment 27 Deleted

Have you checked the latest release v3.5.3 (build 44358)? At first glance, it seems that it is safe. At least it doesn't crash on GET<port>/fileserve/?callback=error :)
Please read before posting as stated
"It turns out that BitTorrent just made added an additional token to uTorrent Web, and was still vulnerable to the same attack.

Previously, a request would look like this:

But now, they added a second token, so it looks like this: just have to fetch that token as well, which comes from:

Therefore, this issue is still exploitable. The vulnerability is now public because a patch is available, and BitTorrent have already exhausted their 90 days anyway. I see no other option for affected users but to stop using uTorrent Web and contact BitTorrent and request a comprehensive patch, we've done all we can to give BitTorrent adequate time, information and feedback and the issue remains unsolved."

So no problem not solved they added a second key that can still be hacked easily , and they also changed the port from 10000 to something else. So they added another step.
I have run the PoC tests against v2.0.4 and v3.3.1, and the result is the same as described in Comment 11 and 24. Only the popups showed.
Tested on utorrent 3.4.5 (41372). Default settings or not, none of these tricks work. Seems to be behaving exactly like 2.2.1
Can anyone confirm the latest uTorrent build released 3.5.3 (44358) is not vulnerable to this? Also, has anyone tested these vulns on the latest Bittorrent client (the other bittorent client created by uTorrent's creator)?
is it true that utorrent on osx/*nix is uneffected, and this issue only effects utorrent running on windows? TIA
I think it's important to test utorrent 2.2.1 by how widely it's used.

Trackers and users alike are refusing to adapt and drop this client. It's very concerning. 

I think testing it would reveal a lot and help trackers and users move on to software that's actually maintained.

Comment 35 Deleted

im importabt
What ever there is  .................
2.2.1 .. thus still a solid piece ..

I see lots of people keep trying to downvote this version ...
i wonder why ? .. .lol ... no bugs , no adds , no nada ... ow wait ... now i get it .. :)

Project Member

Comment 38 by, Mar 1

Labels: Restrict-AddIssueComment-EditIssue
This is not a discussion forum, or a place to share your conspiracy theories.

Disabling comments to reduce noise.

Sign in to add a comment