CVE-2026-1070
Cross-Site Request Forgery in Alex User Counter Plugin Allows Settings Modification
Publication date: 2026-01-24
Last updated on: 2026-01-24
Assigner: Wordfence
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| alex_user_counter | alex_user_counter | to 6.0 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-352 | The web application does not, or cannot, sufficiently verify whether a request was intentionally provided by the user who sent the request, which could have originated from an unauthorized actor. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
The vulnerability in the Alex User Counter WordPress plugin (up to version 6.0) is a Cross-Site Request Forgery (CSRF) issue caused by missing nonce validation in the alex_user_counter_function(). This allows unauthenticated attackers to trick a site administrator into performing actions like updating plugin settings via a forged request. Additionally, the plugin lacks sanitization of user input on its settings page and includes an external HTTP script, which may lead to cross-site scripting (XSS) and insecure data transmission. [1, 2]
How can this vulnerability impact me? :
This vulnerability can allow attackers to change plugin settings without authorization by tricking an administrator into clicking a malicious link (CSRF). The lack of input sanitization can lead to stored cross-site scripting (XSS) attacks, potentially compromising site security. Also, the inclusion of an external script over HTTP can expose site information and data to man-in-the-middle attacks, risking privacy and security. [1, 2]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
You can detect this vulnerability by checking if the Alex User Counter plugin version 6.0 is installed and active on your WordPress site. Additionally, look for the presence of the admin settings page "User Counter Settings" that allows updating the user count display text without nonce validation. To detect potential exploitation attempts, monitor HTTP POST requests to the plugin's settings page that update the option 'alex_user_counter_settings' without nonce tokens. On the server, you can search for the plugin files, for example: `grep -r alex_user_counter_function /path/to/wordpress/wp-content/plugins/user-counter/` to confirm the vulnerable function is present. Also, check for outgoing HTTP requests to `http://mrstats.strangebutfunny.net/statsscript.php` from the admin area, which indicates the plugin's external script inclusion. Network monitoring tools can be used to detect such outbound requests. There are no specific commands provided in the resources, but these steps can help identify the vulnerability and its exploitation. [1, 2]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include: 1) Disable or uninstall the Alex User Counter plugin until a patched version is available. 2) Restrict access to the WordPress admin area to trusted users only to reduce risk of CSRF attacks. 3) Monitor and block outgoing HTTP requests to `http://mrstats.strangebutfunny.net/statsscript.php` to prevent data leakage. 4) If you must keep the plugin active, implement manual nonce validation and sanitize inputs on the settings page to prevent CSRF and XSS attacks. 5) Keep WordPress and all plugins updated to the latest versions once a fix is released. These steps reduce the risk of unauthorized settings changes and data exposure caused by the vulnerability. [1, 2]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in the Alex User Counter plugin allows unauthenticated attackers to perform Cross-Site Request Forgery (CSRF) attacks that can update plugin settings without proper nonce validation. Additionally, the plugin includes an external HTTP script that sends the site's host information to a third-party server, potentially exposing site data externally. These issues could lead to unauthorized changes and data exposure, which may negatively impact compliance with data protection regulations such as GDPR and HIPAA by risking unauthorized access and disclosure of site information. However, no explicit mention of compliance impact is provided. [1, 2]