Version 79 (modified by dustin, 11 years ago) (diff)

security alert, change version #

Security Alert

Nicolas Sylvain reported a cross-site scripting vulnerability in the waterfall web status view. This vulnerability allows an attacker to craft a URL targetting a specific Buildbot instance, and run arbitrary browser-side code in the context of that Buildbot instance. This constitutes a security risk both for the Buildbot instance and for any other services hosted on the same domain as that Buildbot instance, and is a particular threat when browsers' same-origin policy is used to protect sensitive information such as cookies.

Note that Buildbot itself does not use cookies (even in the IAuth framework), so the risk for a standalone buildbot instance is somewhat limited. Even so, all users are urged to upgrade or apply the patch given in the MITIGATION section, below.

This vulnerability is limited to the waterfall view, and does not affect Buildbot slaves.

Affected Versions

  • buildbot-0.7.6
  • buildbot-0.7.7
  • buildbot-0.7.8
  • buildbot-0.7.9
  • buildbot-0.7.10
  • buildbot-0.7.10p1
  • buildbot-0.7.11
  • buildbot-0.7.11p1

Unaffected Versions

  • buildbot-0.7.5 and earlier
  • buildbot-0.7.11p2


The fix for this vulnerability is a simple, one-line patch:

Users of buildbot-0.7.11p1 are encouraged to upgrade to buildbot-0.7.11p2, which contains this patch. For others, the simpler solution may be to apply the patch directly. The patch applies cleanly to all vulnerable versions of Buildbot, and will also apply to an installed copy of Buildbot.

Welcome to Buildbot!

The BuildBot is a system to automate the compile/test cycle required by most software projects to validate code changes. By automatically rebuilding and testing the tree each time something has changed, build problems are pinpointed quickly, before other developers are inconvenienced by the failure. The guilty developer can be identified and harassed without human intervention. By running the builds on a variety of platforms, developers who do not have the facilities to test their changes everywhere before checkin will at least know shortly afterwards whether they have broken the build or not. Warning counts, lint checks, image size, compile time, and other build parameters can be tracked over time, are more visible, and are therefore easier to improve.

The overall goal is to reduce tree breakage and provide a platform to run tests or code-quality checks that are too annoying or pedantic for any human to waste their time with. Developers get immediate (and potentially public) feedback about their changes, encouraging them to be more careful about testing before checkin.

Many thanks to for hosting the buildbot's SourceForge Project Page for all these years. Logo