CVE-2026-104991 in Phproject
Summary
by MITRE • 10/02/2026
Phproject before 1.8.7 contains a missing object-level authorization vulnerability in the REST API issue endpoints (single_get, single_comments, single_comments_post) that allows authenticated API key holders to bypass the security.restrict_access confidentiality control by never invoking the allowAccess() authorization routine. Attackers can use a valid API key to read restricted issue contents and comments, including owner and author email addresses, and post unauthorized comments to issues they should not have access to.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in Phproject versions prior to 1.8.7 represents a critical failure in object-level authorization within the application's REST API architecture. Specifically, this flaw affects endpoints responsible for retrieving single issue details, fetching existing comments on an issue, and posting new comments to an issue. The core technical deficiency lies in the absence of proper access control checks during these operations. While the application implements a security.restrict_access configuration designed to enforce confidentiality controls based on user roles or project membership, this mechanism is effectively bypassed because the underlying code does not invoke the allowAccess() authorization routine for these specific API endpoints. This omission means that the system fails to verify whether the authenticated entity requesting data actually possesses the necessary permissions associated with the specific resource being accessed.
From a technical perspective, this vulnerability classifies as CWE-284 Improper Access Control and more specifically aligns with CWE-639 Authorization Bypass Through User-Controlled Key Identifier if the API key itself is manipulated to infer access rights, though in this case it is primarily an authorization logic flaw where the check is simply missing. The impact of this vulnerability is significant for organizations relying on Phproject for sensitive project management tasks. An attacker possessing a valid API key can exploit this gap to read restricted issue contents and comments that should be hidden from them based on their role or membership status. This includes accessing personally identifiable information such as the email addresses of owners and authors, which constitutes a privacy breach and potentially aids in further social engineering attacks. Furthermore, the ability to post unauthorized comments allows an attacker to inject malicious content, spam, or misleading instructions into issues they do not have legitimate access to, thereby compromising data integrity and operational trust within the project workflow.
The exploitation of this vulnerability requires only that the attacker holds a valid API key for any user account with at least minimal read permissions on some part of the system. The attack does not require privilege escalation or authentication bypass beyond possessing a standard credential set. Once authenticated, the attacker can systematically enumerate issues and extract sensitive data by crafting HTTP requests to the affected endpoints without triggering any denial responses related to access rights. This lack of enforcement creates a silent failure where unauthorized actions appear successful from the API's perspective because no error is returned for missing permissions, only potentially incorrect or overly broad data retrieval results depending on how the database queries are structured internally.
Mitigation strategies must focus on immediate patching and architectural review. The primary remediation is to upgrade Phproject to version 1.8.7 or later where this authorization logic has been corrected to ensure that all API endpoints properly invoke access control checks before processing requests. In environments where upgrading is not immediately feasible, temporary mitigations should include restricting network-level access to the REST API endpoints using firewall rules or reverse proxy configurations to limit exposure only to trusted IP addresses and services. Additionally, implementing strict input validation and logging mechanisms can help detect anomalous patterns of data retrieval that may indicate exploitation attempts. Security teams should also audit other API endpoints for similar omissions in authorization logic to prevent lateral movement through the application's interface. This incident underscores the importance of adhering to defense-in-depth principles where every access point must explicitly verify permissions against the specific resource being accessed, rather than relying on implicit trust or incomplete security configurations.