CRLF injection vulnerability in Jenkins before 1.491, Jenkins LTS before 1.480.1, and Jenkins Enterprise 1.424.x before 1.424.6.13, 1.447.x before 1.447.4.1, and 1.466.x before 1.466.10.1 allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via unspecified vectors.
Cross-site scripting (XSS) vulnerability in Jenkins before 1.491, Jenkins LTS before 1.480.1, and Jenkins Enterprise 1.424.x before 1.424.6.13, 1.447.x before 1.447.4.1, and 1.466.x before 1.466.10.1 allows remote authenticated users with write access to inject arbitrary web script or HTML via unspecified vectors.
Jenkins Security Advisory 2012-11-20
The second vulnerability is so-called open redirect vulnerability. This allows an anonymous attacker to create an URL that looks as if it's pointing to Jenkins, yet it actually lands on the site that the attacker controls. This can be therefore used as a basis for phishing.
Fix: Main line users should upgrade to Jenkins 1.491 LTS users should upgrade to 1.480.1
External URLs: https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2012-11-20 http://www.cloudbees.com/jenkins-advisory/jenkins-security-advisory-2012-11-20.cb
Cross-site scripting (XSS) vulnerability in Jenkins before 1.454, Jenkins LTS before 1.424.5, and Jenkins Enterprise 1.400.x before 1.400.0.13 and 1.424.x before 1.424.5.1 allows remote attackers to inject arbitrary web script or HTML via unspecified vectors, a different vulnerability than CVE-2012-0324.
Cross-site scripting (XSS) vulnerability in Jenkins before 1.454, Jenkins LTS before 1.424.5, and Jenkins Enterprise 1.400.x before 1.400.0.13 and 1.424.x before 1.424.5.1 allows remote attackers to inject arbitrary web script or HTML via unspecified vectors, a different vulnerability than CVE-2012-0325.
It was reported [1] that Jenkins suffers from a vulnerability that allows an attacker with HTTP access to the server to retrieve the master cryptographic keys used by Jenkins to encrypt sensitive data in configuration files under $JENKINSHOME, in HTML forms, the authenticate REST API access from users, and authenticating slaves connecting to the master. An attacker with this key could execute arbitrary code on the Jenkins master or impersonate arbitrary users via REST API calls.
This can be somewhat mitigated, depending on certain installations:
- this is only applicable on Jenkins instances that have slaves attached to them, and allow anonymous read access - regenerated API tokens, with a user can regenerate, cannot be impersonated by the attacker
This is fixed upstream in version 1.498 and the LTS 1.480.2 version.
In git, the fix seems to be spread across a few commits
[1] https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2013-01-04
In git, the fix seems to be spread across a few commits (those prefixed with [SECURITY-49]):
https://github.com/jenkinsci/jenkins/commit/a9aff088f327278a8873aef47fa8f80d3c5932fd https://github.com/jenkinsci/jenkins/commit/4895eaafca468b7f0f1a3166b2fca7414f0d5da5 https://github.com/jenkinsci/jenkins/commit/c3d8e05a1b3d58b6c4dcff97394cb3a79608b4b2 https://github.com/jenkinsci/jenkins/commit/3dc13b957b14cec649036e8dd517f0f9cb21fb04 https://github.com/jenkinsci/jenkins/commit/94a8789b699132dd706021a6be1b78bc47f19602