Tracim's 24 title matches are a small set of collaboration-space permission checks
Collaboration tools combine documents, threads, files, tasks, comments, and user roles in shared spaces. The public surface may be small while the internal object graph is large. Tracim documents shared workspaces, role-based access control, REST APIs, and several authentication integrations.
The ZoomEye observations used sub_type=all, page 1, and pagesize 1. On 2026-11-02, app="Tracim" returned 0 and title="Tracim" returned 24. Both probes succeeded. The zero is an application-fingerprint miss. The title count is a candidate set, not a vulnerability count.
Spaces carry the access model
Tracim's API describes workspaces, user roles, allowed spaces, content revisions, and agenda authentication. Its configuration sample includes internal, LDAP, and SAML authentication settings, along with token lifetimes and default user profiles.
The security decision sits at the junction of those settings. An internal user may be assigned to a workspace with a role. An LDAP or OIDC identity may be created on first login and inherit a default profile. A WebDAV or calendar client may use a token whose validity differs from the browser session.
An administrator reviewing exposure should ask which identity source created each account, which workspace role it holds, and which token type can carry the session. A user removed from the identity provider should not retain an API token or calendar token that still reaches a private workspace.
Do not infer content exposure from a title
A title result can be a public collaboration site, a login page, a project page, or documentation. It does not show the content of a workspace or whether a visitor can authenticate.
Use safe metadata checks to identify the host and redirect behavior. Do not attempt to enumerate users, workspaces, files, or calendars. If the deployment is authorized for testing, verify that an unauthenticated request to a workspace endpoint fails consistently and does not return file metadata.
For authenticated review, test role transitions inside a non-production or explicitly authorized space. Confirm that removing a user from a space takes effect across the web interface, REST API, WebDAV, and calendar paths. Check that a token-validity setting does not extend access beyond the account's current role.
Review the authentication path
The configuration sample exposes internal authentication and several external providers. Each provider creates a trust relationship and a provisioning path. Confirm that the SAML or OIDC issuer matches the intended identity provider, that the default profile is not administrative, and that user attributes do not collide.
Review CORS origins, base URLs, and redirect settings as part of the same identity boundary. A token intended for a web calendar can be long lived. Keep its scope narrow and make revocation possible without resetting the user's primary password.
The 24-title count is small enough for a focused owner review. Confirm each deployment, its version, its identity source, and its workspace roles. The important question is whether one authenticated identity can cross a space boundary through a secondary protocol. A small observed population does not make that question less relevant.
Top comments (0)