Bug #12596

Check Jenkins 2017-04-26 security advisory

Added by intrigeri 2017-05-25 07:05:39 . Updated 2017-07-06 13:58:32 .

Continuous Integration
Target version:
Start date:
Due date:
% Done:


Feature Branch:
Type of work:

Affected tool:
Deliverable for:


Forwarded on Apr 27, pinged on May 16, no reply => let’s track this on a ticket instead of trusting email.

Are we affected? Anything we should do to fix it?


Related issues

Blocks Tails - Feature #13233: Core work 2017Q3: Sysadmin (Maintain our already existing services) Resolved 2017-06-29


#1 Updated by intrigeri 2017-05-27 08:44:34

  • Target version changed from Tails_3.0 to Tails_3.1

It can wait one more month => cleaning up a bit your 3.0 plate :)

#2 Updated by intrigeri 2017-06-29 10:16:38

  • blocks Feature #13233: Core work 2017Q3: Sysadmin (Maintain our already existing services) added

#3 Updated by bertagaz 2017-07-06 13:48:18

  • Assignee changed from bertagaz to intrigeri
  • QA Check set to Ready for QA

intrigeri wrote:
> Are we affected? Anything we should do to fix it?

We are affected, in that the version of Jenkins we use is supposed to be vulnerable.

Now, as we’re not running it publicly, but behind a web proxy, all the CLI vulnerabilities in this advisory are somehow mitigated. It’s not available on the internet without the HTTP password.

The rest of the advisory is about a XSS vulnerability. I guess this one could work if one of us was logged in in Jenkins and would click on a malicious link. OTOH, we don’t find (and click if we do hopefully) that kind of link everywhere on the web, mostly on this Redmine instance.

We don’t have much alternatives other than upgrading Jenkins if we consider this issue is important. Bot sure when it’s doable yet.

#4 Updated by intrigeri 2017-07-06 13:58:33

  • Status changed from Confirmed to Resolved
  • Assignee deleted (intrigeri)
  • % Done changed from 0 to 100
  • QA Check changed from Ready for QA to Pass

OK, I see. Basically we have no choice, given the version of Jenkins we’re still running, than relying purely on our HTTP password authentication and ignoring such issues. This is not a really good situation to be in, but I see no realistic short term option so I’ll live with it. Marking as “Resolved” then.