The Creative Overlay Menu in Elementor — A Full-Screen Menu That Shows Off
Reboot Addons' Creative Overlay Menu: a full-screen Elementor menu with kicker, headline, CTA and eleven animated surface options. No custom ...
Reboot Addons' Creative Overlay Menu: a full-screen Elementor menu with kicker, headline, CTA and eleven animated surface options. No custom ...
R749, R999, R1499 or R1999 a month — what each Reboot Websites package actually builds, and why the gap between ...
Advanced Text FX gives you 58 text-in effects in one Elementor widget — scramble, typewriter, glitch, neon, and a whole ...
Seven content widgets plus all six form stylers that build card effects, carousels, and styled forms without writing JS. Widget ...
Okay, so I was checking email on Monday morning and a buddy of mine sends me this message: “Your site is running mining scripts.”
I literally laughed. Like — my site?
Turns out he wasn’t joking.
Someone had gotten into the server my WordPress sites run on and dropped crypto-miners everywhere. Not through a plugin. Not because I used some dodgy free theme I pulled off Reddit. Through a hole in WordPress core that literally anyone with an internet connection could abuse.
Called it wp2shell. Which is pretty funny when you think about it — WP directly to Shell.
Alright so here’s the thing. WordPress has this endpoint called `/wp-json/batch/v1` — it’s been sitting there since like 2020 (shipped in version 5.6). Normally it’s fine. But starting with WordPress 6.9, something shifted and you could actually exploit it.
The chain goes like this:
Step one: There’s a route confusion bug — CVE-2026-63030. What that means is the batch endpoint doesn’t properly validate requests, so an unauthenticated hit gets smuggled through to places it absolutely should not reach.
Think of it like someone walking into your office building without showing ID, and the security guard just… waves them through. Because why not?
Step two: That smuggled request lands on `author__not_in` in WP_Query — which has a SQL injection vulnerability (CVE-2026-60137). From there, the attacker can basically do whatever they want with your database.
Step three — and this is where it gets ugly: They use UNION queries to forge posts. Then they write through the oEmbed cache. Then they create a rogue admin user. Then they drop a webshell plugin. By the time you notice, they’ve got full command execution on your server.
No login required. No password guessing. Just hit their script and watch it roll.
If your site is running anything older than WordPress 7.0.2 or WP 6.9.5 — stop reading this page for one second and update now. Seriously. This isn’t theoretical anymore.
This matters — because some of you reading this might be safe and some of you are sitting on a live grenade right now.
Affected ranges:
If you’re anywhere in those ranges, your site is sitting wide open. Not potentially vulnerable — actively exploitable.
(And yeah, even a completely stock install with zero plugins. They found that out the hard way and it sounds pretty scary.)
I’ve built probably over 100 WordPress sites at this point. Some are for small local businesses, some are full e-commerce builds like [this furniture store I threw together](https://rebootwebsites.co.za/how-to-build-a-furniture-style-ecommerce-website-in-wordpress-elementor-tutorial/). Almost all of them use Elementor because honestly it just works for 90% of clients.
But here’s what wp2shell means: it doesn’t matter how good your design is, how many animations you’ve coded, or whether you spent three months building the perfect [container entrance effect](https://rebootwebsites.co.za/entrance-animations-for-any-widget-or-container-elementor-tutorial/). If core hasn’t been patched, none of that matters because they can just nuke the whole thing from orbit.
And WordPress actually had to force auto-updates for affected sites. They don’t do that. Like ever. The risk was genuinely this bad.
This is the part you probably came here for, so let’s just get into it.
1. Update core. Now.
Dashboard → Updates. That’s it. Or if you’ve got WP-CLI: `wp core update –version=7.0.2`
2. Check your users list.
If they got in before the patch, they probably created an admin account and left it there. Go to Users → All Users and compare against accounts you actually know about. Any garbage? Delete it.
3. Scan for unknown plugins.
The exploit chain drops webshell plugins through oEmbed cache writes. So literally any plugin you don’t remember installing is a red flag — not just a red flag, a “call me back in 20 minutes because I found something” kind of moment.
4. Pull your access logs.
Search for hits to the batch endpoint before July 17. If you see activity there, someone already knocked on your door — you just didn’t notice yet.
5. Reset admin passwords.
Even if you’re certain they couldn’t have gotten credentials, just do it. Takes two minutes and buys you sleep at tonight.
If you’ve been with me on WordPress hosting or I manage your site? You’re good. I patched everything the second this dropped — probably at 3am because that’s what this job does to you.
If you’re just reading this and wondering about “your” site (the one you built two years ago on cheap shared hosting and kind of forgot about) — go check right now. Seriously. I’m not even going to wait here.
You know what? I’ve been there. Client’s site is mid-launch and you’re terrified that updating might break something because you never bothered to test against the new version (we’ve all done it).
In that case — and this is purely emergency mode — block `/wp-json/batch/v1` at your WAF or web server level.
A single Nginx deny rule kills 90% of the attack surface. WordPress doesn’t need the batch endpoint for normal operation, so blocking it shouldn’t break anything. Most sites didn’t even know it was there until this happened.
But again — stop using band-aids and just patch the core already. It literally takes three seconds from the dashboard.
Do I need to update plugins or themes too?
Nope — wp2shell is WordPress core. Zero plugins involved, neither causing it nor required for the exploit. Stock install? Still vulnerable on affected versions.
How do I check my version from the terminal?
If you have WP-CLI: `wp core version`. Don’t? Run `grep “wp_version” wp-includes/version.php` from your site root.
How can I tell if I’ve already been compromised?
Check for unexpected admin accounts, plugins you don’t recognise, or PHP files in your uploads directory that contain `base64_decode`. Wordfence catches the obvious stuff, but honestly it’s worth scanning manually too.
Who found this and when was it disclosed?
July 17 — researchers at Aikido Security found the chain (CVE-2026-63030 + CVE-2026-60137), WordPress released emergency patches same day, and the GitHub advisory went public simultaneously.
This is one of those vulnerabilities that makes me think “how did this even get through review?” because it combines two separate bugs into a complete remote code execution chain, requires zero authentication to trigger, and affects almost half the websites on the internet.
Honestly? The only reason I’m writing this instead of rebuilding servers right now is because WordPress forced the updates through before most people even knew what was happening. And that’s actually impressive in a “they panicked but did the right thing” kind of way.
If you need help checking your site or keeping it patched? [Drop me a line](https://rebootwebsites.co.za/contact/). I’d rather have coffee and a chat about your website than explain to someone why their site’s hosting cat porn after 2am.
One more thing. Most of what gets a site patched quickly is small, repeated, and easy to forget. That is the kind of thing worth turning into a setting you stop thinking about.