We just released security updates to Jenkins, versions 2.57 and 2.46.2, that fix several security vulnerabilities, including a critical one. That critical vulnerability is an unauthenticated remote code execution via the remoting-based CLI. When I announced the fix for the previous vulnerability of this kind, I announced our plans to revisit the design of the CLI that enabled this class of vulnerabilities. Since Jenkins 2.54, we now...

In response to the zero-day vulnerability we fixed in November, I wrote the following: Moving forward, the Jenkins security team is revisiting the design of the Jenkins CLI over the coming weeks to prevent this class of vulnerability in the future. If you are interested in participating in that discussion, please join in on the jenkinsci-dev@ mailing list. In early February, several project contributors met after FOSDEM...

These are not security fixes you can apply blindly. We strongly recommend you read this post, as well as the security advisory to understand what the vulnerabilities are, whether and how they affect you, and what to expect when upgrading plugins. Multiple Jenkins plugins received updates today that fix several security vulnerabilities or other security-related issues: Email Extension (Email-ext) Environment Injector (EnvInject) Extensible Choice Parameter Groovy Job DSL Lockable Resources Matrix Authorization Role...

Multiple Jenkins plugins received updates today that fix several security vulnerabilities: Active Directory Distributed Fork Email Extension (Email-ext) Mailer SSH Build Agents For an overview of what was fixed, see the security advisory. Additionally, we also published a security notice for the following plugin and recommend that users disable and uninstall it: Pipeline: Classpath Step This plugin is not part of the Pipeline suite of plugins, despite its name. It’s installed on just...

We just released security updates to Jenkins, versions 2.44 and 2.32.2, that fix a high severity and several medium and low severity issues. For an overview of what was fixed, see the security advisory. For an overview on the possible impact of these changes on upgrading Jenkins LTS, see our LTS upgrade guide. I strongly recommend you read these documents, as there are a few possible side...

Jenkins 2.40 was released earlier this week, and readers of the changelog will have noticed that it now includes the ability to show security warnings published by the configured update site. But what does that mean? In the past, we’ve notified users about security issues in Jenkins and in plugins through various means: Emails to the jenkinsci-advisories mailing list (which I recommend you subscribe to), blog posts, and, recently, emails...

A zero-day vulnerability in Jenkins was published on Friday, November 11. Last week we provided an immediate mitigation and today we are releasing updates to Jenkins which fix the vulnerability. We strongly recommend you update Jenkins to 2.32 (main line) or 2.19.3 (LTS) as soon as possible. Today’s security advisory contains more information on the exploit, affected versions, and fixed versions, but in short: An unauthenticated remote code execution vulnerability allowed attackers to transfer...

The Jenkins security team has been made aware of a new attack vector for a remote code execution vulnerability in the Jenkins CLI, according to this advisory by Daniel Beck: We have received a report of a possible unauthenticated remote code execution vulnerability in Jenkins (all versions). We strongly advise anyone running a Jenkins instance on a public network disable the CLI for now. As this uses the same attack vector as SECURITY-218, you can reuse the...

We just released security updates to Jenkins that fix a number of low and medium severity issues. For an overview of what was fixed, see the security advisory. One of the fixes may well break some of your use cases in Jenkins, at least until plugins have been adapted: SECURITY-170. This change removes parameters that are not defined on a job from the build environment....

Last week, the infrastructure team identified the potential compromise of a key infrastructure machine. This compromise could have taken advantage of, what could be categorized as, an attempt to target contributors with elevated access. Unfortunately, when facing the uncertainty of a potential compromise, the safest option is to treat it as if it were an actual incident, and react accordingly. The machine in question had access to binaries published...