Leantime provides project planning, task management, timesheets, and an API. Its access model includes users, roles, projects, and API keys. A deployment found on the internet may therefore expose more than a login form. It may expose service-account credentials that can read or change project data.
A count-only ZoomEye query on 2026-11-02 returned 960 assets for app="Leantime". The query used sub_type=all, page 1, and page size 1. The app fingerprint gives a more product-specific candidate set than a generic title, but it still does not prove that every result is an active, reachable Leantime instance.
The ZoomEye query is a lead for an owned asset review. Confirm the host with DNS, certificate, and deployment records before testing.
Treat API keys as service identities
Leantime's API documentation describes creating an API key under company settings. The key can have roles and projects assigned, which limits its scope. The documentation also describes API keys as service accounts rather than credentials tied to a single human user. That distinction affects ownership, rotation, and audit.
Inventory every API key by name, owner or purpose, assigned role, assigned projects, creation time, and last use where available. Remove keys that were created for experiments and never retired. A key used by a reporting integration should not be able to edit tickets in unrelated projects. A key used by an automation account should have a named owner even if it is not tied to a human login.
Review company settings access. The person who can create or manage API keys can create a durable service identity. Use an administrative role with strong authentication and a controlled invitation path. Alert on key creation, role changes, and project scope changes.
Review the project boundary
Leantime roles and project assignments should be checked from the perspective of the API, not only the dashboard. A user or key that can read a project through the web interface may also be able to query its tickets, comments, files, users, and timesheets through the API. Test the allowed endpoints with a low-privilege service account and confirm the expected denials.
The configuration documentation covers database, file storage, authentication, email, themes, and system settings. For a self-hosted deployment, review the storage and session configuration as security controls. Confirm that the application secret and database credentials are not stored in a public container image. Check that an external identity provider maps groups to the intended roles rather than granting an administrator role to every new account.
Files and exports need separate attention. A project member may be allowed to view tickets but not every uploaded file. Check the storage backend and object permissions. A private project with a public attachment bucket is effectively public for the exposed files. Test a signed download and verify that its lifetime is short.
Inventory the deployment
For each observed Leantime host, record the hostname, certificate, address, product evidence, organization, and first-seen time. Determine whether the result is an official demo, a documentation site, or a production deployment. A login page or a product name in HTML is not enough to claim ownership.
Check whether the deployment exposes setup or diagnostic paths. An installation wizard that remains available after setup can become an administrative path. Review reverse-proxy rules, trusted proxy headers, and TLS termination. Ensure the application sees the correct client address for rate limiting and audit logs.
Use the ZoomEye result to find new hosts associated with owned domains and to compare changes over time. Do not treat a new app match as a compromised instance. Preserve the exact query, time, scope, and result. The count is useful for inventory and prioritization, not for a vulnerability claim.
Design a containment path
If a key is exposed, revoke it in Leantime and check the integration that used it. Rotate any downstream credential the key could reach. Review project activity during the period the key was valid, including ticket changes, comments, file downloads, and user management. If the key could create another API key, inspect for persistence before returning the service to normal.
Leantime can be a useful collaboration system, and its API makes automation convenient. The same API makes key governance important. Keep service accounts few, scoped, owned, and observable. That gives the organization a way to distinguish an expected integration from an unmanaged path into project data.