Gotenberg converts documents to PDF, and the fingerprint count of 3,030 says little about who can reach it

Gotenberg is a stateless document conversion service. It accepts a document or a URL and returns a PDF, which makes it a component in invoicing, reporting and archiving pipelines rather than a destination users visit. That role explains a measurement where the two obvious queries disagree by two orders of magnitude.

The numbers

On 2026-10-19, app="Gotenberg" returned 3,030 matching assets and title="Gotenberg" returned eight.
A title query on a service that returns PDFs has almost nothing to match. A fingerprint query on a service that returns structured error pages and version headers has something to match on every instance. The eight title matches are probably documentation pages or installations that serve an HTML interface by coincidence.

Why the population is misleading in both directions

Reading 3,030 as a count of exposed conversion services overstates the organisation-relevant figure, because the query is global. Reading eight as the count of installations understates it, because the title query is not measuring installations at all.
The number that matters for an owner is the count within their own address space, and the number that matters for a trend line is the global count measured the same way over time.

The security question a converter raises

A conversion service is a parser with a network interface. It accepts a document in a format whose specification is large, and it renders it, which is the same description that fits several classes of memory-safety bug.
Two service-specific properties make the exposure question concrete. First, Gotenberg can fetch a URL rather than receiving an upload, which means a converter reachable by an untrusted party is a request-forgery primitive against anything the service can reach. Second, the output is a file, so a conversion pipeline that writes to a shared directory inherits the file-handling question on top.
Neither is a claim that a specific version is vulnerable. Both are reasons to decide who may call the service, and to make that decision at the network layer rather than only in application code.

Controls that fit a pipeline component

A conversion service belongs on an internal network with an explicit list of callers. Where that is impractical, an authenticated proxy in front of it provides the same boundary and leaves an audit trail.
The URL-fetch capability deserves a separate decision. If the pipeline only needs uploaded files, restricting outbound access from the service removes the request-forgery path without changing the intended function.
The output directory should be readable by the caller and not by every account on the host. That is the same file mode question that applies to any service that writes files, and it is decided at deployment rather than in code.

Recording the measurement properly

Because the title query is uninformative for this product, a monitoring routine should use the fingerprint query alone and state that the title query was tested and found uninformative. Reporting a tested negative is more useful than omitting the query, because the next analyst will wonder whether anyone tried.

Limits

The count describes recognised services. It does not establish that any instance accepts requests from outside its intended callers, and it does not establish a version. Both require a request the operator authorises.

References

• Measurement collected 2026-10-19: app="Gotenberg" 3,030; title="Gotenberg" 8 (ZoomEye, sub_type=all).
• Gotenberg documentation: https://gotenberg.dev/
• ZoomEye: https://www.zoomeye.ai/