A threat actor has posted what they claim are publicly accessible WordPress configuration backup files from municipal government portals in Sonora, Mexico. According to the underground listing, 16 backup files were reachable through ordinary web browsers, no hacking tools required, no passwords needed. Just the right URL and a direct download.
If the claim checks out, the damage potential goes well beyond leaked contact details. The exposed files allegedly contain live database passwords, administrator authentication keys, and enough internal server information for an attacker to log into government systems, impersonate administrators, and access citizen data, all without triggering a single alarm.
The Sonora state government and the affected municipal portals have not issued public statements confirming or denying the exposure. The claim remains unverified. But the underlying vulnerability it describes is very well documented, very common, and almost trivially easy to exploit when it exists.
Quick answer: A threat actor on an underground forum claims to have found 16 publicly accessible WordPress configuration backup files tied to municipal government portals in Sonora, Mexico. These files allegedly expose live database credentials, authentication salts, multisite configuration details, user data through the WordPress REST API, and PHP debug logs. None of this has been independently confirmed. But the exposure type described, a publicly accessible wp-config backup, is one of the most well-known and dangerous WordPress misconfigurations that exists.
What Is a wp-config File and Why Does This Matter?
Every WordPress website has a core file called wp-config.php. Think of it as the master key to the entire site. It contains the username and password to access the database, the secret keys WordPress uses to generate and verify login sessions, and the filesystem paths that map how the server is structured internally.
By default, this file is protected. WordPress is built to block direct browser access to it. But when a developer or automated backup tool creates a copy of that file — say, while updating a site or migrating it to a new server, that copy often gets saved under a slightly different filename: wp-config.php.bak, wp-config.bkp, wp-config.php~, or wp-config.old. And those backup versions don’t inherit the same protection. They can sit inside a web-accessible folder completely open to anyone who types the right URL.
That is what the threat actor in this case claims to have found. Not a sophisticated exploit. Not a zero-day vulnerability. Just backup files left in web-accessible directoriesexactly the kind of , misconfiguration that automated scanners probe for constantly, often within hours of a file being created.
What the Listing Claims Was Exposed
According to the underground posting, the 16 backup files contain several distinct layers of sensitive information. Each one on its own would be a problem. Together, they represent near-complete administrative access to the affected portals.
Live database credentials: The username and password required to connect directly to the MySQL database behind each site. With these, an attacker doesn’t interact with WordPress at all. They connect straight to the database, read everything stored in it, modify records, create new administrator accounts, or wipe it entirely. WordPress’s login system is completely bypassed.
Authentication salts: This is the detail most news coverage of WordPress exposures misses entirely. WordPress uses eight long random strings called salts to generate and verify login cookies. If an attacker gets the salts, they can forge a valid WordPress session cookie for any user, including administrators, without knowing a single password. They effectively become the admin without needing to log in. Threat documentation from ThreatPort describes this directly: exposed salts allow “impersonating any user, including administrators, without needing to know the password.”
Multisite and subdomain configuration: The claim states that the affected environment runs a shared WordPress multisite installation supporting multiple Sonora government websites simultaneously. This changes the scope significantly. In a multisite setup, one installation powers many separate sites under a single shared database and core files. If the configuration for that shared installation is compromised, every site running on it is potentially exposed through the same credentials, not just one portal but all of them.
User and account information through the WordPress REST API: WordPress’s built-in REST API, when not properly locked down, can return a list of all user accounts on a site at a publicly accessible URL endpoint. This doesn’t require authentication. An attacker running a simple query gets back usernames and display names for every account registered on the site, including administrators. Those usernames are then available for targeted phishing, password spraying, or social engineering attacks against government staff.
PHP debug logs: If WordPress debug mode is active, PHP logs errors and warnings to a log file. Those logs often contain file paths, server configuration details, database table structures, error messages from failed queries, and sometimes even partial credential information. They effectively hand an attacker a map of the server’s internal structure that would otherwise require substantial reconnaissance work to build from scratch.
The Specific Risk of a Shared Government Multisite
The multisite angle deserves more attention than most coverage of WordPress exposures gives it.
When a single WordPress installation powers multiple government websites, the database is shared. One set of credentials opens all of them. One exposed wp-config backup from any site on the network reveals the master password for the entire installation.
This is a common setup for municipal governments that manage multiple portals on a limited IT budget, one server, one WordPress install, several sites running off the same backbone. It’s efficient and cost-effective. But it also means that a misconfiguration on one site isn’t contained to that site. The blast radius from a single exposed backup file covers every portal in the network.
The claim in the underground listing specifically states the exposed environment is “connected to a shared WordPress multisite installation supporting multiple Sonora government websites.” If accurate, that means multiple municipal portals, any of which might handle citizen applications, permit requests, local services, or benefit enquiries, share the same compromised credentials.
Mexico’s Municipal Governments Have Been a Repeated Target in 2026
This isn’t an isolated event in a vacuum. It fits a documented pattern that has been running through 2026.
In January 2026, the Chronus Group claimed to have breached at least 25 Mexican government agencies, publishing what it described as 2.3 terabytes of data affecting up to 36 million citizens. Mexico’s national cybersecurity agency, the ATDT, said at the time that the data appeared to come from previously compromised legacy systems rather than a new attack on live infrastructure, but the scale of the exposure was real regardless of its origin.
Between late December 2025 and mid-February 2026, a single threat actor breached at least nine Mexican government organizations including the national tax authority SAT, the National Electoral Institute, multiple state governments, and a municipal water facilityusing commercial AI tools to accelerate reconnaissance and exploitation in a campaign that exposed an estimated 150GB of sensitive data.
As recently as August 15, 2026, intelligence reports flagged an alleged compromise of the municipal government of Cuautitlán Izcalli in the State of Mexico, with the threat actor claiming administrative access to internal IT infrastructure and exfiltrated resident data.
The Sonora exposure fits this trajectory: smaller municipal governments, running shared infrastructure, with configuration misconfigurations that are easy to find and easier to exploit. Understanding why your data might end up circulating online after incidents like this is part of why we put together our guide on what to do if your information is already on the dark web — the steps matter regardless of which country the breach originated in.
