In November last year the token issued for displaying job logs on Travis CI was incorrectly valid for two other endpoints. This issue was discovered on Wednesday 14 February, 2018 and fixed the next day. Further investigation into historical data found no successful attempts at fetching non-log endpoints with the log token. This indicates the issue was not exploited in any way.

When displaying job’s log on Travis CI we also show a button to retrieve a raw version of the log. If a repository is private, the link to the raw log contains a log token for convenience so that, for example, the log can be opened in a new browser tab. The token is valid for 24 hours and should only be valid for that specific log.

In November last year we were updating the V3 version of our API to include the log token in the /job/:id/log endpoint. Unfortunately, the token issued for the log was also valid for two other endpoints: /job/:id and /repository/:id/jobs. This meant an attacker could get information about a job, a job’s config, or the job’s commit info, which in some cases may be sensitive.

The problem was caused by using our permissions system in a wrong way. Instead of checking the log visibility for a user we reused a function that checked the job visibility. On top of that the log token isn’t scoped to specific endpoints, which allowed to use it on any endpoint that was only checking for a job visibility. We’ve fixed this by using a fine grained log visibility check and by adding more tests covering this area of the code.

As mentioned above, the issue was discovered on 14 February, and resolved the following day. Going forward we plan to revisit our code to allow to scope tokens to work only on specific endpoints, which would make it much harder to introduce such issues in the future. We will also do a review of the permissions system to confirm that there are no other places were permissions checks are too generic.

If you’re concerned about the issue, don’t hesitate to contact us at support@travis-ci.com.