Description

The Project Manager WordPress plugin before 4.0.7 does not check that the user whose activity is being requested is the one making the request in one of its REST API routes, allowing any authenticated user, such as a subscriber, to read any other user's activity history along with their email address and the details of projects they have no access to.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-08-26T06:16:27.133Z",
  "pubdate": "2026-08-26T06:16:27.133Z",
  "executiveSummary": "The Project Manager WordPress plugin, in versions prior to 4.0.7, contains an Insecure Direct Object Reference (IDOR) vulnerability within its REST API endpoints. This security flaw stems from a lack of proper authorization checks, failing to verify that the requesting user has the appropriate permissions to access the requested resource.\nAny authenticated user, including those with minimal privileges such as subscribers, can exploit this vulnerability to perform unauthorized data extraction. By manipulating REST API requests, attackers can retrieve sensitive information, including the activity logs, email addresses, and private project details of other users within the system.\nThis vulnerability exposes the system to unauthorized information disclosure, potentially compromising user privacy and revealing internal project configurations. The flaw resides in the server-side access control logic, which erroneously assumes that authentication is sufficient for authorization. The risk to the confidentiality of organizational data is high, as the vulnerability does not require administrative privileges to execute and can be leveraged by any registered user on the WordPress installation.",
  "technicalDetails": "The root cause of this vulnerability is a failure in the plugin's REST API implementation to enforce object-level access control. Specifically, the affected REST API routes responsible for fetching user activity history fail to validate the identity of the requester against the target user identifier provided in the request parameters.\nIn a secure implementation, the application should confirm that the 'current_user_id' matches the requested user profile ID or that the 'current_user' possesses sufficient administrative permissions to view the target user's metadata. In this case, the controller logic processes the request based solely on the presence of a valid authentication token, neglecting the authorization requirement.\nAn attacker can exploit this by intercepting or manually crafting HTTP GET requests directed at the vulnerable REST API endpoints. By systematically iterating through user IDs or requesting specific target identifiers, an attacker can bypass the intended access restrictions. The server-side API handler processes these requests and returns sensitive JSON-formatted data, which may include the target user's email address, project participation records, and granular activity history, even if those projects are marked as private or restricted.\nThe attack flow is as follows: 1. The attacker authenticates as a standard user (e.g., subscriber role). 2. The attacker identifies the target REST API endpoint responsible for fetching user activity. 3. The attacker submits a crafted request, replacing the target parameter with the ID of another user, administrative account, or project owner. 4. The vulnerable endpoint, failing to perform a capability check or ownership validation, executes a database query to retrieve the sensitive data. 5. The application returns the private information to the attacker's session.\nThis flaw is persistent across all versions of the Project Manager plugin prior to 4.0.7. The exposure is high as it resides on the web server and is reachable over standard HTTP/HTTPS protocols. Because the vulnerability exists within the application layer's API logic, it effectively bypasses traditional perimeter defenses that are not inspecting the authorization logic of individual REST routes.\nThe post-exploitation impact includes the mass scraping of user emails, the unauthorized mapping of private project structures, and the potential for further reconnaissance that could lead to privilege escalation or targeted social engineering attacks against high-value users."
}