WordPress Security Plugin Vulnerability Exposes User Data on 100,000+ Sites
A serious vulnerability has been discovered in the Anti-Malware Security and Brute-Force Firewall plugin for WordPress. This flaw, tracked as CVE-2025-11705, allows users with minimal account privileges to read arbitrary files stored on the server. The plugin is installed on more than 100,000 websites, but only half of those sites have applied the security patch released to fix the problem.
What This Plugin Does
The Anti-Malware Security and Brute-Force Firewall plugin provides several security functions for WordPress sites. It scans for malware infections, protects against brute-force password attacks, blocks exploitation attempts targeting known vulnerabilities in other plugins, and defends against SQL injection attacks.
Website administrators install this plugin specifically to improve their site's security. The irony that a security tool itself contained a vulnerability that exposed sensitive data is not lost on the security community.
How the Vulnerability Was Discovered
Security researcher Dmitry Ignatiev discovered the vulnerability and reported it to Wordfence specialists through their bug bounty program. Bug bounty programs encourage researchers to report security issues responsibly rather than publicly disclosing them or selling them to malicious actors. Researchers receive financial rewards for valid vulnerability reports.
The flaw affects version 4.23.81 and all earlier versions of the plugin. Sites running these versions remain vulnerable until they update to the patched version.
The Technical Details
The vulnerability exists in a function called GOTMLS_ajax_scan(), which handles AJAX requests. AJAX (Asynchronous JavaScript and XML) allows web pages to update content dynamically without requiring full page reloads. WordPress plugins commonly use AJAX to process user actions in the background.
The problematic function contains a critical security flaw: it lacks a capability check. In WordPress, capability checks verify that the user requesting an action has appropriate permissions to perform that action. For example, only administrators should be able to install plugins, while regular subscribers should not.
Instead of checking user capabilities, the GOTMLS_ajax_scan() function relies solely on a nonce for security. A nonce (number used once) is a token WordPress generates to verify that requests come from legitimate sources rather than from cross-site request forgery attacks. However, nonces are not designed to enforce permission levels—they only confirm the request originated from the site itself.
The problem: attackers can discover these nonces through various means. Once they have a valid nonce, they can call the vulnerable function even though they lack appropriate permissions.
What Attackers Can Access
Because the function lacks proper permission checks, any user with even minimal privileges can exploit it. This includes regular subscriber accounts—the lowest permission level on most WordPress sites. An attacker doesn't need administrator access or special technical exploits. They simply need to create a free account on a vulnerable site.
Once they have this basic account, attackers can call the vulnerable function to read any file stored on the server. The file system access this provides makes several valuable targets available.
The wp-config.php File
The most attractive target for attackers is the wp-config.php configuration file. This file sits at the root of every WordPress installation and contains critical information the site needs to function:
- Database name
- Database username
- Database password
- Database host address
- Authentication keys and salts
- Security keys
- Table prefix
Access to this file gives attackers everything they need to directly access the site's database, bypassing WordPress entirely.
What Database Access Enables
Once attackers obtain database credentials from wp-config.php, they can extract extensive information:
Password Hashes: WordPress stores password hashes for all users. While these are hashed (encrypted), attackers can attempt to crack weak passwords offline using specialized tools and massive computing power. Once they crack an administrator password, they gain full site control.
Email Addresses: Complete lists of user email addresses support phishing campaigns. Attackers can send targeted emails that appear to come from the compromised site or reference site-specific information to increase credibility.
Post Content: All published posts and pages become accessible, along with drafts that haven't been published. Drafts might contain sensitive information authors haven't yet released publicly.
Authentication Keys and Salts: These values secure WordPress sessions and cookies. Access to them allows attackers to forge authentication cookies and impersonate users, including administrators.
Private User Data: Depending on what plugins are installed, databases may contain private messages, contact form submissions, e-commerce orders, customer information, or other sensitive data.
Comments and Moderation Queues: Unpublished comments awaiting moderation become visible, potentially revealing information commenters expected to remain private until approved.
Plugin and Theme Settings: Configuration data for other plugins might include API keys, third-party service credentials, or other sensitive technical information.
The Attack Progression
With database access, attackers follow a predictable pattern:
- Initial Access: Create a minimal privilege account or use an existing subscriber account
- Exploit Vulnerability: Call the vulnerable function to read wp-config.php
- Database Access: Use stolen credentials to connect directly to the database
- Data Extraction: Copy password hashes, emails, and other valuable information
- Password Cracking: Attempt to crack administrator password hashes offline
- Account Takeover: Log in as an administrator using cracked passwords
- Full Compromise: Install backdoors, modify content, or use the site for further attacks
This progression can happen quickly. Automated tools can execute these steps in minutes once attackers identify a vulnerable site.
The Severity Assessment
The vulnerability is not officially classified as critical because it requires authentication—attackers need some kind of account to exploit it. Security researchers reserve "critical" ratings for vulnerabilities that allow completely unauthenticated exploitation.
However, this classification understates the real-world risk. Any WordPress site that allows user registration is vulnerable. Most blogs, membership sites, e-commerce stores, forums, and community platforms allow users to create accounts. The barrier to exploitation is extremely low.
In my opinion, vulnerabilities requiring only minimal authentication deserve serious attention. Per the technical details, an attacker needs nothing more than a free subscriber account—something they can create themselves in seconds on most WordPress sites. The authentication requirement provides almost no protection in practice.
The Patch and Response Timeline
Wordfence notified the plugin developers about the vulnerability on October 14, 2025. The developers responded quickly, releasing version 4.23.83 on October 15—just one day later. This rapid response demonstrates appropriate prioritization of a serious security issue.
The patch adds a new function called GOTMLS_kill_invalid_user() that checks user permissions before allowing access to sensitive operations. This function implements the capability check that should have existed in the original code. Only users with appropriate permissions can now call the vulnerable function.
The Update Problem
According to data from WordPress.org, approximately 50,000 site administrators have downloaded the patched version since its release. Given that the plugin is installed on over 100,000 sites, this means roughly 50,000 sites remain vulnerable.
This update gap is common in the WordPress ecosystem. Many site administrators don't monitor plugin updates closely or apply them promptly. Some sites are abandoned or poorly maintained. Others have administrators who don't understand security risks or prioritize updates.
The longer sites remain unpatched, the greater the risk. Once vulnerability details become public—as they have now—attackers quickly develop automated tools to find and exploit vulnerable sites at scale.
Current Exploitation Status
Wordfence researchers report they have not yet observed exploitation of CVE-2025-11705 in real-world attacks. This doesn't mean exploitation hasn't occurred—only that Wordfence hasn't detected it through their monitoring systems.
However, the public disclosure of vulnerability details significantly increases exploitation risk. Security researchers and journalists publish these details to inform administrators about threats they face, but malicious actors read the same publications. Within days or weeks of public disclosure, automated scanning tools typically appear that search the internet for vulnerable sites.
Immediate Actions for Site Administrators
If you run a WordPress site with the Anti-Malware Security and Brute-Force Firewall plugin installed, take these steps immediately:
Update the Plugin: Log into your WordPress dashboard, navigate to Plugins, and update Anti-Malware Security and Brute-Force Firewall to version 4.23.83 or later. Do this before continuing with other tasks.
Check for Unauthorized Users: Review your user list for accounts you don't recognize. Attackers may have created accounts in preparation for exploitation. Delete any suspicious accounts.
Review Recent Activity: Check your site's activity logs for unusual file access patterns. If you have a security plugin that logs file access, look for attempts to read wp-config.php from unexpected sources.
Change Database Passwords: If you suspect your site may have been compromised, change your database password. Update wp-config.php with the new password. This invalidates any stolen database credentials.
Scan for Malware: Run a complete malware scan using a security plugin or service. If attackers gained administrator access, they may have installed backdoors or modified files.
Check Administrator Accounts: Verify that all administrator accounts are legitimate and that passwords haven't been changed without authorization.
Review Recent Content Changes: Check for unauthorized posts, pages, or comments that might have been created or modified by attackers.
Enable Two-Factor Authentication: If you haven't already, enable two-factor authentication for all administrator accounts. This provides protection even if passwords are compromised.
Preventive Measures
Beyond addressing this specific vulnerability, several practices improve WordPress security:
Regular Updates: Apply plugin, theme, and WordPress core updates promptly. Most compromises exploit known vulnerabilities that have available patches.
Limit User Registration: If your site doesn't require user accounts, disable registration entirely. Go to Settings > General and uncheck "Anyone can register."
Restrict Subscriber Capabilities: If you need user registration, consider whether subscribers need any special capabilities. Remove unnecessary permissions.
Use Security Plugins: Install reputable security plugins that monitor for suspicious activity, block brute-force attacks, and scan for malware. Wordfence, Sucuri, and iThemes Security are popular options.
Regular Backups: Maintain current backups stored off-site. If your site is compromised, backups allow you to restore to a known-good state.
Limit Plugin Count: Only install plugins you actually need. Each additional plugin increases your attack surface. Deactivate and delete unused plugins.
Choose Plugins Carefully: Before installing plugins, check their update history, user reviews, and security track record. Avoid plugins that haven't been updated recently or have known security issues.
Monitor Security Advisories: Subscribe to WordPress security mailing lists or RSS feeds to learn about new vulnerabilities affecting plugins you use.
The Bigger Picture: WordPress Security Challenges
This vulnerability illustrates broader challenges in the WordPress ecosystem. WordPress powers approximately 40% of all websites—hundreds of millions of sites globally. This popularity makes it an attractive target for attackers.
The plugin architecture that makes WordPress flexible also creates security risks. The WordPress plugin directory contains over 60,000 plugins developed by thousands of different authors. Code quality varies dramatically. Some plugins are professionally developed and maintained, while others are side projects by individual developers who may lack security expertise.
Security vulnerabilities in plugins are discovered regularly. Most are reported responsibly and patched quickly, but the window between disclosure and widespread patching creates opportunity for exploitation.
The Developer Perspective
The rapid release of a patch demonstrates responsible vulnerability handling by the plugin developers. They prioritized the security issue and released a fix within 24 hours of notification. This response deserves recognition.
However, the original vulnerability raises questions about security practices during development. The missing capability check represents a basic security error. WordPress documentation clearly explains permission checking, and security best practices emphasize validating user permissions before performing sensitive operations.
This suggests either insufficient security review during development or lack of security expertise by the original developers. Either way, it points to the need for better security practices in plugin development.
For WordPress Plugin Developers
This incident offers lessons for anyone developing WordPress plugins:
Implement Capability Checks: Always verify user permissions before executing sensitive operations. WordPress provides clear functions for this purpose—use them.
Security Reviews: Have security-knowledgeable developers review code before release. Fresh eyes often catch issues original developers miss.
Security Testing: Test plugins with different user permission levels. Verify that low-privilege users cannot access functions intended for administrators.
Follow WordPress Coding Standards: WordPress coding standards include security guidelines. Following them prevents common vulnerabilities.
Participate in Bug Bounty Programs: Bug bounty programs encourage responsible disclosure and help identify vulnerabilities before malicious actors do.
Rapid Response Plans: Have procedures ready for quickly patching and releasing updates when security issues are discovered.
User Communication: Clearly communicate security updates to users. Make it obvious when an update addresses a security issue so administrators prioritize installation.
Looking Forward
The 50,000 sites still running vulnerable versions of this plugin face ongoing risk. As automated exploitation tools emerge, these sites will likely face compromise attempts. Some will be successfully exploited before administrators apply the patch.
This pattern repeats regularly in the WordPress ecosystem. Vulnerabilities are discovered, patches are released, and a significant portion of affected sites remain unpatched for weeks, months, or indefinitely.
Improving this situation requires better mechanisms for ensuring sites apply security updates. WordPress has automatic updates for core software and can enable them for plugins, but many administrators disable this feature fearing updates will break their sites.
The tension between security and stability drives much of the reluctance to update. Administrators worry that updates will cause compatibility issues, break functionality, or create visual problems. These concerns are legitimate—updates do occasionally cause problems.
However, the security risks of remaining unpatched typically outweigh the risks of updating. Sites running vulnerable software face certain exploitation once attackers begin scanning for them. Updates might cause problems, but those problems are usually fixable. A compromised site faces much more serious consequences.
Final Recommendations
If you manage WordPress sites, treat this vulnerability as a call to action—not just for updating this specific plugin, but for reviewing your overall security practices.
Update the Anti-Malware Security and Brute-Force Firewall plugin immediately if you use it. Check your other plugins for available updates and apply them. Review your user management practices and ensure only necessary accounts exist with appropriate permission levels.
Consider this incident a reminder that security requires ongoing attention. WordPress security isn't a one-time configuration—it's an ongoing process of monitoring for threats, applying updates, reviewing access controls, and maintaining awareness of new vulnerabilities affecting the plugins and themes you use.
The half of site administrators who promptly updated after the patch release are now protected. The half who haven't updated yet remain at risk. Which group you're in determines whether your site becomes another statistic in the next round of WordPress compromises or whether you successfully defended against a serious threat.
