Unprotected Browserless Endpoints Can Execute Arbitrary Puppeteer Code

Browserless is a headless-browser service used for screenshots, PDFs, scraping, and browser automation. It can accept URLs, scripts, and browser instructions from a caller. That makes authentication and network egress part of the product's core security model, not optional deployment polish.

The ZoomEye query on 15 November 2026 returned 19 matches for app="Browserless", 13,176 for title="Browserless", and 31,844 for http.body="Browserless" with sub_type=all, page 1, and page size 1. The title and body counts are broad because documentation and integration pages use the product name. The application fingerprint is the better discovery signal, but it is still not proof of a vulnerable or unauthenticated deployment.

A browser service is a privileged primitive

The project's open-source Docker guide is explicit: Browserless does not generate a token for you, and leaving TOKEN unset leaves every endpoint unauthenticated, including /function, which executes arbitrary Puppeteer code from the request body. An owner who deploys that image without a token has created a remote browser execution service. The correct response is to configure a strong token and restrict access before exposing the port.

Tokens should be separated by role or tenant when the deployment supports it. A screenshot-only integration does not need the same authority as an administrative function endpoint. Store tokens in the calling service's secret manager, rotate them after exposure, and avoid putting them in browser JavaScript or public URLs.

The service's network egress is a second boundary. A browser can reach internal addresses, cloud metadata endpoints, file URLs, or local services if the sandbox and browser are not constrained. Apply egress policy at the container, host, or network layer. Do not rely only on a URL denylist in the client. Test redirects, DNS rebinding, alternate IP encodings, and download behavior.

Harden the container

Run the browser service as a dedicated user with a read-only root filesystem where practical, bounded temporary storage, resource limits, and a short session lifetime. Disable features the integration does not need. Keep the browser and Browserless image patched, and pin image versions so a deployment does not silently change behavior.

Review the self-hosted image separately from the managed cloud. The provider's trust center describes the managed service, while the operator configures token roles and access control inside a self-hosted deployment. Account sign-in is not the control plane for the self-hosted image.

Inventory the hostname, version, token configuration, allowed caller networks, egress rules, session timeout, and log retention. Test an unauthenticated request, an invalid token, and a valid token against a harmless local test page. The point is to prove that the service rejects unauthorized execution before the browser starts.

References

• ZoomEye
• Browserless open-source Docker deployment
• Browserless documentation
• Browserless trust center