One Website Became a Route to Government Data
GreyNoise’s investigation, published 21 September 2026, traces 18,566 or more stolen records to one government in the West. Accounts, unencrypted passwords and personal information concerned police and government bodies. This is one target’s confirmed loss, not a campaign-wide total.
The wp2shell route chained CVE-2026-63030 and CVE-2026-60137 through WordPress to run code, preserve access and reach a connected database. Researchers counted 49 or more organisations in 29 countries, with some locations undetermined. Their observations do not establish that every target lost data or that all victims were counted.
On 21 July 2026 the federal exploitation catalogue listed both flaws. Investigators place the government intrusion on the following day using timestamps on files they retained. A separate forensic reconstruction could produce different clock times.
An update does not finish the incident
The security release that month fixed both components in 7.0.2 and 6.9.5. Branch 6.8 had the SQL issue alone, fixed in 6.8.6; the test branch received 7.1 beta2. Versions before 6.8 were unaffected. These are historical first fixes, not current production recommendations: use a currently maintained secure release.
A publishing host can retain application credentials, database connections, cloud tokens, backup locations and trusted network routes. The hardening guidance separates host/application responsibility and stresses containment.
Six checks beyond the publishing host
- Inventory the estate. Locate every installation, including campaign sites, old microsites and agency- or contractor-owned environments. Confirm who maintains each.
- Patch both components. Treat them as one entry route, checking the actual installed, maintained release on every reachable instance. Updating does not rule out earlier compromise.
- Hunt for persistence. Review recently created or modified PHP files, unfamiliar administrator accounts, scheduled jobs, plugins and configuration changes. Preserve evidence before cleaning.
- Trace connected access. Examine database activity, outbound connections, cloud audit logs and use of secrets stored on the server, beyond web requests.
- Replace exposed credentials. After containment, replace potentially exposed login salts, database passwords, API keys and deployment credentials. Reset access again after clean recovery, following the official recovery guidance.
- Determine data reach. Record what the application could query, export or access through adjacent systems, which data was reachable and what the evidence actually shows was extracted.
The wider containment approach supports investigating the full environment. Closing a known route is necessary; tracing prior access and data movement answers a different question.
