FreeScout is a shared help-desk application. A visible login page may be the least interesting part of the service. Mailboxes contain customer messages, internal notes, attachments, and sender identities. The security review has to connect account roles, mailbox permissions, API keys, and the network path that reaches the application.

Two count observations

On 2026-10-30, ZoomEye count-only queries used sub_type=all, page 1, and page size 1. app="FreeScout" returned 1,272. title="FreeScout" returned 1,712.

The title result is larger. That does not mean there are 440 additional servers without a fingerprint. The queries use different matching fields and may overlap in ways the totals do not reveal. The counts should be retained as separate observations.

Both results indicate that FreeScout is visible in internet-wide data. An organization should use the result to prompt an inventory, not to assume that every match is its own or that every match accepts public registration.

Mailbox access is the main object

FreeScout's FAQ documents a setting for non-administrator users that limits them to assigned conversations. The API documentation notes that a newly created user may not have access to any mailbox by default. That default is useful because mailbox membership is a data boundary, not just a convenience setting.

Review each mailbox's members and administrators. Check whether a support agent needs every conversation or only the team's queue. Look for users who changed roles but retained direct membership. Include shared accounts and integrations in the review.

Personal API keys and application API access need the same ownership. The API and webhooks module documentation describes personal API keys. A key belongs to a user and can expose the data that user can reach. Retire keys for separated staff and test that the old key fails after retirement.

External links and inbound mail

Help-desk workflows often include customer portals, webhooks, and email ingestion. Confirm which hostname faces customers and whether that route can reach staff-only settings. A reverse proxy that protects the admin path should also protect related APIs and background endpoints.

Webhooks send data to another service. Limit destinations to approved hosts and do not let a low-privilege user add an arbitrary endpoint without review. Incoming email can carry attachments and HTML. The application should treat them as untrusted input, and the surrounding mail gateway should still scan them.

Test the boundary

Create two test users in different mailboxes. Confirm that each can see the intended conversations and cannot read the other's message through the UI, an API route, or a direct attachment URL. Repeat after changing a role. The test should leave no real customer data in logs.

Use a network identity that is not on the staff VPN to check whether the login page is intentionally public. If it is public, confirm MFA or another strong authentication control for privileged users. If the application is meant to be internal, verify that the public DNS and proxy paths do not reveal it anyway.

Evidence to retain

Keep the exact query strings and measurement times with the asset record. For each owned instance, record the owner, version, public hostnames, mailbox count, administrative accounts, and API-key review date. A title count alone does not show whether mailbox permissions are correct. The required evidence is a tested mailbox separation and a retired key that no longer works.

References