Memos is a self-hosted note-taking application built around a timeline of short notes. Some notes are private, some are visible to signed-in users, and some can be shared publicly. That range makes product discovery different from deciding whether a page exposes a note. A visible login form and a public bearer-token link are separate observations.
A ZoomEye count-only measurement on October 31, 2026 at 06:44 Beijing time used page 1, page size 1, and sub_type=all. app="Memos" returned 0 matches and title="Memos" returned 6,134. These counts describe visible ZoomEye fingerprints. They do not identify public notes, signed-in-only pages, or installations with weak access controls.
Treat the zero as a fingerprint result
A zero app result means the exact application fingerprint was absent from this result scope. It does not mean there are no Memos instances. Self-hosted software often appears under a company domain, with a custom title, a reverse proxy, or a configuration that changes the default response.
The title count is broader because the word can appear in login pages, help content, and unrelated pages. Use it to find candidates, then verify the product from an owned deployment. If the page is not owned by the organization, do not use a share path, API route, or login form to test access. A product match is not permission to inspect notes.
Separate visibility from sharing
Memos' API definitions distinguish a note's visibility from a share grant. A private note belongs to its owner. A signed-in-only note can be read by authenticated users under the deployment's policy. A public note can be read anonymously. A share grant provides read-only access through an opaque bearer token.
That means a note URL can be sensitive even when the main application requires login. A share token should be treated as a capability. Anyone who obtains it may be able to read the note until it expires or is revoked. Record who created the share, which note it references, the intended audience, and the revocation path.
Check whether shares are visible in the application's administrative interface or only to the note owner. Test revocation on an owned instance. Confirm that a revoked token fails and that the cached page is not still served by a proxy. Review browser history, chat previews, mail archives, and support tickets for share links that escaped their intended recipients.
Review instance access settings
The deployment policy should state whether the instance is public, authenticated, or private. Public instances may allow anonymous reading of public notes, while private instances should reject unauthenticated access. Do not infer that setting from one page title. Check the effective configuration and test the behavior with a fresh session.
Review personal access tokens, administrator accounts, backup access, and database permissions. A token that survives a password change needs an explicit ownership and revocation process. Audit signup and user creation if the instance is exposed. Keep the database and attachment storage out of direct public paths.
For external discovery, capture only the hostname, title, first-seen time, and visible authentication status. Do not open note paths or enumerate user names. For an owned asset, compare the public route with the internal service inventory and confirm that the intended access mode matches policy.
Build the record that matters
The useful unit is a deployment record: owner, hostname, access mode, authentication methods, administrator group, token policy, share policy, backup location, and last review. Add a test note for each visibility state, a share token test, a revocation test, and an unauthenticated request to an internal route.
ZoomEye helps find a self-hosted service that may have left the asset catalog. It cannot show whether an individual note is safe. The application's visibility model and share tokens decide what a successful viewer can read.
Conclusion
Memos app and title counts are discovery evidence, not exposure evidence. The title query is a starting inventory; the app count shows one fingerprint's limit. Security review starts when an owned deployment is connected to its access policy, share tokens, administrators, backups, and revocation tests.