5,375 titles, 5 fingerprints: Planka, and what a board full of project data looks like from outside

Planka is a self-hosted kanban board — Trello-shaped, one container plus a database — and on 27 October 2026 it returned 5,375 title matches against 5 application fingerprints. That is a ratio over a thousand to one, the widest in this collection, and it forces a question that a single number never answers: which of those pages is a running board, and which is a screenshot in a blog post about self-hosting?

The measurement

ZoomEye, sub_type=all, one page per query, totals only, no host records retrieved:
| Query | Total |
|---|---|
| title:"Planka" | 5,375 |
| app:"Planka" | 5 |
A count of five is at the edge of statistical usefulness. At that scale a single deployment going offline or being discovered changes the figure by twenty per cent, and any trend drawn from consecutive measurements would be noise. The honest use of the number is as a lower bound on positively identified hosts, not as a population estimate.

Why the title count is so far ahead

Three sources inflate a title match for a popular self-hosted tool, and Planka has all three.
The first is documentation. The project's own pages, installation guides, container image pages and reverse-proxy tutorials all carry the name in a title. Those are pages, not servers.
The second is comparison content. "Planka vs Trello", "best open-source kanban", and every listicle that mentions it produces a titled page with no deployment behind it.
The third is authentic deployment. A self-hosted board on board.company.tld often keeps the product's default title, which is why this count is larger than a white-labelled product's would be.
The five fingerprints are the opposite: a host whose response artefacts match the application confidently. That is a small, verifiable set, and small verifiable sets are what an inventory should be built from.

What a kanban board holds

The exposure question for a project board is not about the software; it is about what teams write on cards. In practice a board holds customer names, unreleased feature plans, incident timelines, credentials pasted into a card by someone in a hurry, and links to internal systems.
Four properties make a reachable instance worth escalating.
Boards are shared with external collaborators. Planka supports project membership, so an instance usually has more accounts than the team that runs it, including contractors and, in some cases, customers.
Attachment handling is a file store. Cards carry uploaded files, which means the instance holds a directory of documents whose access control is the application's responsibility.
The API is the real surface. A board UI is a thin client over a REST or socket API. An exposed instance is an exposed API with the UI's routes as documentation.
Session tokens are long-lived. A self-hosted board is a daily-use tool, which means sessions persist, and a stolen token stays useful.

Turning five into a working inventory

• Do not derive your inventory from a global count. Five, five thousand, or five hundred thousand — the number describes an index, not your estate. Enumerate the hosts you own that answer on the board's port and require a login.
• Check the registration setting. A board that allows self-registration on a public address is a shared workspace with an open door. That is a configuration choice and it takes one request to test.
• Review membership against the collaborator list. Every account that can read a board is an account that can exfiltrate it. Contractors who left the project rarely lose access on their own.
• Inventory attachments separately. Card attachments live outside the database in most deployments, and they are the part that backups and access reviews most often miss.
• Treat the API as the asset. If the UI is behind SSO and the API is not, the UI's protection is decorative.

Reading the ratio honestly

The 5,375 describes pages that mention a product in their title. The 5 describes hosts the index can identify as running it. Both are true, neither is an exposure count, and the gap between them is a warning against building a risk narrative on a title dork. For the operator of one board, the useful question is narrower: is it reachable, does it accept registrations, and who is on the member list.

Limits

Both totals are single-day index observations from one provider. The three explanations for the title inflation are typical patterns inferred from how self-hosted tools are documented and discussed, not a classification of any matched page. No Planka host was inspected, no registration endpoint was tested, and no exploitation or vulnerability in Planka is asserted here — this article measures exposure and describes what the exposed asset would contain.

References

• Planka repository and documentation: https://github.com/plankanban/planka
• ZoomEye search syntax reference: https://www.zoomeye.org/doc