CVE-2026-65055 in taiga-back
Summary
by MITRE • 07/22/2026
Taiga 6.10.1 contains a missing authorization vulnerability that allows unauthenticated attackers to disclose the full member roster and internal workflow configuration of any private project by supplying a project ID to the filters_data API endpoints on UserStory, Task, Issue, and Epic viewsets. Attackers can send unauthenticated GET requests to the filters_data endpoints with sequential integer project IDs to enumerate private project membership details including user IDs, full names, and gravatar hashes, bypassing the access controls that correctly restrict other project API endpoints.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/22/2026
This vulnerability resides in Taiga version 6.10.1 where a critical missing authorization flaw exists within the API endpoint structure, specifically affecting the filters_data functionality across UserStory, Task, Issue, and Epic viewsets. The core technical issue manifests as an insufficient access control mechanism that fails to validate authentication status when processing requests to these particular endpoints, allowing unauthorized parties to bypass normal security boundaries that would typically restrict access to private project information.
The operational impact of this vulnerability extends beyond simple data exposure as attackers can systematically enumerate private project membership details through sequential integer project ID enumeration. This methodical approach enables threat actors to discover complete member rosters including user identifiers, full names, and gravatar hash values without requiring any valid authentication credentials or authorization tokens. The vulnerability affects the fundamental security model of the platform by creating a backdoor access path that circumvents the standard access control checks implemented for other API endpoints within the same system.
The technical exploitation mechanism relies on the predictable nature of project ID assignment where attackers can iterate through integer values to discover valid project identifiers and subsequently extract sensitive information from private projects. This enumeration capability represents a significant deviation from expected security behavior since legitimate access controls properly restrict other project API endpoints while leaving these specific filters_data endpoints unprotected, creating an asymmetric vulnerability landscape within the same software system.
This vulnerability aligns with CWE-284 which specifically addresses inadequate access control mechanisms and can be categorized under ATT&CK technique T1078 for valid accounts and T1566 for credential harvesting through reconnaissance activities. The flaw demonstrates a classic case of privilege escalation through unauthorized data access where unauthenticated users gain access to information that should remain restricted to authorized project members only.
Organizations utilizing Taiga 6.10.1 should immediately implement mitigation strategies including immediate patching to address the authorization gap, implementing additional rate limiting controls on API endpoints, and conducting comprehensive access control reviews to identify similar vulnerabilities within other parts of the system. The recommended remediation involves strengthening authentication requirements for filters_data endpoints while ensuring consistent access control enforcement across all API interfaces to prevent similar issues from emerging in future releases or configurations.
The broader implications suggest that this vulnerability may indicate deeper architectural weaknesses in how authorization controls are implemented and enforced throughout the Taiga platform, potentially exposing other sensitive data points beyond the immediate scope of member roster disclosure. Security teams should perform thorough audits of API endpoint access controls and consider implementing comprehensive logging mechanisms to detect unauthorized access attempts to sensitive project information.
Organizations should also implement network-level controls including firewall rules that restrict access to these specific API endpoints from untrusted networks, while simultaneously establishing monitoring procedures to detect unusual patterns of project ID enumeration that may indicate active exploitation attempts. The vulnerability highlights the importance of principle of least privilege implementation where even read operations on sensitive data require proper authentication and authorization validation.
This particular flaw represents a significant risk to organizations relying on Taiga for project management and collaboration, as the exposure of member rosters can facilitate social engineering attacks and provide attackers with valuable information for targeting specific individuals within project teams. The combination of user identification details and gravatar hashes creates a comprehensive profile that could be leveraged for various malicious activities including targeted phishing campaigns or credential stuffing attacks against users who may share common email addresses across multiple systems.