I reported a vulnerability. It wasn't fixed. Now there's the Kimwolf botnet.

In late April and early May 2025, I reported a serious vulnerability to about a dozen residential proxy providers. For the uninitiated, a residential proxy is a proxy service that routes your internet traffic through an IP that belongs to a “residential” ISP such as Comcast, typically for the purpose of bypassing restrictions that websites place on “datacenter” IP addresses. For example, many sites won’t let you sign up or pay for services from datacenter IPs. Residential proxies are used for web scraping, bulk social media account creation, sneaker “copping”, ticket scalping, and occasionally even for more legitimate purposes like verifying that advertisements you’ve paid for actually show up when you browse the page as a normal human.

Where do these IPs come from? Ordinary people. Residential proxy services get their “points of presence” (PoPs) from lots of places, like free VPN apps that double as proxies. The biggest proxy providers develop “monetization SDKs” you can include into your own mobile, desktop, or even smart TV app to turn it into a PoP and earn money. I can see why it’s appealing as an app developer, since being a PoP doesn’t degrade the user experience nearly as much as advertising does. Many smaller providers are extremely sketchy when it comes to how they source their PoPs.

The key thing to remember about residential proxies: providers are proxying potentially adversarial traffic through normal people’s home internet connections.

Enough talk, PoC or GTFO

PoC it is. Rent some residential proxies from a vulnerable provider, set up a domain that resolves to 192.168.0.1, then:

curl --proxy http://user:pass@my-favorite-residential-proxy-provider.com some-domain-that-resolves-to-192.168.0.1.example.com

This will send an HTTP request to 192.168.0.1 (often a router admin login page) on some random person’s home network, simply because they have a free VPN app or similar installed on their phone.

By setting up DNS so that a domain name resolves to a local network IP, such as 10.0.0.1, or 192.168.0.1, it is possible for any customer of a vulnerable proxy provider to access home internet routers, IoT devices, and any other exposed network devices on random people’s home internet connections. These devices often have security vulnerabilities or well-known admin passwords.

I made a fun little tool that you can use to create a DNS server that can resolve to arbitrary IP addresses based on the subdomain. Eg, you can have 192.168.0.1.yourdomain.com resolve to 192.168.0.1. This makes it easy to check common IPs like 192.168.0.1, 10.0.0.1, etc. (I used to run such a resolver under my own domain, but I don’t want to somehow mess up its reputation, so you’ll have to set up your own).

Reporting the vulnerability

I reported the issue to providers as fast as I could test them. At the time, I didn’t understand the structure of the residential proxy market well. I knew there were resellers, but I didn’t take the time to figure out who the true upstream providers were.

• Simplynode: The first provider I found the vulnerability in. Not for any reason in particular; I basically chose them randomly from a list on some aggregator website.

  Their support team/person was competent and told me they had forwarded the issue to their “upstream” provider (so yes, they’re a reseller). A few days later, they told me that the upstream provider had provided them with a bug bounty of $1,000, and they paid it forward to me. This was the only cash bounty I received. I still do not know who simplynode is reselling from. I’ve requested a few IPs from them and looked them up using Spur, and there’s no single provider that reliably seems to be behind their IPs.

• DataImpulse: They resolved the issue in less than a week. DataImpulse is the only provider that ever communicated to me that they had fully patched the issue. And they truly did. Which actually really confuses me, because this issue shouldn’t be easy to patch. I’ll talk more about that later.

  While DataImpulse handled the fixing of the bug better than any other provider, they didn’t exactly compensate me well: Their reward was 100 GB of free credit on their platform (worth $50).

• Oxylabs is one of the mythical non-reseller (“upstream”) providers. They make their own SDK which is embedded into tons of third-party apps that then turn into Oxylabs PoPs. Tons of other providers resell from oxylabs. According to data from Spur, they’re just about tied for first place as the largest proxy provider, alongside Bright Data (we’ll talk about them soon). Oxylabs is the only provider I reported to that had an established vulnerability disclosure program, which says a lot about the approach these firms take to security, and even more about my maturity or lack thereof in reporting it to them. (Bright Data also has a bounty program, but I didn’t report anything to them, as I’ll discuss later).

  The email I got back from Oxylabs was very surprising:

  This vulnerability has been previously reported to us and our teams are currently working on it. Unfortunately, this means that your report is not eligible for our Vulnerability Disclosure program. Nevertheless, we appreciate your effort and commitment in keeping the internet safe.

  And this is why I should’ve taken an hour to understand the structure of the residential proxy market before reporting vulnerabilities to them. Did Simplynode get the bounty from Oxylabs and then give it to me? I hope so. But was it the full amount? Or is Simplynode actually a Bright Data reseller (I’ll discuss them soon), and instead some other provider I reported to took the Oxylabs bounty and ran? I’ll never know.

• ProxyRack is primarily a reseller, but is also trying to get their own upstream business off the ground. Their support was competent. I’m not sure if they fixed the issue, but they acknowledged it and gave me a hilarious bounty:

  Hi Mark, Thank you for bringing the issue regarding access via domains resolving to 192.168.0.1 to our attention. This is an important security concern, and we appreciate your diligence in reporting it. We’re currently implementing a fix to block access through such domains to prevent potential vulnerabilities. Your input has directly helped us improve our platform’s safety for all users. As a token of appreciation, /we’ve extended your trial one more week./

  (emphasis mine)

I reported the issue to 6 other providers in addition to those listed here. 2 of these providers allowed unrestricted access to the local network without even needing the DNS trick. That’s right, you could just curl 192.168.0.1 straight through the proxy. However, the support teams for those two providers never responded to me, and didn’t have vulnerability disclosure programs, so I won’t list them here.

Additionally, I tested 2 providers that did not appear to be vulnerable. I won’t list them here because they did not have a proper vulnerability disclosure program and I don’t want to get into trouble, and also, I’m not sure beyond a shadow of a doubt that they’re safe against all forms of this attack (one had very strange variable response times when trying to perform the attack).

And then there’s one more…Bright Data.

Bright Data

Bright Data is approximately tied with Oxylabs for being the largest residential proxy provider (according to Spur, at least). And it’s only recently that Oxylabs caught up. Bright Data also has the strictest KYC (know-your-customer) policies of any provider I tried. To get a KYC’d account, you have to submit identification for yourself, and your company, and provide Bright Data with a convincing explanation of why you need residential proxies.

In Bright Data’s non-KYC plan:

• A number of sites are blacklisted, such as 4chan.org, and any domain that resolves to a private IP address!

• Only HTTPS traffic is allowed

• All HTTPS traffic is intercepted and decrypted on Bright Data’s servers (ie, the “backconnect” servers). You must add Bright Data’s certificate authority to your HTTP client (or just disable certificate validation entirely).

• The ultimate destination server’s HTTPS certificate is verified by the backconnect server.

• The backconnect server checks robots.txt and blocks the connection if disallowed. This blocks Reddit, for example, which interestingly has the following robots.txt:

  # Welcome to Reddit's robots.txt
  # Reddit believes in an open internet, but not the misuse of public content.
  # See https://support.reddithelp.com/hc/en-us/articles/26410290525844-Public-Content-Policy Reddit's Public Content Policy for access and use restrictions to Reddit content.
  # See https://www.reddit.com/r/reddit4researchers/ for details on how Reddit continues to support research and non-commercial use.
  # policy: https://support.reddithelp.com/hc/en-us/articles/26410290525844-Public-Content-Policy
  
  User-agent: *
  Disallow: /

  Real subtle way to say “If you’re training an LLM, fuck off or pay us!”

When I first tried to exploit this vulnerability on Bright Data, I received 502 errors with the error message “Could not resolve host my-subdomain.example.com”, indicating that Bright Data was blocking my request.

There are two layers of defense: 1. By enforcing HTTPS and a valid HTTPS certificate, routers and IoT devices are ruled out: Even on the rare occasion that an IoT device uses HTTPS, the certificate it presents is probably not signed with a public CA, and certainly won’t match the random domain name you registered to resolve to a local IP. 2. Domain names that resolve to local IPs are explicitly blocked.

But: 1. In the KYC plan, HTTPS is not enforced or intercepted by the backconnect server. 2. There was a TOCTOU (time-of-check/time-of-use) vulnerability in how Bright Data checks whether the domain resolves to a local IP.

This suggests that Bright Data may have also been exploitable with a KYC-approved account, though I can’t be sure as I never attempted to pass KYC (I’ll say why soon).

To figure out (2), I set up my own DNS server and logged all requests. On every other proxy provider, I logged usually just one DNS request per HTTP request that I made, and the DNS requests usually came from IPs belonging to residential ISPs like Comcast. This indicates that DNS is resolved once, and is resolved at the PoPs.

Bright Data was different. Invariably, my DNS server first received a hit from a Vultr IP address, followed by a delay and then another hit from a residential ISP. (Vultr is a popular cloud provider). You can see where this is going.

I wrote a DNS server that let me serve a different response depending on who’s asking (in this case, I just did a reverse DNS lookup on the requesting IP and searched for a vultr substring). If I served a public IP to the Vultr request, and then eg 192.168.0.1 to all other addresses, I was able to get past Bright Data’s first line of defense and started getting HTTPS errors instead of DNS related errors in my responses.

To fully exploit the vulnerability, I’d need a KYC-approved account. But before going down that rabbit hole, I realized I could just download the official Bright Data SDK and look at what protections they have against the attack. I found my answer before even clicking the download button, by reading the changelog on the download page: 1-2 weeks after I reported this vulnerability to other providers, Bright Data released a patch to some of their SDKs with a changelog message along the lines of “prevent access to private IPs”.

Since then, Bright Data edited the changelogs to just say “Bug fixes” (they likely realized it was irresponsible to publicly disclose, and I agree), and I didn’t take a screenshot at the time. You’ll have to take my word for it.

What most likely happened is one of the other providers I reported to was a Bright Data reseller, whose infrastructure bypasses both Bright Data’s HTTPS verification and Bright Data’s DNS checking at the backconnect server. I’ll never know for certain, though.

So all 10 vulnerable providers promptly patched the issue, right?

Wrong. But in their defense, it’s not as easy as it sounds.

First, a little more info about the internal architecture of a typical residential proxy provider. Because most PoPs are behind NAT, you can’t have your clients connect directly to the PoPs; instead, you have centralized “backconnect” servers that relay the traffic between clients and PoP (and presumably PoPs initiate TCP connections to these backconnect servers to get through NAT):

How can you fix this issue? I can think of three options, only two of which work: 1. The naïve way: On your backconnect servers, resolve the domain, and verify that the resolved IP is public.

Don’t choose this option! On most providers, the protocol between the backconnect servers and the PoPs passes hostnames to the PoPs, which do DNS resolving from the residential network. This causes the TOCTOU issue described in the Bright Data section above, where a smart DNS server can return a public IP to the backconnect, but a private IP to the PoP. 2. Move DNS resolving entirely to the backconnect servers. Instead of passing a hostname all the way to the PoPs, the backconnect resolves the hostname, verifies that it’s not private, then passes said IP to the PoP.

This fully resolves the problem. I do not know for typical residential proxy providers whether this fix is possible without updating the software on the PoPs. I suspect it is, because residential proxies generally support accessing IP addresses without a hostname already, which suggests that the PoPs are perfectly capable of connecting straight to an IP.

This solution may be slightly less desirable to the proxy providers because clients may want the DNS resolving to happen at the PoPs. If you resolve DNS at the backconnect servers, a site can block residential proxies by blocking DNS requests from datacenters (though you can already detect proxies by comparing the TCP round-trip latency to the TLS (or HTTP) round-trip latency). 3. Verify at the PoPs that the resolved IPs are public.

This solution is super simple, but requires updating every PoP. If you have an SDK that you give to app developers, every app developer that uses your SDK needs to update your SDK, and then all the users of that app need to update the app. So it takes a very long time for this fix to become effective.

IMO, option 2 is clearly the best tradeoff. It’s a little less elegant than option 3, but can be implemented instantly vs option 3 which could take months.

It’s easy to check if a provider implemented option 1 by monitoring DNS traffic. If a provider uses option 1, you’ll see multiple DNS requests when you access a domain using your DNS server through the proxy. I don’t believe any of the providers I tested “fixed” the issue using option 1, thankfully.

However, most providers seem to have not been aware of option 2 (or it was infeasible) and instead chose option 3, which left their networks vulnerable for months while their PoPs got updated. A full year after I reported the issue, and 6 months after its was first exploited in the wild, this vulnerability still exists on some of the providers I tested. At the time the issue was publicly disclosed in January (by Synthient, see below), most of my tested providers were vulnerable. And only DataImpulse has ever confirmed to me in writing that the issue is fully resolved.

(How was DataImpulse able to fix the issue in a week? Either they used option 2, or they implemented option 3 but have complete control over their PoPs and were able to quickly update them without waiting for users to download a new version of an app etc).

Fast Forward: January 2026

I opened up the blog of everyone’s favorite large-foreheaded security researcher and to my dismay, read about the 2-million device botnet called Kimwolf created using this vulnerability. (based on research by Synthient).

The Kimwolf botnet was created by scanning through millions of residential proxy PoPs scanning for any devices with an exposed Android Debug Bridge. It’s just the kind of all-powerful, unauthenticated protocol that low-end IoT devices love to leave exposed.

The botnet is now being actively used to launch DDoS attacks, and, ironically, to run another residential proxy network operated by the attackers at a much lower price than legitimate providers. I guess the proxy providers are a victim of the attack, in a way!

In one sense, it’s too late to stop the attack. Patching the vulnerability in the proxy providers now won’t un-infect the infected devices. But it will stop any other actors from hacking the same devices to create another botnet. And the bigger risk is someone using the vulnerability to hack devices with some other vulnerable unauthenticated protocol, instead of ADB. (There’s a lot of possibilities by logging into routers with default passwords, then changing the network-wide DNS servers…)

Is this my fault?

I’ve been in contact with someone at Synthient who says they believe this vulnerability was first exploited in November 2025, about 6 months after I discovered it.

The bug is pretty simple. Residential proxies have been getting a lot more attention recently in general. So I think it’s most likely the hacker discovered the vulnerability independently.

On the other hand, I told quite a lot of people about the issue in enough detail to reproduce it: + 12 proxy providers, not exactly a crowd known for upstanding behavior. + Many of my friends and coworkers. + A few people at a couple technical conferences.

I can’t come to see myself as the villain here, though. It’s ultimately the responsibility of the proxy providers. 6 months from bug reported to bug exploited is more than enough time for these providers to fix their shit.

And still, the fact that at least Bright Data patched new versions of their SDK shortly after I reported this vulnerability, means that my reporting at least slightly mitigated the size of the Kimwolf botnet.

Timeline Summary

• April-May 2025: Discovered the issue, reported to 12 providers.
• May 2025: DataImpulse fixed the issue, some of the other providers acknowledged the issue, and I received the bug bounty from SimplyNode.
• November 2025: Active exploitation by Kimwolf begins.
• January 2026: Synthient discovers the mechanism Kimwolf is using and publicly discloses it. Many proxy providers are still vulnerable at this time.

Prove it!

I’m not sure why I feel the need to include this, but here’s a DKIM-signed email from the DataImpulse team in response to me disclosing this issue, to prove that I did in fact report it in May 2025 and am not just spinning this yarn for clout.

LLMs

Every word in this article was written by a human. An LLM was used to provide feedback on a draft, which was useful.