This post contains information about a security patch available for GoCD 15.2 (and soon, earlier versions). If you're using GoCD 15.2 in production, and especially if it is available over the internet, it is highly recommended to apply this patch immediately.

[Any updates to this post are available starting here]

What is the vulnerability?

As a part of AppSecCali 2015, a talk highlighted a vulnerability using Java deserialization with Apache commons-collections, a very commonly used library in Java-based applications. Though the talk focused on other applications, GoCD is affected too.


This is a potentially serious issue and applying the patch is recommended, since it is a remote code execution vulnerability in Java deserialization (exploited using Apache commons-collections).

The impact is reduced a bit, because as far as we are able to determine, this attack on the server is possible only by having the authentication certificate of an already-registered and enabled Go Agent, because of the way the GoCD Server and GoCD Agent communicate using a secure connection.

So, even if you have a GoCD server exposed to the internet, you're not immediately vulnerable, as far as we have been able to determine (and we have given it a lot of thought).

Risks of applying this patch:

This patch removes the known vector for this attack, as recommended by the vulnerability report. But, given the urgency, this patch hasn't been extensively tested. There is a small potential for the Go Server to fail. However, given that the patch is just a replaced JAR file, you can replace the original JAR file, if that happens and contact us on the GoCD community mailing list or at (if you need a private way to reach some of the committers).

We have been using this patch on and it has been fine. We will update this post if anything new is found.

Risks of not applying this patch:

The GoCD server will be open to arbitrary remote code execution from anyone who has access to a registered Go Agent (or the agent.jks file of such an agent). This is true of an agent which was once registered and then disabled as well.

How do I apply this patch?

Steps to apply the patch:

  1. Download the appropriate go.jar file mentioned below, for your version of the Go Server and verify its checksums.

  2. Find out the location of your go.jar file and take a backup. On different ways of installation of Go, this can be in different places:
    • On Windows: It is usually in C:\Program Files (x86)\Go Server\go.jar
    • On Debian and RPM based installations: It is usually in /usr/share/go-server/go.jar
    • On zip installers: It is in the base directory where you start the Go Server from.
  3. Now that you have a backup of go.jar, stop the Go Server and replace go.jar with the one you downloaded.

  4. Restart the Go Server.

All of your agents will now fetch the new agent JAR as well, and restart themselves. Depending on the number of agents you have, this might take a little while (same as an upgrade of the Go Server).

The different patches available are:


  • JAR file:
  • MD5 checksum: 0872e4eefceaaf842a69d8b55ec6a2d0
  • SHA256 sum: eecee2b04c9bd46e74c5c999585683daf164fe41b39151dfcc3f0642561fd4c5
  • GPG signature:


  • JAR file:
  • MD5 checksum: 5981fee0fbd4e7be51a9d0351694bd13
  • SHA256 sum: 8ffe0461ab7d0f5ab5aaf1c4a10f8519c7acf7d808bff987614a8e867edee152
  • GPG signature:


  • JAR file:
  • MD5 checksum: 72409fb8ee9a305b03439747043752bd
  • SHA256 sum: 452c1cb7518d9654b000d18068729cd9a2072ce8bc262dededebc002f88141f8
  • GPG signature:


  • JAR file:
  • MD5 checksum: 64de38f7363a9345cad5e9c39aaa468e
  • SHA256 sum: 80d98e12d0b18107840951b2c067edf554a966131373ab0015a585021f46538f
  • GPG signature:


  • JAR file:
  • MD5 checksum: 68a711227d7a2cd663f304cf04c87139
  • SHA256 sum: 6212eb9d0ab59d626e8ea3ec70ae0c34689f0de233502bd2f034fc91017c08f7
  • GPG signature:

The JAR files above are signed using the usual key used to sign the RPM and DEB installers. The signature file provided can be used to verify it. The public key is available on MIT PGP Public Key Server and GoCD's bintray page. When verified, you'll see that it is signed by the GoCD team:

$ gpg --verify go.jar.asc go.jar
gpg: Signature made Mon Nov  9 12:13:21 2015 EST
gpg:                using RSA key 0x9149B0A6173454C7
gpg: Good signature from "Go CD (GPG key for signing bintray downloads) <>" [full]
Primary key fingerprint: 9A43 9A18 CBD0 7C3F F81B  CE75 9149 B0A6 1734 54C7

I don't trust you. How do I generate this patched go.jar myself?

Glad you asked. Take a look at this.


Update 1: 9th Nov, 2015 - 1830 EST

This patch fixes one of the known vectors, but there could be one other, TemplatesImpl, which might be vulnerable. From an early analysis, it doesn't seem to be, since it has some security and expects a JDK property to be set, before it is used. If we find more about it, this post will be updated. Even if it is vulnerable, there might not be much that can be done, because that is a class provided by the Java Runtime Environment itself. The long-term fix for issues such as this is to move away from Java serialization.

See these articles for more information: InfoQ: Remotely Exploitable Java Zero Day Exploits through Deserialization and The Java Deserialization Bug.

Update 2: 10th Nov, 2015 - 1900 EST

  • Updated the "How do I apply this patch?" section with information about patches for older, supported versions.
  • Removed the shell script for generating the patched version. It was too much information on this page. It is linked.
  • Go is not vulnerable to the TemplatesImpl payload.

Note: This post will be updated with more information, as we find it and with information about patches for older, supported installers. If you need help, please email the GoCD community mailing list or for a private channel,