Taiga public projects make membership and API scope visible problems
Taiga is a project-management platform with public and private projects, membership roles, integrations, and a REST API. An internet-facing deployment can expose a public project intentionally while still containing private project data, attachments, and integration credentials elsewhere in the same instance.
A count-only ZoomEye query on 2026-11-02 returned 6,944 assets for title="Taiga". The query used sub_type=all, page 1, and page size 1. The title may match product pages or deployments that are not confirmed Taiga instances. The count is an observation of matching assets, not proof of exposure or compromise.
The ZoomEye query is useful for finding candidate hosts. Ownership must be established before any active validation.
Separate public content from public membership
Taiga's production documentation discusses public registration and the effect it can have on external identity-provider buttons. Turning on public registration changes who can create an account and potentially become discoverable by project owners. A public project can be read by a broad audience while editing remains restricted by membership.
Review the instance-wide setting first. Decide whether self-registration is required, whether invitations are the only path, and which external identity providers are allowed. If public registration is enabled, monitor new accounts and membership changes. If it is disabled, confirm that the setting actually applies to every frontend instance and API route.
For each project, record visibility and the role of every member. Check project owners, administrators, developers, and viewers. A public project should not inherit credentials or webhook destinations that grant write access to a private production system. Project templates and imports can copy configuration, so inspect them for secrets and unexpected integrations.
Follow API and integration authority
Taiga exposes a REST API for the same data used by the web application. API clients should use a dedicated account or token with the minimum project membership. Do not rely on obscurity of an endpoint or on the web UI hiding a project. Test whether a member of one project can query another project's metadata, memberships, or attachments.
Integrations add outbound identities. A GitHub, GitLab, Slack, or webhook connection may hold a token or endpoint that can write to another system. Inventory integrations by project, owner, destination, and credential age. Remove integrations that no longer have an owner. Rotate a webhook secret after a project changes ownership.
Review attachments and export paths. A public project may intentionally expose issue text while an attachment bucket or generated archive contains more data. Check object storage permissions separately from Taiga application roles. A signed URL should have a short lifetime and a scope limited to the intended object.
Verify the deployment boundary
For each candidate host, capture the title, certificate, IP address, and first-seen time. Confirm whether it is a production instance, a demo, or an unrelated product page. Compare DNS and certificate names with the organization's known assets. Check for alternate hostnames and old deployments without attempting unauthorized access.
Inspect the login and registration configuration through an authorized account. Confirm that TLS is enforced and that session cookies use appropriate attributes. Review reverse-proxy headers and trusted proxy ranges so a client cannot claim an administrative identity through a forwarded header. Check that static assets and public project pages do not reveal private media.
Keep an audit trail for project creation, visibility changes, membership changes, API token creation, and webhook edits. Alert on changes by an unusual account or outside a change window. Retain the evidence in a system that remains available if the Taiga host is compromised.
Use the scan as a population signal
The 6,944 title matches can help identify where Taiga is deployed, but they cannot tell an operator which project is public for a valid reason. Match candidates to owned domains, then inspect configuration and project policy. A high count should not be reported as a high number of vulnerable systems.
Repeat the query and retain the timestamp. A new owned hostname may indicate a deployment that missed the inventory process. A disappearing host may indicate a migration. Neither event proves a security incident.
The practical control is a project boundary review that combines visibility, membership, API scope, integration credentials, and object-storage permissions. Taiga can present all of those pieces in one instance, so the organization should not assume one visibility switch covers them all.
Top comments (0)