Woke up to a SANS ISC diary about a new WordPress core vulnerability — CVE-2026-63030, “wp2shell.” Unauthenticated SQL injection, no plugin required, straight into core. The kind of bug that makes you check your own site before you finish your coffee. (link below)
https://isc.sans.edu/diary/WordPress+Exploitation+Underway+CVE202663030/33168
Checked. My version: 6.9.1. Right in the vulnerable range.
What followed was a several-hour crawl through the actual mechanics of getting a real production site patched when the “automatic” updater silently fails. Turned out my host’s internal update mirror couldn’t resolve DNS — a cURL error 6 that had apparently been quietly breaking updates long before this CVE ever existed. No amount of clicking “Check again” in wp-admin was going to fix that.
So: SFTP, FileZilla, a fresh core download straight from wordpress.org, a backup of wp-admin and wp-includes (the actually-relevant subset, not the entire multi-gigabyte wp-content folder I torched an hour on before realizing my mistake), and a manual file swap. Support chat helped, eventually, after some initial confusion about PHP compatibility that turned out to be a red herring.
Patched to 7.0.2. Then did what you’re supposed to do after any “were you actually exploited” scare: checked /wp-content/cache/ for planted shells (folder didn’t even exist — a small mercy), checked Users for anything I didn’t create (found one leftover temp-access account from a support session, cleaned it up), confirmed no other footholds.
Bonus discovery along the way: my hosting package is still running PHP 7.4.33 — end-of-life since November 2022 — and it turns out this specific WordPress package doesn’t allow PHP version changes at all, by design. That’s a different problem, for a different day, possibly involving an actual migration.
Today’s lesson: “the update failed” is never the end of the story. It’s usually the start of the interesting part.