It was recently reported that under specific circumstances, encrypted environment variables could be leaked through our API. This post details the nature of the issue, which repositories may have been affected, and the necessary steps we have taken to ensure that encrypted environment variables remain secure.

All affected users have been contacted. If you did not receive an email from us with the subject “Encrypted environment variable security question”, you were not affected by this issue.

History

Since 2013, Travis CI has provided users with the ability to encrypt sensitive environment variables. This feature allows build machines to communicate with private services; one common example is to deploy an application directly after a build job has successfully completed.

Using the Travis CI command line tool, the following command encrypts the given environment variable, using the remote private key associated with the repository found in the current working directory:

$ travis encrypt FOO=bar

Using the -a flag appends the environment variable to the config file (.travis.yml) for the repository. The config file would then look as follows:

env : global : - secure : a-very-long-encrypted-string

Environment variables that have been added to the config are available via the Travis CI API. The responses from the jobs endpoint shows the variable name unencrypted but the value obfuscated:

{ "job" : { "id" : 123 , "config" : { "global_env" : "FOO=[secure]" , ... } , ... } }

The problem

A problem arose when users attempted to use the same command without the = , as follows:

$ travis encrypt FOO bar

This encrypted the value FOO bar , which is not only useless as a variable assignment, but also led to a security vulnerability in the Travis CI API. The environment variable was returned as follows:

{ "job" : { "id" : 123 , "config" : { "global_env" : "FOO bar" , ... } , ... } }

The potential for leaking sensitive information due to a slight user error here is quite high. The risk has existed ever since the encryption feature was introduced in January 2013.

Who was affected?

We determined that 1,230 repositories were affected. The repository owners have all been contacted and were given seven days to ensure that any credentials which could have been compromised are no longer in use before this public disclosure.

Please search your inbox/spam for an email with the subject “Security of encrypted environment variables” if you want to confirm that you are not affected by this issue. Of course, you can also contact us at any time. We will be very happy to talk you through the issue.

Conclusion

Firstly, we would like to thank Travis CI user Marcin Zajączkowski for disclosing this vulnerability.

The bug in the API has already been fixed and is no longer present in production. We continue to unencrypt the environment variable names in the interest of usability ( FOO=[secure] ), but the values can no longer leak, even when incorrectly formatted.

In addition, the command line client now displays a warning when users add a poorly formatted environment variable to the config file.

$ travis encrypt FOO bar -a Environment variables in env.global should be formatted as FOO=bar

We know that security is important to our users and we do strive to provide a reliably secure CI environment. While the chances that this has been exploited are relatively low, we also understand the pain of rotating credentials after a security issue, and we apologise sincerely.

Thanks for your understanding and happy building!