Back to Index

I Stopped a Supply Chain Attack on a 10k User Website

winsrewu
winsrewu

June 25, 2026

Due to some security issues, I can't tell you much about the details, but here is the general story.

General Story

A few days ago, I logged into the mobile version of that website on my phone. When I was browsing the content, I suddenly got redirected to another gambling and pornographic website. It's really dangerous. Although I turned it off immediately, my personal information might have already been leaked. The website was trusted, proxied by Cloudflare, and I was using Edge on iOS, with HTTPS. At that moment, I was 90% sure that it was a supply chain attack. But the website did have some plugins, so I couldn't tell where the dangerous code came from. I contacted the maintainer of the website, and he said that after a scan, no clues were found, and that maybe it's a network environment issue. So I put it aside for a few days, until it happened again.

This time, I believed it was not a coincidence. I tried to reproduce it on my iOS device, but didn't succeed. I didn't quite remember what I did before the redirection. It seemed like something really rare. I also tried it on Edge on my laptop, with devtools enabled to make it act like my phone. It turned out to be a bad idea (actually they have something more than UA, haha).

Then a line of error on my laptop drew my attention: "A function was not found." It's hard to debug on iOS Edge, but I managed to get access to the logs, which didn't have that line of error. Maybe it was the root cause, but I needed a way to know where my Edge was importing it from. Source code didn't help — I guess they return different HTML based on the device, so I logged into a third-party iOS browser test website. But there was no Edge, only Safari and Chrome. I tried them both, and they did have that line of error. The clue ended here. (I guess Edge somehow ignored that error.)

Eventually I remembered that there was a packet capture app on my phone, so I tried it. Fortunately, the redirection happened in time.

There was no way for the poisoned code to hide. I found that there were a few suspicious requests to a CDN before the redirect. So I just threw all of these responses (they're very long and I'm lazy) to an LLM, and it immediately found a Base64-encoded redirection URL.

My agent told me that the CDN is dangerous — it was bought by someone who had been related to other attacks. But I didn't find any passages about it being shut down or being tried. *sigh

That's it — the maintainer fixed this issue really quickly.

How Does the Attack Work?

The redirection URL was Base64-encoded, and that URL points to a site which then sends you to another random bad website. There's logic that only mobile users are redirected, since most of the security work is done on PC.

The malicious response was only returned in a small fraction of requests; under normal conditions, it functioned as expected.

Can I Do Better?

Yes, I turned off my ad block extension on my PC to reproduce it, but I should have turned logging on and scanned it first. Plus, I should have used the packet capture app earlier.

What Should We Do to Prevent This?

Use an ad block extension. I have two. Haha

View on GitHub