Tuleap supports project management, issue trackers, source repositories, documentation, and continuous integration. An exposed Tuleap instance is therefore a collection of project boundaries. The important question is not simply whether the login page is visible. It is which project data anonymous users, registered users, project members, and delegated groups can reach.
A count-only ZoomEye query on 2026-11-02 returned 706 assets for title="Tuleap". The query used sub_type=all, page 1, and page size 1. A title fingerprint may include documentation pages, mirrors, and deployments that are not the same service version. The result is a matching-asset count, not a confirmed vulnerability count.
The ZoomEye query helps locate the population. Ownership evidence should come from DNS, certificates, cloud accounts, and deployment records before an analyst tests a host.
Start with project visibility
Tuleap documents project visibility and a permission model that combines platform configuration with project-level rules. Registered users may have access to projects unless project administrators restrict them. That default makes the distinction between authentication and authorization important. A user who can sign in is not necessarily a member of every project, and a project that is private still needs feature-level review.
Tuleap project groups can receive permissions for individual services and actions. The documentation describes per-feature permissions and user groups. Review the groups that can access Git repositories, trackers, documentation, files, and project administration. Check whether a group includes all registered users or an external identity-provider group with broader membership than intended.
The project administrator role deserves special attention. A user who can change visibility or delegate permissions can change the exposure of the whole project. The documentation describes a safety rule intended to prevent removal of the last platform-administration group. Keep analogous ownership controls for each project and avoid a single unmonitored break-glass account.
Review API and token paths
Tuleap exposes REST API access and supports OAuth2 access tokens. A token can make calls that the underlying account may not clearly see in the web interface. Inventory OAuth applications, personal access keys, and service identities. Record their owner, purpose, project scope, and creation time where available.
Test an API client with a project role that should be read-only. Confirm that it cannot create artifacts, change project visibility, or read an unrelated project. Check the error path as well as the success path. A response that reveals project names or artifact metadata can still be useful to an attacker even when the write action is denied.
Do not place a broad API token in a public client-side application. If a tracker integration needs to submit artifacts, use a service identity limited to the relevant project and tracker. Rotate the token after a project transfer or ownership change.
Inventory the public service surface
For each observed host, record the Tuleap title, certificate, address, first-seen time, and organization. Determine whether the host is a production service, a demo, a mirror, or a stale deployment. Check for exposed installation or administration pages without attempting unauthorized actions. A public documentation host may share a product title without exposing project data.
Review DNS history and certificate transparency for related hostnames. A project portal may be protected while an old API hostname, CI runner, or artifact endpoint remains reachable. Compare the public surface with the ingress configuration and the service's own configured external URL. Redirects can hide multiple vhosts behind one certificate.
Within Tuleap, retain authentication and permission-change logs. Alert on new project visibility, new external OAuth clients, group membership changes, and the creation of access keys. Correlate those events with the identity provider and a change ticket. If a project becomes private, verify that cached artifacts and API sessions no longer expose its data.
Turn the scan into a project review
Use the ZoomEye result to prioritize organizations that have a known Tuleap deployment. Then review one project at a time: visibility, members, groups, tracker permissions, repository access, documentation, and API clients. Record the owner and the expected audience for each project.
A title match is weak identity evidence by itself. Confirmation should combine a product-specific page, certificate ownership, DNS control, or an authenticated administrative record. That distinction prevents a large scan count from being reported as a confirmed exposure count.
The useful outcome is a repeatable inventory that shows where project boundaries are configured, who can change them, and how quickly a visibility mistake is detected. Tuleap's permission model can express those boundaries. The organization still needs to observe that the deployed configuration matches the intended one.