CVE-2026-65055: Taiga Information Disclosure Vulnerability

CVE-2026-65055 Overview

CVE-2026-65055 is a missing authorization vulnerability [CWE-862] in Taiga 6.10.1, an open source project management platform. Unauthenticated attackers can 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 the UserStory, Task, Issue, and Epic viewsets. The affected endpoints fail to enforce the access controls that correctly restrict other project API endpoints. Attackers enumerate sequential integer project IDs to harvest user IDs, full names, and gravatar hashes from private projects.

Critical Impact
Unauthenticated remote attackers can enumerate private project membership and workflow metadata across an entire Taiga deployment without credentials.

Affected Products

Taiga (taiga-back) 6.10.1
filters_data endpoint on the UserStory viewset
filters_data endpoint on the Task, Issue, and Epic viewsets

Discovery Timeline

2026-07-21 - CVE-2026-65055 published to NVD
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-65055

Vulnerability Analysis

Taiga exposes filters_data endpoints on multiple viewsets to power the frontend filtering UI for user stories, tasks, issues, and epics. These endpoints accept a project query parameter containing an integer project ID. The handlers query and return aggregated filter metadata for the referenced project, including the list of members assigned to work items along with their user IDs, full names, and gravatar hashes.

Other project-scoped endpoints in Taiga correctly evaluate the requesting user's membership and the project's public or private status before returning data. The filters_data handlers omit that permission check. A request without any authentication token receives the same response as an authenticated project member. This exposes private project rosters and workflow configuration that would otherwise be restricted.

Root Cause

The root cause is a missing authorization check on the filters_data action within the affected Django REST Framework viewsets. The permission classes applied to the standard list and retrieve actions are not enforced on the custom filters_data action, leaving it accessible to anonymous callers.

Attack Vector

The attack requires only network access to the Taiga API. An attacker iterates project IDs from 1 upward and issues an unauthenticated GET request to each filters_data endpoint. Every private project that exists in the database returns member and workflow data. The vulnerability requires no user interaction and no privileges. See the VulnCheck Advisory on Taiga Back for full technical details.

Detection Methods for CVE-2026-65055

Indicators of Compromise

Unauthenticated GET requests to /api/v1/userstories/filters_data, /api/v1/tasks/filters_data, /api/v1/issues/filters_data, or /api/v1/epics/filters_data.
Sequential enumeration patterns where the project query parameter increments across many integer values from a single source IP.
High request volume to filters_data endpoints without a preceding authentication call or Authorization header.

Detection Strategies

Alert on any HTTP 200 response from filters_data endpoints where the request lacks an Authorization header or valid session cookie.
Correlate access logs to identify single clients touching filters_data for many distinct project IDs within a short time window.
Compare response body sizes; successful roster disclosure returns member arrays that are larger than empty filter responses.

Monitoring Recommendations

Ingest Taiga web server and application logs into a centralized analytics platform and retain them for enumeration pattern analysis.
Add a WAF or reverse proxy rule to log and rate-limit anonymous access to /api/v1/*/filters_data paths.
Track outbound traffic from the Taiga host and alert on anomalous data volumes tied to API endpoints.

How to Mitigate CVE-2026-65055

Immediate Actions Required

Restrict network access to the Taiga API to authenticated users where feasible, using a reverse proxy or VPN in front of the application.
Block unauthenticated requests to /api/v1/userstories/filters_data, /api/v1/tasks/filters_data, /api/v1/issues/filters_data, and /api/v1/epics/filters_data at the WAF or load balancer.
Audit access logs for prior enumeration and rotate any information exposed on private projects that must remain confidential.

Patch Information

Monitor the GitHub Taiga Back Repository and GitHub Issue #246 for a fix. The remediation must apply the same project membership and visibility checks used on the standard list and retrieve actions to the filters_data action across the UserStory, Task, Issue, and Epic viewsets.

Workarounds

Deploy a reverse proxy rule that rejects requests to filters_data endpoints when no session cookie or Authorization header is present.
Place the Taiga instance behind SSO or network-level authentication until an upstream patch is available.
Rate-limit anonymous requests to Taiga API endpoints to slow enumeration of sequential project IDs.

bash

# Example nginx snippet to block unauthenticated filters_data access
location ~ ^/api/v1/(userstories|tasks|issues|epics)/filters_data {
    if ($http_authorization = "") { return 401; }
    proxy_pass http://taiga_back;
}