Vaultwarden at internet scale: 87,252 title matches on the self-hosted password vault

Vaultwarden is the lightweight, community-maintained implementation of the Bitwarden server API, and it is a popular choice for teams that want password management on their own hardware. A ZoomEye search for the product's page title returns 87,252 matches, which is a large number for a service whose entire purpose is to hold credentials.

How the figure was produced

The measurement is a single ZoomEye query with the condition title="Vaultwarden", run with sub_type=all and a page size of one. Page size limits how many records are returned; it does not limit the matched total, which is what the platform reports for the condition.

Three qualifications belong with the number. It is a title match, so it reflects hosts where the string appears in the page title at the moment of indexing, and it does not verify that the instance is reachable now. It does not distinguish a serious deployment from a test instance someone left running. And it counts hosts, not accounts, so the population of credentials behind those hosts is unknown from the outside.

Even with those caveats, 87,252 is the kind of figure that changes the question from whether exposure exists to how much of it is intentional.

What a reachable Vaultwarden instance exposes

The first thing a scanner sees is usually the web vault interface, which is designed to be reached by users and therefore sits on a normal HTTPS port. Behind it are the API endpoints the clients use.

The security model depends on the master password and on the server never seeing the derived key in a usable form. That design is sound, and it means an exposed instance does not immediately leak vault contents. What it does expose is the identity layer. Registration is frequently left open so that new employees can enroll themselves, and on an open instance an attacker can create an account, observe the invitation and organisation behaviour, and use the login endpoint as a credential-stuffing oracle against real user addresses.

The administrative surface is the second concern. Vaultwarden ships an /admin panel that is protected by a token. Instances where the token was left at a default or committed to a configuration repository have been the subject of past disclosures in this ecosystem, and the panel exposes user lists, organisation settings and SMTP configuration.

Reading the number usefully

The value of 87,252 is comparison, not alarm. Run the same condition against the organisation's own discovery output and the difference between the two numbers is the set of hosts the organisation does not know about.

For the ones that are known, three checks take an afternoon. Confirm that registration is closed, or that it requires an invitation. Confirm the admin token was generated for this deployment rather than copied from a guide. And confirm the instance is on the version the project currently recommends, since the project publishes security-relevant fixes with its releases.

What ZoomEye adds here

A title query answers one question: how many hosts announce this product. The follow-on queries are where the measurement becomes a management tool. Filtering by country narrows the population to regions the organisation operates in. Filtering by the certificate in use, where the field is available, separates hosts with a real certificate from those with a default one, which is a rough proxy for whether anyone is maintaining the instance.

Used that way, the figure moves from a headline to a starting list.

Limits

The count reflects indexed fingerprints and not verified live services, and it does not measure whether any instance has been compromised. Nothing in this article is a claim about a specific organisation's exposure.

References

• ZoomEye search syntax and field reference: https://www.zoomeye.ai/doc