TestLink body matches outnumber title matches, and that gap changes the inventory

TestLink is a long-running test-management system. Its web interface holds test projects, test plans, requirements, builds, executions, and user roles. A public login page can therefore sit in front of project names, defect references, release schedules, test evidence, and API keys that connect the system to other engineering tools.

A count-only ZoomEye query for title="TestLink" found 1,245 matching records on 2026-11-10 at 00:51 UTC. The same normalized scope with app="TestLink" returned zero, while http.body="TestLink" returned 10,647. Those numbers describe different matching surfaces. The body count is a broad text signal and should not be presented as a count of confirmed TestLink deployments.

The title count is the more useful discovery baseline for this review. It shows a reachable population that can be checked for authentication, role assignment, API access, and exposed installation paths. It does not prove that any instance is vulnerable. View the title measurement in ZoomEye. The query used page 1, page size 1, and sub_type=all; the reported total is the matched record count.

Why a test system holds sensitive context

TestLink's role model is organized around test projects and test plans. The available roles include administrator, test designer, tester, senior tester, and guest, with different rights in the project and plan context. The project assignment is part of the authorization decision, not only a label in the interface.

That model creates a useful review question. Which users can see a project, which roles can change its test cases, and which accounts can execute tests or attach evidence? An exposed TestLink title may reveal only a login page, but a weak account can reveal the release process and the internal systems named in test cases.

TestLink also exposes an API for automation. The user guide and source describe a user-specific developer key. The repository's configuration notes whether users can generate API keys, and the API implementation checks rights when a request targets a test project and test plan. API access should be reviewed as another role-bearing interface, not as a read-only convenience.

A practical inventory

Start with the title result and confirm the product in a small, authorized sample. Do not use the body count as if every match were an installation. Record the title, hostname, path, visible version or login marker, and date of observation without collecting credentials.

For each discovered or internally owned instance, check whether anonymous access is disabled, whether default or shared accounts remain, and whether user registration or guest access is enabled. Review project roles for dormant users and service accounts. Then review API-key generation and the set of users who can call project or test-plan operations.

Test the API with an account that has a narrow project role. Try the same operation on a project where the account has no assignment. The expected result is a denial. If the API performs the operation, the role model in the user interface is not the effective authorization boundary.

What ZoomEye can and cannot show

ZoomEye is useful for finding title and body markers at internet scale and for comparing a current result with an earlier query. It is not an authenticated scanner, a vulnerability detector, or a substitute for asset ownership. A matching host may be a demo, a staging system, a honeypot, a stale page, or a product-like application with no live test data.

The zero application fingerprint is also informative. It means the tested app value did not produce a match under that query, not that the product is absent. A different fingerprint value or a new index may change the result. The body count is broader still and may include documentation, job listings, and pages that mention the product.

Use the difference to choose the next query. If the title is the product's default login, keep that as the primary discovery signal. If an organization deploys a custom title, test a body marker that is specific to the product and record the false-positive risk. Preserve the exact query and collection time so another analyst can reproduce the result.

Ownership and exposure decisions

A TestLink instance should have an owner, an environment label, a network zone, and a decision about whether it belongs on the public internet. Test-management data often describes unreleased products. The project role and API rights should match the people and automation that need them.

Walk through the account lifecycle. Remove accounts for former staff, review contractor access, and verify that a disabled project does not remain reachable through an API key. Record who can administer roles and who can create a new project. Treat the ability to assign a project role as a privileged operation.

Finally, compare the external count with the internal inventory. The value of the ZoomEye result is not the number itself. It is the list of questions a team would not otherwise ask: Do we know why this test system answers on the internet, who owns its data, and which role grants can turn a login page into release intelligence?

References

• TestLink project repository
• TestLink API implementation
• TestLink configuration example
• ZoomEye title measurement for TestLink

Measurement metadata: 2026-11-10 00:51 UTC, sub_type=all, page 1, pagesize 1; title 1,245, app 0, body 10,647. The body query is a broad text marker and is not used as a confirmed product count.