ProjeQtOr is a project-management application with portfolios, projects, activities, resources, contacts, risks, and decisions. Its user guide treats the project as the highest level of visibility and definition for access rights based on profiles. That sentence describes a useful boundary for defenders because a reachable login page is only the entry point to a graph of project records.

A count-only ZoomEye query for title="ProjeQtOr" returned 485 matches on 2026-11-10 at 00:51 UTC. The app="ProjeQtOr" query returned zero, while http.body="ProjeQtOr" returned 726. The title and body results are close enough to suggest a recognizable product marker, but the body query is still a broad textual signal. Neither result proves access or vulnerability.

The title query is the practical starting point for an inventory. It identifies a small internet-visible population that should be checked against internal deployment records and ownership. View the title measurement in ZoomEye. The scope was page 1, page size 1, sub_type=all, with the exact count as the matched total.

Profiles and allocations are different controls

The ProjeQtOr guide says a profile defines in-app permissions and data access rights. A profile allocated to a user, resource, or contact on a project controls that person's scope for that project. The documentation also says the profile in the allocation does not grant or revoke access to users. The two concepts need to be read together.

That distinction matters during review. A user may have a powerful global profile but no allocation to a sensitive project, or a modest profile with a project allocation that exposes more data than expected. The effective question is which projects the user can reach and which actions the user can perform in each project.

Project visibility can also be changed by assignment and planning workflows. A user who should see only one project may appear in portfolios or resource views if the role and allocation model is not understood. Test the interface with the actual account. Do not infer the final view from one profile label.

The API is part of the identity surface

The ProjeQtOr administration guide documents a REST API and an API directory with a template .htpasswd that references the default username and password projeqtor. A template is not proof that a production deployment left the password unchanged. It is a clear item to verify because default credentials in a shipped example can become a durable exception.

Review API authentication separately from the browser login. Record which accounts can call the API, how the request identifies the user, which project data the response can contain, and whether the API respects the same project allocation as the user interface. Rotate any account that appears in a deployment guide, sample file, repository, or support note.

The user guide also describes external-directory login through LDAP. If the application accepts LDAP identities, review the external user population, disabled accounts, and project allocations. Federation or LDAP authentication proves who the user is; it does not decide which projects the user should see.

Turning the count into an asset review

Use the ZoomEye title count to build a discovery list, then confirm the product in a small authorized sample. A title can be customized, so a zero app match should not be used to delete the product from inventory. The body query is useful for finding customized instances, but it needs a more specific marker and manual validation.

For each owned instance, record the base URL, environment, owner, authentication method, LDAP or SSO configuration state, default API template status, and the number of active projects. Review the administrators and the users with cross-project visibility. Check whether project allocation records are changed when a person moves to another team.

Test access from a non-administrator account. Try to open a project that is not allocated and call the corresponding API object. Test an account that has been disabled in the external directory but might still exist in ProjeQtOr. Test whether an API key or password remains valid after the user is deactivated.

What the evidence supports

The measurement supports a statement about matching title records in ZoomEye. It does not establish that 485 organizations are using ProjeQtOr, that the pages are live project systems, or that any account is weak. The app zero is a fingerprint result, not an ownership conclusion. The body count is a broader discovery signal.

That is still useful. A small product population is easier to review than a broad web-server population, and a project system often provides a clear path from an exposed page to business records. The defensible conclusion is that ProjeQtOr deployments deserve an owner and an access review, especially where API defaults, project allocation, and LDAP synchronization have not been tested together.

References

Measurement metadata: 2026-11-10 00:51 UTC, sub_type=all, page 1, pagesize 1; title 485, app 0, body 726.