Taiga public projects make membership and API scope visible problems

Taiga is a project management platform that offers both public and private projects, with various membership roles and integrations, including a REST API. However, the platform's design can lead to visibility and scope problems, particularly when public projects are exposed alongside private data. A ZoomEye query conducted on November 2, 2026, identified 6,944 assets matching the title "Taiga," indicating potential instances of the software.

While the query does not confirm exposure or compromise, it serves as a useful tool for identifying candidate hosts.

To address these issues, Taiga's production documentation recommends separating public content from public membership. When public registration is enabled, external identity providers should be carefully managed, and new accounts and membership changes should be monitored. Conversely, if public registration is disabled, it must be confirmed that the setting applies to all frontend instances and API routes.

Each project should have its visibility and member roles recorded and reviewed, ensuring that project owners, administrators, developers, and viewers are appropriately managed. Public projects should not inherit credentials or webhook destinations that grant write access to private production systems.

When using Taiga's REST API, clients should use dedicated accounts or tokens with the minimum necessary membership. API and integration authority should be carefully managed to prevent unauthorized access to other systems. Integrations, such as those with GitHub, GitLab, Slack, or webhooks, should be inventoried by project, owner, destination, and credential age.

Stale integrations should be removed, and webhook secrets should be rotated after changes in project ownership. Additionally, attachments and export paths should be reviewed, as a public project may expose issue text while an attachment bucket or generated archive contains more sensitive data.

Finally, a comprehensive review of the deployment boundary is essential. For each candidate host, details such as the title, certificate, IP address, and first-seen time should be captured. The host's classification as production, demo, or an unrelated product page should be confirmed through DNS and certificate names. Alternate hostnames and old deployments should be checked without attempting unauthorized access.

Reverse-proxy headers and trusted proxy ranges should be inspected to prevent clients from claiming administrative identities. All changes related to project creation, visibility changes, membership changes, API token creation, and webhook edits should be audited, with alerts set for unusual accounts or changes outside designated windows.

Evidence should be retained in a system that remains available even if the Taiga host is compromised. Finally, the scan results should be used as a population signal to identify deployed Taiga instances, but any high count should not automatically indicate vulnerable systems.