I would much rather write a post about a new plugin or a feature our users have been waiting for. But trust is not built only by sharing the good news. It is also built by being honest when something goes wrong.
Recently, the BerryPress website was one of millions of WordPress-powered sites exposed to a critical vulnerability in WordPress core.
In the aftermath of the public disclosure of the security bug, we discovered an unfamiliar administrator account on the live site. Our investigation then uncovered malicious files disguised as ordinary WordPress plugins, along with backdoors that could execute commands on the server. In other words, this was not merely a wave of failed login attempts, something that our existing security measures successfully guard against day after day. The attacker had gained a foothold inside the website.
This is uncomfortable to discuss publicly. We build WordPress products, including tools intended to make authentication safer, so we understand how quickly a critical pre-authentication flaw can expose affected sites – and why the successful deployment of security updates must be actively verified. What distinguishes a responsible team is how quickly and rigorously it detects, contains, investigates, and learns from an incident.
This post explains what we currently know, what we did in response, and what other WordPress site owners can learn from our experience.
The vulnerability: a critical flaw in WordPress core
The evidence we found is consistent with wp2shell, tracked as CVE-2026-63030. This was a critical remote code execution vulnerability in WordPress core.
The issue combined confusion in the WordPress REST API batch route with SQL injection. An attacker could send a specially crafted request to a vulnerable website and execute code remotely – without first logging in and without relying on a vulnerable third-party plugin. In security terminology, this was a pre-authentication RCE, one of the most serious types of vulnerability because successful exploitation can give an attacker control over a site.
The affected WordPress versions were:
- WordPress 6.9.0 – 6.9.4, fixed in 6.9.5;
- WordPress 7.0.0 – 7.0.1, fixed in 7.0.2.
Because of the severity, the WordPress.org team enabled forced automatic updates for affected versions. The official WordPress 7.0.2 release announcement recommends updating immediately. A clear independent overview is also available in Nebula Design’s explanation of wp2shell.
Our production site was running WordPress 7.0.1, one of the affected versions.
The logs contain hundreds of requests to the WordPress REST batch endpoint concentrated during the incident, including a burst correlated with the installation and use of the malicious components.
What the attackers did
Once inside, the attackers created or used administrator-level access and uploaded several malicious “plugins.” Their names were designed to look plausible – for example, like a performance or maintenance tool – but their real purpose was to preserve access.
We found multiple backdoors capable of:
- running system commands on the server;
- creating additional malicious files;
- exposing an unauthenticated REST API endpoint controlled by the attacker;
- maintaining access even after one malicious component was removed.
We are intentionally not publishing the attackers’ access tokens, complete source code, or other details that would make these backdoors easier to reuse.
Our logs also indicate attempts to access or extract information including:
- WordPress user names and email addresses;
- WooCommerce customer records;
- email addresses present in comments, billing records, or newsletter data;
- database credentials and server-path information stored in
wp-config.php; - SMTP credentials or configuration from mail-related plugins.
Our investigation found no evidence that product activation keys or payment card details were exposed at any time. Payment processing is handled by Stripe and PayPal, which do not store full payment card details within WordPress. Our investigation focused primarily on customer information, account data, and credentials that may have been accessible through the compromised environment.
At this time, we have no evidence that customer accounts were misused or that any personal data has been published or abused. However, because the attackers had privileged access, we chose to treat all data and secrets that may have been accessible through the WordPress installation as potentially compromised, even where the logs did not prove that a specific value had been accessed or extracted. We responded accordingly by rotating credentials and following a full remediation process.
How we responded
We followed established incident-response priorities: preserve the evidence, contain the threat, remove unauthorized access, recover from trusted sources, and monitor for any sign of recurrence.
We then took the following steps:
- Preserved and reviewed the evidence. We collected security and server logs, recorded the suspicious administrator activity, and identified recently created or modified files.
- Contained and removed the malicious access. We removed the identified backdoors and fake plugins and searched systematically for related persistence mechanisms, including unexpected PHP files, scheduled tasks, and must-use plugins.
- Applied the patched WordPress release. We moved the site to a fixed version and verified the version running in production.
- Reset access. We changed administrator and infrastructure credentials, including database, SMTP, deployment, API keys.
- Invalidated active sessions. We rotated the WordPress security keys and salts in
wp-config.php, forcing existing sessions to sign in again. - Reviewed every privileged account. We removed unauthorized users and checked all remaining administrator accounts and role changes.
- Scanned and restored carefully. We compared files against trusted sources and rebuilt the production installation from clean sources, then scanned again.
- Expanded monitoring coverage. We added further visibility and alerts around administrator logins, account creation, role changes, file changes, and plugin installation.
We completed the cleanup after removing the malicious files, changing all affected credentials, and carefully reviewing the website for any remaining signs of compromise.
We continued reviewing traffic after containment. In the available follow-up log window, we found ongoing automated probes against WordPress login, XML-RPC, configuration files, and the REST batch endpoint, but no evidence of another successful login or renewed access to the known malware paths.
If you ever face a similar incident, the official WordPress guide for hacked sites provides a practical starting point. Remember that changing a WordPress password is necessary, but it is not enough. A serious compromise can affect database credentials, hosting access, SMTP accounts, API keys, active sessions, scheduled tasks, and files outside the normal plugin list.
Lessons reinforced by this incident
1. An update is not complete until you verify it
WordPress can install security updates automatically, but hosting restrictions, version-controlled deployments, disabled background updates, or a failed update can leave a site exposed. For a critical release, check the production version directly.
2. A visible warning may be only one part of the incident
The first visible warning was a new administrator account. We treated it as a potential indicator of a wider compromise and conducted a broader forensic review. The logs helped reconstruct the sequence of events and identify additional malicious files. For any site owner, the lesson is clear: preserve the evidence and investigate the full environment rather than treating an unexpected privileged account as an isolated issue.
3. Backups must be clean, off-site, and tested
A backup stored on the same compromised server may also be changed or deleted. A backup from yesterday may already contain a dormant backdoor. Keep multiple off-site restore points and test restoration before an emergency. Consider using backup systems outside of your WordPress installation, such as through your hosting system (as we do), to isolate access to off-site backups from on-site vulnerabilities.
4. Security has to be layered
Two-factor authentication is valuable, but it cannot patch a pre-authentication vulnerability in WordPress core. Updates, least-privilege access, monitoring, file-integrity checks, backups, a web application firewall, and secure authentication address different parts of the risk. No single plugin can replace all of them.
5. Alerts should focus on actions that matter
Most site owners do not watch the Users screen all day. A new administrator, a user promoted to Administrator, or an unexpected privileged login should generate a notification immediately. The sooner you see an indicator of compromise, the smaller the attacker’s window can be.
A practical checklist for WordPress site owners
If your site ran WordPress 6.9.0-6.9.4 or 7.0.0-7.0.1, updating closes the vulnerability, but it does not prove the site was not compromised before the update.
We recommend that you:
- update to a patched WordPress release immediately;
- confirm the live version after the update;
- review all Administrator accounts and recent role changes;
- inspect recently installed plugins, including must-use plugins;
- review server and security logs for unusual REST API batch requests and unfamiliar admin activity;
- scan for unexpected or recently modified PHP files (using a server-side malware scanner such as Wordfence or Sucuri Security, and verify suspicious files manually);
- rotate credentials if there is any evidence of compromise, including database, hosting, SMTP, and API credentials;
- rotate WordPress salts to invalidate active sessions;
- remove unused plugins and themes and update everything you retain;
- enable 2FA for privileged accounts;
- maintain tested, off-site backups with more than one restore point;
- ask a qualified incident-response professional for help if you cannot establish a clean state with confidence.
WordPress also maintains a broader hardening guide covering updates, backups, file permissions, logging, and monitoring.
How this is shaping LoginBerry
This incident made an abstract risk painfully real. It also sharpened our priorities for LoginBerry, our authentication and login-monitoring plugin.
LoginBerry currently provides independently configurable features including:
- email-based two-factor authentication by user role;
- passwordless login using one-time email codes;
- account email verification;
- successful and failed login logs, including IP address and timestamp;
- optional last-login tracking in the WordPress user list.
These features do not “prevent every hack,” and we will never market them that way. Authentication controls cannot patch a pre-authentication vulnerability in WordPress core. They can, however, complement updates and infrastructure security by making privileged activity easier to audit and high-risk changes faster to detect.
Based directly on this incident, we developed several new security features that are currently being tested and will be released soon:
- email notifications for administrator logins;
- alerts when a new administrator is created or a user is promoted to Administrator;
- an optional must-use component that is harder for an attacker to deactivate from the Plugins screen;
- optional administrator restrictions based on approved email domains.
- email notifications when a plugin or theme is installed, activated, deactivated, updated, or removed;
These controls map to concrete events that security and incident-response teams need to identify quickly: privileged access, creation or promotion of administrator accounts, and attempts to disable the monitoring layer itself.
LoginBerry should be one layer in a wider security strategy – not a reason to delay core updates or skip backups.
Why we are sharing this
There is a temptation after an incident to say as little as possible, clean up quietly, and move on. I understand that instinct. Security incidents are uncomfortable to discuss, especially when your work is closely connected to the ecosystem that was attacked.
But hiding the experience would waste its most useful lesson: security incidents do not happen only to careless people or obviously neglected websites. A critical vulnerability can turn the time between disclosure and patching into a race.
We are treating the incident seriously, improving both our internal practices and our products, and sharing what we learned so that others can respond quickly and with better information.
We hope this write-up helps other WordPress site owners recognize similar attacks sooner and respond with confidence.
If you have questions about this incident, or if you think your site may have been affected, please get in touch. If you need help investigating or cleaning your WordPress site, we’re happy to help. You can contact us through help.berrypress.com or connect with me on LinkedIn.