wp2shell, a Fake Chrome and a Botnet in My Logs

🌐 Also available in: Deutsch · Français · Español

A few days ago, “wp2shell” made the rounds — an unauthenticated RCE chain in WordPress, cobbled together from a SQL injection (CVE-2026-60137) and a validation bypass in the REST batch endpoint (CVE-2026-63030). 🩸 Every WordPress ≥6.8 was exposed, upstream finally fixed it in 7.0.2. For a nail-biting couple of days, this very blog was running an emergency nginx block on /wp-json/batch/v1 because the patched Docker image simply refused to exist yet. Classic. 🙃 So naturally, once the fire was out, I did what any self-respecting homelab nerd does at 2am: I went spelunking through my own ingress logs. 🕵️‍♂️ Turns out the internet does not care that you patched. The internet keeps knocking anyway.

Table of Contents

🔍 Receipts From the Access Log

First pass through the logs, I thought I had a tidy little handful of hits. Then I went back with a better grep (turns out nginx’s plain access-log lines don’t repeat the hostname, so my first domain filter was quietly eating real hits — even homelab nerds have off days 🤦) and found out it was way more than a handful.

🌊 The opening flood, 18–19 July — the day the CVE dropped, my logs lit up with dozens of hits, almost all from the same wonderfully unsubtle User-Agent, wp2shell.com scanner, cycling through a small army of Cloudflare-fronted IPs, mostly landing 207 (processed, pre-mitigation). Basically the internet’s security researchers (or “researchers” 🧐) doing a synchronized victory lap the moment the disclosure went public.
😂 Repeat performance from the same scanner UA on 20 July: 403, blocked by my emergency rule. 💪 Then again on 21 July, rule happened to be off for a moment: 207, sailed right through. 🎯 (Core CVE was already patched by then, so — anticlimactic for both of us.)
🕵️ My personal favorite: an EC2 box in AWS Tokyo (ec2-*.ap-northeast-1.compute.amazonaws.com, yes I did the reverse-DNS lookup, yes I felt very smart) wearing a fake Chrome User-Agent like a cheap Halloween costume. 🎭 It requested /, waited exactly one (1) second, then went straight for the exploit endpoint. No CSS. No JS. No favicon. No human being browses like that — real Chrome loads a small novel’s worth of assets per pageview. Nice try, robot. 🤖
🆕 Update while I was still writing this post: a fresh one landed from Google Cloud (*.bc.googleusercontent.com), two requests, one second apart, both 207 — and this one bothered to tag itself with its own tracking parameter, &_w2s=347b2f52 / &_w2s=b58fad1b. Somebody’s scan tool is apparently numbering its own attempts now. Efficiency! 📊 Third different major cloud provider spotted so far (Cloudflare-fronted, AWS, now GCP) — this thing has friends everywhere.

🤔 Okay, But Who’s Actually Doing This?

Fair question, and worth spelling out for anyone who doesn’t stare at server logs for fun: not everyone poking at a known vulnerability is a criminal. There’s a real spectrum here, and the tells matter. 🔬

😇 Good-faith end: security research outfits and scanning services (think Shodan, Censys, GreyNoise-style projects) constantly sweep the internet for known CVEs — sometimes to build public threat-intel feeds, sometimes so affected site owners can look themselves up and go “oh no.” A tool that literally calls itself wp2shell.com scanner in its own User-Agent fits this profile well: it has no reason to hide, and being loud about who you are is exactly what legitimate scanners do (and often what responsible-disclosure norms expect).
😈 Bad-faith end: attackers running the exact same kind of check, except the goal isn’t “tell someone,” it’s “find a door I can still walk through” — to drop a webshell, a spam injector, a cryptominer, or just add the box to a botnet. These are the ones with every incentive to blend in.

That’s exactly why I keep pointing at the fake Chrome User-Agent cases (the AWS Tokyo one, the GCP one) as the more interesting ones: an honest scanner doesn’t need to disguise itself as a regular visitor’s browser. Something pretending to be a person, specifically to avoid looking like a scanner, has a reason to hide — and “I have good intentions” isn’t usually it. 🎭 So, honest layperson’s summary: this is almost certainly a mix of both, and I can’t prove intent from an access log alone — a 207 response tells me the endpoint answered, not what someone was trying to do with it. But the self-announcing scanner is probably closer to “internet background radiation / security tooling,” while the disguised ones are the closer I’d get to “someone actually hoping to get in.” Since the underlying WordPress bug is patched either way, neither camp got anywhere here — but the pattern itself is worth knowing. 🛡️ Full disclosure, for the nerds keeping score at home: my own curl tests — the ones I ran to confirm the block actually worked — are sitting in that same log file, repeatedly, because apparently I couldn’t just check once. 😅 So technically I’m also “an IP address probing the vulnerable endpoint.” Guilty as charged, Your Honor. 👨‍⚖️ Not just me being paranoid, by the way: Golem.de covered this exact wave of ongoing exploitation attempts too — “Lücken in WordPress: Laufende Schadcode-Attacken gefährden Millionen von Websites” — so this isn’t some isolated homelab-blog conspiracy theory. 📰 It’s a genuinely internet-wide thing.

🕸️ Bonus Round: The Scrapers Wearing a Trenchcoat

While I was down in the log mines looking for wp2shell, I tripped over something way bigger and, honestly, more interesting: 765 different IP addresses, spread across at least 530 distinct /16 network blocks (so: everywhere, not one datacenter), each one showing up to make exactly one or two requests and then vanishing forever. 👻 Every single one of them presented a perfectly normal-looking desktop browser UA — Chrome or Edge, Windows or Mac, the works. Nothing you’d flag on sight. But line them all up and the mask slips immediately: they only ever hit my ~31 tag/category/date archive pages (/tag/ansible, /category/devsecops, /2025/05, and so on), methodically working through the list — and not one of them ever fetched a single CSS file, JS file, or image afterwards. 🖼️🚫 A real Chrome tab loads two dozen assets per pageview without you lifting a finger. These didn’t load any. That’s the signature of a residential-proxy scraping botnet: instead of hammering the site from one IP (which gets you rate-limited or banned in about four seconds), you rent a few hundred thousand real residential IPs and fire exactly one polite, totally-a-real-person-honest request from each. Death by a thousand paper cuts, except the paper cuts are indistinguishable from actual readers unless you zoom out far enough to see the pattern. 🔎 Given the target (systematically walking every archive page, i.e. the entire content index of the site, not just the homepage), my money’s on large-scale content scraping — could be good old SEO content theft, could be someone building an AI training set. Either way: 765 “visitors” who read zero words and loaded zero fonts were never visitors. 🤖🕶️

🎬 Takeaway

The actual hole has been patched for a while now (running 7.0.2 since day one of this being possible). But scanning for a freshly-announced CVE doesn’t stop just because someone, somewhere, shipped a fix. 📡 The scanning bots do not read changelogs. If you run public-facing WordPress, this kind of traffic is just background radiation — a good excuse to actually glance at your access logs once in a while instead of assuming “patched == done.” 🛡️