Hackers Chain Two WordPress Bugs to Hijack Sites Without a Password

Key points

• Attackers are actively exploiting two critical WordPress flaws, CVE-2026-63030 and CVE-2026-60137, chained together under the name wp2shell.
• The chain gives unauthenticated remote code execution, meaning an attacker needs no login to take full control of a vulnerable site.
• Mass scanning and successful break-ins were observed by the early hours of Saturday (UTC) after a public exploit was released.
• Site owners should patch immediately and check for signs of intrusion, including new admin accounts and unfamiliar PHP files.

Attackers are breaking into WordPress websites by chaining two serious flaws that, used together, let them run their own code on the server without ever logging in.

The combined attack has been nicknamed wp2shell. It joins two separate bugs, tracked as CVE-2026-63030 and CVE-2026-60137, into a single push-button takeover. In plain terms: one bug gets the attacker in the door, the second lets them plant and run a malicious script on the site.

That combination is called unauthenticated remote code execution, or RCE. It is the worst-case outcome for a web server. No password needed. No user tricked into clicking anything. The attacker sends a crafted web request and, if the site is vulnerable, they own it.

Mass exploitation began fast. By the early hours of Saturday morning, UTC, successful break-ins were already being logged in the wild, according to reporting by The Hacker News. A public proof-of-concept exploit, working attack code released online, appears to be driving the surge.

What does this mean for a normal website owner?

If you run a WordPress site and have not patched, assume you are a target right now. Automated scanners do not care whether you run a florist, a school, or a law firm. They spray the internet looking for the vulnerable version and hit whatever answers back.

A compromised WordPress site is typically used for one of a few things. Attackers plant a web shell (a hidden control panel they can revisit later), redirect visitors to scam pages, mine cryptocurrency using your server, or use the site as a stepping stone into other systems on the same host.

For visitors of a hacked site, the risks are practical. You might land on a fake login page. You might be pushed to download something that looks like a browser update but is actually malware. If you entered a password on the site during the compromise window, treat it as burned and change it elsewhere.

How to check if you have been hit

Patching alone is not enough once exploitation is this widespread. Sites that were vulnerable before the update went on likely already have a backdoor.

A few concrete steps for site owners and their admins:

1. Update WordPress core and any affected plugins to the fixed versions immediately.
2. Look for admin accounts you did not create, and remove them.
3. Search the WordPress install directory for recently modified or unfamiliar PHP files. Web shells often hide in wp-content/uploads or masquerade as legitimate plugin files.
4. Rotate every credential the site touches: WordPress admin passwords, database passwords, hosting panel logins, and any API keys stored in configuration.

If the site handled customer data, logins, or payments, treat this as a data incident and consult your legal or compliance lead. Depending on jurisdiction, notification duties may apply.

WordPress powers a large share of the public web, so the target pool for wp2shell is enormous. Expect the exploitation wave to continue for weeks. Old, unmaintained sites (the abandoned company blog, the events microsite nobody owns) will keep falling for months. Those are exactly the sites that tend to become long-lived staging grounds for other attacks.

One caveat worth flagging: precise fixed-version strings and the exact plugin or core component involved should be confirmed against the official WordPress security advisory before you plan your rollout. Do not take a stranger's word for it, including mine.