Notice
This article is based on WordPress security updates, analyses published by cybersecurity firms, and related reports available as of July 21, 2026. Details about the attack methods and indicators of compromise may change as further investigations are conducted.
What This Article Covers
Critical vulnerabilities discovered in the WordPress core software began to be exploited in real-world attacks shortly after security patches were released.
These vulnerabilities are not limited to a particular plugin or theme. They were found in WordPress’s core REST API request-handling logic and database query-processing mechanism. By chaining the two vulnerabilities together, an attacker can execute arbitrary code on a server without logging in.
This goes beyond gaining administrator privileges on a vulnerable website. It means that an attacker could effectively take control of the server environment in which the site is running.
Two Vulnerabilities Discovered in WordPress Core
The attacks reportedly involved two separate WordPress vulnerabilities.
CVE-2026-63030 was discovered and reported by Adam Kues, a researcher at cybersecurity firm Searchlight Cyber, which named the vulnerability WP2Shell.
The first vulnerability, CVE-2026-63030, is a validation flaw in the way the WordPress REST API processes requests.
The REST API is an interface that allows external applications and WordPress administrative features to access content such as posts and user information. In vulnerable versions, however, certain requests could be trusted even when they had not been properly validated.
The second vulnerability, CVE-2026-60137, is an SQL injection vulnerability that allows attackers to manipulate commands sent to the database.
SQL injection is an attack in which an attacker inserts database commands into input submitted to a website, allowing data to be retrieved or modified in ways that would normally not be permitted.
The SQL injection vulnerability may present a relatively lower level of risk when exploited on its own. However, when combined with the REST API vulnerability, it can lead to a remote code execution attack, or RCE, allowing an attacker to run code on the server without logging in.
Attackers Can Take Over a Site Without Logging In
Taking control of a WordPress website generally requires an attacker to steal an administrator’s password or exploit a vulnerable plugin to obtain administrative privileges.
The latest vulnerabilities, however, can be exploited without first gaining access to a legitimate administrator account.
When the two vulnerabilities are chained together, an attacker may be able to perform the following actions:
- Create a new administrator account
- Install a malicious plugin or backdoor
- Modify website files and databases
- Redirect visitors to a malicious website
- Distribute phishing pages and malware
- Use the server as an intermediary for additional attacks
Once a backdoor has been installed, an attacker may be able to regain access even after the WordPress version has been updated.
Websites that previously used a vulnerable version should therefore do more than simply install the update. Their operators should also investigate whether the site may already have been compromised.
Affected WordPress Versions
The main versions affected by both vulnerabilities are:
- WordPress 6.9.0 through 6.9.4
- WordPress 7.0.0 through 7.0.1
WordPress 6.9 installations should be updated to version 6.9.5 or later, while WordPress 7.0 installations should be updated to version 7.0.2 or later.
The WordPress 6.8 branch is not affected by the REST API vulnerability, but it may still be affected by the SQL injection flaw. WordPress 6.8 installations should therefore be updated to version 6.8.6 or later.
The required updates can be summarized as follows:
- WordPress 7.0.0–7.0.1: Update to version 7.0.2 or later
- WordPress 6.9.0–6.9.4: Update to version 6.9.5 or later
- WordPress 6.8.0–6.8.5: Update to version 6.8.6 or later
WordPress determined that the vulnerabilities were severe enough to enable forced automatic updates where possible. After real-world exploitation was confirmed following the release of the security patches, the WordPress project took more active measures than simply advising users to update.
Real-World Attacks Began Within a Day of the Patch Release
One of the most important aspects of this incident is the short amount of time between the release of the vulnerability patches and the beginning of real-world attacks.
Cybersecurity firm WatchTowr said that attacks were already underway by early the following morning after WordPress distributed the patches.
WatchTowr’s honeypots reportedly recorded tens of thousands of attack attempts and the creation of more than 100 backdoor administrator accounts. Some attackers also reportedly attempted to install remote-control malware on compromised servers.
Multiple cybersecurity firms, including Patchstack, Hexastrike, and WatchTowr, warned that the vulnerabilities were being exploited in real-world environments. This means the incident had moved beyond the publication of proof-of-concept code demonstrating that an attack was theoretically possible. Attackers were actively attempting to break into WordPress sites that had not yet been updated.
When a vulnerability is disclosed, attackers compare the source code before and after the patch to determine what was changed.
By examining those differences, they can work backward to identify the location of the vulnerability and reconstruct a possible attack method. As a result, the release of a security patch can also provide attackers with clues about the underlying flaw.
The growing use of automated tools and AI-based code analysis is further reducing the time required to analyze public patches and develop working exploit code.
How Many Websites Are Actually at Risk?
WordPress is one of the most widely used content management systems in the world.
It powers not only personal blogs but also corporate websites, news publications, online stores, and public-sector websites.
Applying WordPress’s official version statistics directly would suggest that a very large number of websites may have been running affected versions.
Cybersecurity consultant Daniel Card examined a sample of approximately 3,500 WordPress websites and estimated that fewer than 15% remained vulnerable. Applying that estimate to the entire WordPress website population would produce a figure of approximately 90 million sites.
However, this figure should not be treated as the confirmed number of vulnerable websites.
WordPress version statistics may include sites that have already completed automatic or manual updates. Some attacks may also have been blocked by Cloudflare or web application firewalls, while managed hosting providers may have automatically deployed the patches to customer websites.
The important point is therefore not the exact number of vulnerable sites, but the possibility that the attack surface may extend across a very large number of WordPress installations.
Why This Is Different from a Plugin Vulnerability
Many WordPress security incidents originate from outdated plugins or themes.
In those cases, websites that do not use the affected plugin are generally not directly exposed to the vulnerability.
This time, however, the vulnerabilities were discovered in the WordPress core code.
WordPress core is the basic software shared by every WordPress website. A site running an affected version may therefore be vulnerable regardless of which plugins it has installed.
This is not a limited issue affecting users of one particular plugin. It is a shared risk that applies across the wider WordPress ecosystem.
WordPress core vulnerabilities are particularly dangerous because a single software defect can affect a large number of otherwise independent websites at the same time.
If vulnerable websites begin to be used for malware distribution, phishing, search-result manipulation, or attacks against other servers, the incident could expand beyond the security of individual websites and become a systemic risk across the web ecosystem.
Checks Are Necessary Even After Updating
A website is not necessarily safe simply because the latest WordPress version is displayed in the administrator dashboard.
If an attacker created an administrator account or installed a backdoor before the update was applied, evidence of the compromise may remain inside the site even after the WordPress core has been patched.
WordPress operators should prioritize the following checks.
Check the WordPress Version
Open the update section of the WordPress administrator dashboard and verify the current version. Confirm that one of the patched versions—7.0.2, 6.9.5, or 6.8.6 or later—has been installed, depending on the release branch being used.
Check the Automatic Update Settings
Verify that automatic security updates for WordPress core have not been disabled. Sites using managed hosting should also confirm whether the hosting provider automatically applied the emergency patch.
Look for Unfamiliar Administrator Accounts
Review the user list for administrator accounts that were not intentionally created or that use unfamiliar email addresses.
Inspect Plugins and Themes
Check for plugins that were not knowingly installed, plugins that were recently activated without authorization, and themes from unknown sources.
Change Administrative Passwords
When a compromise is suspected, it is safer to change the passwords for the WordPress administrator account, hosting account, database, and FTP or SSH accounts.
Review Access Logs and File Changes
Look for unfamiliar administrator logins, abnormal REST API requests, recently modified PHP files, and suspicious communications with external servers.
The cited security report also recommends checking for unfamiliar administrator accounts and unknown plugins even after the WordPress update has been completed.
Why Automatic Updates Are Becoming More Important
In the past, website operators could often manage security by periodically logging in to the administrator dashboard and checking for updates.
However, when real-world attacks begin within a day of a patch release, as they did in this incident, weekly or monthly inspections are no longer sufficient.
As the time between vulnerability disclosure and real-world exploitation continues to shrink, the following security measures become increasingly important:
- Automatic installation of WordPress core security updates
- Automatic plugin and theme updates or rapid manual review
- Attack-request blocking through a web application firewall
- Administrator account login alerts
- File-change detection
- Regular external backups
- Emergency security patching by hosting providers
People who operate websites independently often do not have dedicated cybersecurity personnel. For that reason, relying on an administrator to discover vulnerability information and respond manually is less practical than actively using automatic updates and security features provided by hosting companies.
What to Watch Next
At this stage, it has been confirmed that the WordPress vulnerabilities are being exploited in real-world attacks.
The following developments should now be monitored:
- Whether compromised websites are used to distribute malware or phishing pages
- Whether SEO spam designed to manipulate search results begins to spread
- Whether detailed indicators of compromise, including IP addresses and filenames, are released
- Whether attack campaigns targeting particular countries or industries are identified
- Whether hosting providers block vulnerable versions or expand forced-update measures
- Whether additional security tools are released to diagnose and recover compromised websites
The actual scale of the damage will become clearer once more information is available about the malware installed by attackers and how compromised websites are being used.
DANA NOTES Commentary
The key issue in the latest WordPress incident is not simply that severe security vulnerabilities were discovered.
What matters more is that less than a day passed between the publication of the patches and the beginning of real-world attacks.
Even when a software provider fixes a vulnerability and distributes a patch, the flaw remains exposed on systems that have not installed the update.
Attackers analyze the patch, rapidly reconstruct the vulnerability, and automatically scan the internet for websites running affected versions.
As a result, the focus of cybersecurity is shifting away from a model in which vulnerabilities are discovered and addressed through periodic maintenance. It is moving toward a model in which patches are applied immediately and signs of compromise are detected in real time.
The first action WordPress operators should take is to check the version number displayed in the administrator dashboard.
However, when real-world attacks have already begun, confirming that the update has been installed is not enough.
Operators should also inspect unfamiliar administrator accounts, plugins, and file-change records. When compromise is suspected, they may need to restore the site from a clean backup and change all related account passwords.
The convenience of WordPress comes from allowing many different websites to use the same platform.
At the same time, that shared foundation means a single vulnerability in the WordPress core can affect a large number of websites simultaneously.
