CVE-2026-59097: Taiga 6.10.2 Missing Authorization – Unauthenticated Due-Date Record Creation

Technical summary

The vulnerability stems from missing authorization checks on POST endpoints in Taiga's user-story, task, and issue due-date API viewsets. These endpoints inherit or explicitly apply the AllowAny permission class, which bypasses authentication and permission validation. An unauthenticated attacker can craft HTTP POST requests to these endpoints, supplying an arbitrary project identifier as a parameter, and successfully create due-date records without any credentials or project membership. The CWE-862 classification (missing authorization) reflects the absence of proper access control logic before resource creation. The CVSS 3.1 score of 5.3 (MEDIUM) reflects low complexity exploitation over the network with no user interaction required, but limited impact scope (integrity only, no confidentiality or availability loss).

Business impact

While the confidentiality and availability of the system remain intact, the integrity impact can create meaningful friction in project workflows. Attackers can pollute the due-date registry before administrators configure legitimate defaults, forcing cleanup work and eroding trust in data consistency. In multi-tenant or SaaS environments hosting Taiga, a single attacker can impact many projects across different customers, creating a support burden and reputational risk. The ability to mass-create nonsensical due dates across dozens of projects simultaneously could also serve as a harassment or denial-of-service vector in organizational contexts.

Affected systems

Taiga versions prior to 6.10.2 are vulnerable. The specific endpoints at risk are those handling due-date creation for user stories, tasks, and issues. Self-hosted Taiga installations and any SaaS or cloud deployment running the affected version range are in scope. The vulnerability requires network access to the Taiga API but does not require any special network positioning or authentication token.

Exploitability

Exploitability is straightforward and low-friction. An attacker needs only to identify or guess a valid project ID and send a properly formatted POST request to a known API endpoint. No authentication is required, no user interaction is needed, and the attack can be automated and scaled rapidly across multiple projects. The attack surface is broad—any instance with the API accessible over HTTP(S) is vulnerable. However, practical impact depends on whether the attacker's goal is disruption or reconnaissance; many organizations may not immediately notice spurious due-date records if monitoring is lax.

Remediation

Upgrade Taiga to version 6.10.2 or later, which restores proper authorization checks to the affected API endpoints. The patch restricts due-date creation to authenticated users with appropriate project permissions. For organizations unable to upgrade immediately, restrict network access to Taiga API endpoints using a firewall or reverse proxy, and monitor POST requests to due-date endpoints for suspicious patterns. Review and audit existing due-date records to identify any unauthorized entries and remove them.

Patch guidance

Verify that your Taiga instance is running version 6.10.2 or later by checking the version in the admin dashboard or the release notes. If you are on an earlier version, follow the official Taiga upgrade documentation for your deployment method (Docker, pip, or source installation). After patching, restart all Taiga services and conduct a brief functional test of due-date creation to ensure the authorization layer is working as expected. Keep Taiga and its dependencies up to date with the latest security releases.

Detection guidance

Monitor API logs for POST requests to endpoints matching patterns like /api/v1/user-stories/*/due-dates, /api/v1/tasks/*/due-dates, or /api/v1/issues/*/due-dates originating from unauthenticated sources or non-standard user agents. Alert on bulk or rapid-fire requests to these endpoints. Review due-date records in your projects for entries created by unknown or system accounts, especially those with unexpected or nonsensical dates. Implement request rate limiting on these endpoints to slow mass-creation attacks. Enable and audit authentication and authorization logs to identify gaps in coverage.

Why prioritize this

Although the CVSS score is MEDIUM, this vulnerability deserves prompt attention because (1) it requires zero authentication and zero user interaction, making it trivial to exploit at scale, (2) it affects data integrity in a way that could undermine operational trust, (3) in multi-tenant environments it can be used to harass or disrupt many projects simultaneously, and (4) the fix is simple and non-breaking. Organizations relying on Taiga for mission-critical project planning should prioritize patching to prevent supply-chain or workflow sabotage.

Risk score, explained

The CVSS 3.1 score of 5.3 (MEDIUM) reflects a network-accessible vulnerability with no authentication or user interaction barriers (AV:N, AC:L, PR:N, UI:N), but the impact is constrained to integrity without touching confidentiality or availability (I:L, C:N, A:N). The scope is unchanged (S:U), meaning the vulnerability does not breach isolation boundaries. While the technical severity is not critical, the ease of exploitation and potential for coordinated abuse across projects warrants treating this as higher priority than the base score alone suggests. Organizations should not delay patching based on the MEDIUM rating.

Frequently asked questions