CVE-2026-0909
Insecure Direct Object Reference in WP ULike Plugin Allows Log Deletion
Publication date: 2026-02-03
Last updated on: 2026-02-03
Assigner: Wordfence
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| unknown_vendor | wp_ulike | to 4.8.3.1 (inc) |
| unknown_vendor | wp_ulike | 5.0.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-639 | The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
The vulnerability in the WP ULike WordPress plugin (up to version 4.8.3.1) is an Insecure Direct Object Reference (IDOR). It occurs because the AJAX action `wp_ulike_delete_history_api` does not verify that the log entry a user tries to delete actually belongs to them. As a result, an authenticated attacker with Subscriber-level access or higher (if their role has the 'stats' capability) can delete arbitrary log entries of other users by manipulating the 'id' parameter in the request. [1]
How can this vulnerability impact me? :
This vulnerability allows an attacker with low-level authenticated access to delete engagement log entries belonging to other users. This can lead to loss or tampering of user activity data, potentially affecting audit trails, user statistics, or other plugin-related logs. While it does not allow data disclosure or system compromise, it undermines data integrity and trustworthiness of the plugin's logging features. [1]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring AJAX requests to the WordPress wp-ulike plugin's `wp_ulike_delete_history_api` endpoint. Specifically, look for authenticated requests (from users with Subscriber-level access or higher with 'stats' capability) that include the `id` parameter used to delete log entries. You can detect suspicious activity by checking web server logs or using network monitoring tools to filter for POST or GET requests to `admin-ajax.php` with the action `wp_ajax_wp_ulike_delete_history_api` and unusual or unauthorized deletion attempts. Example commands to detect such requests in Apache logs could be: 1. Using grep to find delete history API calls: `grep "action=wp_ulike_delete_history_api" /var/log/apache2/access.log` 2. Using grep to find requests with an `id` parameter: `grep "action=wp_ulike_delete_history_api" /var/log/apache2/access.log | grep "id="` 3. Using a tool like tcpdump to capture HTTP traffic and filter for these requests: `tcpdump -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' | grep 'wp_ulike_delete_history_api'` Additionally, review WordPress user roles and capabilities to identify if any Subscriber-level users have the 'stats' capability assigned, which could enable exploitation. Note: The plugin version affected is up to 4.8.3.1, so verifying the plugin version installed is also important. [1]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include: 1. Upgrade the wp-ulike plugin to a version later than 4.8.3.1 where this vulnerability is fixed, or apply any official patches provided by the plugin maintainers. 2. Restrict the 'stats' capability so that it is not assigned to Subscriber-level users or any untrusted roles, limiting the ability to call the vulnerable AJAX delete API. 3. If upgrading immediately is not possible, consider temporarily disabling or restricting access to the `wp_ulike_delete_history_api` AJAX action by modifying plugin code or using security plugins to block such requests. 4. Review and tighten user role permissions in WordPress to ensure only trusted users have capabilities that allow deletion of engagement logs. 5. Monitor logs for suspicious deletion attempts as a detection measure while mitigation is in place. 6. Implement Web Application Firewall (WAF) rules to block unauthorized AJAX requests targeting this endpoint. These steps reduce the risk of exploitation by limiting who can perform deletions and by removing or restricting the vulnerable functionality. [1, 4]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided resources and context do not explicitly discuss the impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA. However, since the vulnerability allows authenticated users with certain capabilities to delete arbitrary log entries belonging to other users, it could potentially affect data integrity and audit trails, which are important for compliance. Without explicit information, a definitive assessment cannot be made.