Buildbot Web Controls Are Privileged by Default

Buildbot, a system that automates build processes, comes with a web interface that has access controls disabled by default. This means anyone can access it without logging in. The web UI allows users to view build status, logs, artifacts, and control builds. Despite the seemingly innocuous nature of build output, the default configuration makes the web server a prime target for attacks.

ZoomEye, a web vulnerability scanner, identified 323 instances of Buildbot within 10 minutes of scanning. However, these results include documentation and project pages, not necessarily exposed web controls. The exact features available depend on the installation and authentication plugins used. Even if a page appears read-only, it may still have hidden forms, API routes, or websocket actions.

It is crucial to examine the functions each page can perform rather than assuming they are inactive. Authentication should be configured before anyone can access the UI. If a reverse proxy is used for authentication, Buildbot should only trust the username header provided by that proxy. This is unsafe if clients can reach Buildbot directly or if the proxy accepts forged headers.

It is also important to distinguish between human operators and automation. A service account that triggers builds should have minimal permissions, while a worker should authenticate with its own credential and not modify build configurations or run arbitrary commands. After a rebuild, worker passwords and connection settings should be reviewed.

Build logs can expose sensitive information such as environment variables, repository URLs, or test credentials. Logs and artifacts should be retained only as long as necessary and stored in separate credentials for each environment. A production worker should not share an artifact bucket with a development worker if the credentials could overwrite release content.

When upgrading Buildbot, check the release notes for new endpoints or changed defaults and run authorization tests. The configuration file should be under version control, but worker passwords and proxy secrets should not be committed. Test the web layer after an upgrade, including direct access to the Buildbot port, to ensure the identity control is not bypassed.

A forged username header from a non-proxy client should be rejected. With its default configuration, Buildbot's web controls expose a high level of authority, making it essential to treat them as a privileged system rather than a simple status dashboard.