WordPress hacked recovery is not a headline we ever wanted to write. Earlier this week, our store showed signs of an unauthorized WordPress compromise. We treated it as an incident, not a mystery. We preserved evidence, found the foothold, contained it, recovered access, patched the software, and verified the customer-facing store. WordPress has since confirmed that version 7.0.2 fixed a critical REST API batch-route issue. That issue could lead to remote code execution.
We used OpenAI Codex as part of our company’s response team. That does not mean we handed an AI the keys and walked away. Instead, Codex helped our people investigate evidence and compare system state. It also performed repeatable integrity checks and documented approved recovery work. Every destructive or customer-impacting action stayed behind human authorization and a verified rollback path.
What happened to our WordPress store
Our investigation found evidence consistent with the publicly reported wp2shell campaign: an attacker used a WordPress Core vulnerability to gain unauthenticated access, then tried to establish persistence with a malicious plugin and unauthorized administrator accounts. We will not publish the route, payload, or code involved. Those details are useful to attackers and are not needed for a site owner to defend a business.
The independent researcher said affected stock installations included WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. Therefore, WordPress 7.0.2 was the recommended fix. Searchlight Cyber’s advisory says temporary batch-API blocking can be an emergency measure. Use it only when an immediate update is not possible. In our case, containment and patching beat a permanent broad shutdown of the REST API.
How the attack worked, without giving attackers a recipe
At a high level, the vulnerability involved confusion in a WordPress REST API batch route. It was chained with a database-query issue. That combination could let an unauthenticated attacker reach server-side code execution on affected versions. Once an intruder gets that foothold, the next objective is usually persistence: a web shell, a rogue administrator, altered files, or stolen application secrets.
That is why “we updated WordPress” is not enough after a suspected compromise. A patch closes the known door; however, it does not automatically remove someone who walked in before it was closed. Therefore, recovery needs evidence, containment, credential rotation, integrity validation, and real checks of the site’s important user journeys.
What Codex helped our team do
Codex turned a stressful situation into an evidence-driven checklist. First, we preserved a dated backup and incident evidence before making changes. Next, we inventoried administrator accounts and active plugins. Additionally, we checked recently changed files, scheduled work, WordPress Core integrity, and the store’s payment and email surfaces.
After human review, we removed the unauthorized administrator accounts, quarantined the malicious code, rotated the store administrator credential, invalidated WordPress sessions, and refreshed the site’s security keys. We then reinstalled and verified clean WordPress Core files, updated the store to WordPress 7.0.3, verified Core and Easy Digital Downloads checksums, and tested the live homepage, account, and checkout pages.
The key distinction is accountability. Codex could inspect, compare, and execute approved, logged steps quickly. Meanwhile, our team decided what evidence mattered. We approved changes, protected backups, and verified the result. That is what it looks like when AI becomes part of a company. It is not a chat assistant on the sidelines. Instead, it is a supervised operational partner with guardrails.
What payment and license evidence told us
We found no evidence in the store database that raw card numbers or CVVs were stored there. The store uses payment providers for card processing. That does not replace provider-side review. An attacker with server access may be able to read configuration and application secrets. Businesses in this position should rotate payment-provider API credentials and review provider dashboards. They should also review payout settings and follow their legal, processor, and incident-response obligations.
We also checked the store’s available email and license records. Those checks did not show logged outbound mail or newly created or changed license records during the incident window. However, missing records are not proof that nothing was ever accessed or copied. Therefore, good incident response separates what is verified from what is unknown.
A safe prompt to give your own AI during a suspected compromise
If you run WordPress, you do not need to understand exploit development to use an AI productively. Start with a tightly scoped, defensive instruction like this:
“Treat this as a suspected WordPress compromise. Do read-only triage first: preserve evidence; list administrator accounts, active plugins, recent PHP files, and scheduled tasks; compare WordPress Core and plugin checksums; review payment and email exposure; then propose a scoped containment plan. Do not reset passwords, delete users, or publish changes until I approve.”
Then review and approve the plan. Tell the AI to execute only necessary recovery actions. That can include quarantining confirmed malicious code, removing confirmed rogue accounts, rotating credentials and sessions, and patching WordPress and plugins. Afterwards, re-run integrity checks and public checkout/account tests. Keep a written record of every change. If your site is a store, bring in your payment provider and a qualified incident-response professional when the facts warrant it.
Our patch status and WordPress guidance
WordPress’s July 17 security release says 7.0.2 addressed the REST API batch-route confusion and SQL-injection issue. The project recommended immediate updates. The store now runs WordPress 7.0.3, beyond that fixed release. Core checksum verification and live homepage, account, and checkout checks all passed. We reviewed WordPress’s published security release and reporting guidance. Because this incident concerns a known, patched issue, we preserved sanitized evidence and will provide it through an approved private channel if WordPress requests it. This report will be updated if WordPress publishes additional guidance.
For anyone looking for WordPress hacked recovery help: patch first, but do not stop there. Preserve evidence, find persistence, rotate secrets, validate the application, and test the functions that make your business money. AI can help defenders meet attackers pound for pound—if it is operating with the right access, clear boundaries, and a human team that insists on proof.
For another look at how we use supervised agents in day-to-day operations, read our Codex review for creators and our coverage of OpenAI Codex Micro.
