This advisory announces vulnerabilities or security-related fixes in these Jenkins plugins:
Environment Injector (EnvInject) (2 vulnerabilities)
Job DSL (2 vulnerabilities)
Scriptler (5 vulnerabilities)
Warnings (2 vulnerabilities)
Additionally, the following plugins had their vulnerability published and fixed in the past, but haven’t been included in a security advisory:
Due to the number of affected plugins, the list of issues below is split into three parts:
Arbitrary code execution vulnerabilities lists issues that allow users with relatively low privileges (Overall/Read or Job/Configure to run arbitrary code in Jenkins. This means that they can configure all parts of Jenkins (including granting their own user Overall/Administer permission, shutting down Jenkins, running any shell command on any connected agent, etc. In Jenkins, this is a privilege escalation vulnerability: While administrators are typically able to run arbitrary scripts, other users are not.
Script execution protected by wrong permission lists issues that allow users with Overall/Administer permission to run arbitrary code. In typical Jenkins deployments, Overall/Administer implies Overall/Run Scripts, but in certain situations, such as hosted Jenkins setups, this may not always be the case.
Others collects a number of other issues that don’t fit into either of the previous two categories.
| The announcement blog post for this security advisory provides additional advice how to apply updates. |
All of these allow users with relatively low privileges (like Overall/Read or Job/Configure) to run arbitrary code in Jenkins.
These issues are typically resolved by either requiring approval by an administrator with Overall/Run Scripts permission before executing the script, or by running the script in a sandbox that only allows execution of approved methods.
If you are upgrading any of these plugins to a version containing a fix, and use the affected scripting features, an administrator will typically have to approve entire scripts or approve specific method signatures for these features to resume working (see Script Security Plugin documentation). Meanwhile, certain features may not work as before the upgrade.
JENKINS-28732
This plugin allowed users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM.
This vulnerability has been previously disclosed, and fixed in Active Choices Plugin 1.5.1, independently released by its maintainer in 2016.
SECURITY-457
This plugin allows users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM.
As of publication of this advisory, there is no fix.
SECURITY-494
This plugin allows Jenkins administrators to run arbitrary Groovy code inside the Jenkins JVM to determine whether an application is installed.
This plugin also allowed users with Overall/Read access to Jenkins to invoke a form validation method that allowed them to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
As of publication of this advisory, there is no fix.
SECURITY-294
This plugin allows users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM by configuring a Groovy script to be executed when the build is deleted (labeled Execute a groovy script when the job is deleted).
As of publication of this advisory, there is no fix.
SECURITY-293
Build Flow Plugin implements a DSL for orchestrating a build pipeline. As this DSL is not running in a Sandbox, it allows users with Job/Configure permissions for a Build Flow job to run arbitrary Groovy code inside the Jenkins JVM.
While the Build Flow Plugin does not reconfigure the DSL script when a user without Overall/Run Scripts permission submits the job configuration form, this does not affect other methods of sending an updated job configuration to Jenkins, such as POST config.xml (remote API) or the update-job CLI command.
As of publication of this advisory, there is no fix.
SECURITY-488
This plugin allows Jenkins administrators to run arbitrary Groovy code inside the Jenkins JVM to determine group memberships.
This plugin also allowed users with Overall/Read access to Jenkins to invoke a form validation method that allowed them to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
As of publication of this advisory, there is no fix.
SECURITY-491
This plugin allows Jenkins administrators to run arbitrary Groovy code inside the Jenkins JVM to determine group memberships.
This plugin also allowed users with Overall/Read access to Jenkins to invoke a form validation method that allowed them to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
As of publication of this advisory, there is no fix.
SECURITY-459
CVS Tagging Plugin allows specifying a Groovy GString expression to define the tag for the build.
This allows users with Item/Configure permission to run arbitrary Groovy code inside the Jenkins JVM.
This plugin also allowed users with Overall/Read access to Jenkins to invoke a form validation method that allowed them to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
As of publication of this advisory, there is no fix.
SECURITY-462
Dynamic Parameter Plugin allows users with Job/Configure permission to define scripts to be executed on the Build With Parameters form to determine available parameter values.
This allows users with Item/Configure permission to run arbitrary Groovy code inside the Jenkins JVM.
As of publication of this advisory, there is no fix.
SECURITY-257
The following features allowed users with Item/Configure permission to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts:
Script Trigger - Before Build: As the build starts to determine whether to send an email
Script Trigger - After Build: Once the build finished to determine whether to send an email
Pre-send Script: Run a script before sending email to e.g. determine whether to actually send it.
Post-send Script: Run a script after sending email
Groovy and Jelly templates from workspaces
Since users without permission to access Jenkins, but SCM commit permissions, could affect the contents of Groovy and Jelly templates in project workspaces, that part of this vulnerability extends to users without access to Jenkins.
This has been addressed in Email Extension Plugin version 2.57.2 by integrating with Script Security Plugin.
Global/default pre-send and post-send scripts are automatically approved, so any jobs with $DEFAULT_PRESEND_SCRIPT and $DEFAULT_POSTSEND_SCRIPT will continue to run outside the sandbox.
Custom pre-send and post-send scripts first have their variables expanded, and are then checked for whole-script approval. If they are approved, they run as is, and if not, an attempt is made to run them in the script sandbox.
However, when a job configuration form is submitted, the script is sent for administrator approval verbatim, which means variables are not expanded. Therefore any script containing but not equal to expandable variables will be submitted to script approval, but that approval will not allow them to run. They will always be running in the sandbox. This is a known limitation.
Any template provided by a Jenkins administrator (e.g. in the Jenkins controller’s scripts/ directory) will run as is outside the sandbox.
The behavior of templates loaded from the build’s workspace depends on the type of template:
Jelly-based templates have to be approved by administrators.
Groovy-based templates will be checked for approval, and, unless previously approved, will run in the sandbox.
Script-based triggers are configured to need whole-script approval on upgrading, but users configuring the job can choose to run them in the script sandbox instead.
Classpaths no longer support variables, they need to be paths to files on the Jenkins controller.
Any failures to run these scripts will result in build failures.
To find out whether you’re likely to be impacted by these changes, use these scripts.
SECURITY-256
This plugin allowed users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM by configuring a Groovy script to be executed before a build starts, effectively elevating privileges to Overall/Run Scripts.
The fix for SECURITY-86 previously implemented in Environment Injector Plugin version 1.88 is ineffective, as it only prevents reconfiguring the script via form submission.
Users can still submit a job configuration using POST config.xml or the update-job CLI command.
This has been addressed in Environment Injector Plugin version 2.0 by integrating with Script Security Plugin.
After upgrading the plugin, any previously defined Groovy script will be checked for approval, and submitted for approval if it isn’t, and then attempted to run in the sandbox.
When configuring a job, users can choose to run Environment Injector scripts in the sandbox. If so, the methods called in the script are subject to the Script Security Groovy sandbox. If not, and the user configuring the job is not an administrator, the script will be submitted for approval.
Likewise, custom classpath entries are now also subject to approval.
To find out whether you’re likely to be impacted by these changes, use these scripts.
SECURITY-187
This plugin allowed users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
This vulnerability has been previously disclosed, and fixed in Extended Choice Parameter Plugin version 0.63, independently released by its maintainer in 2016.
SECURITY-123
This plugin allowed users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM by configuring a Groovy script to be executed to determine valid parameter values, effectively elevating privileges to Overall/Run Scripts.
It also allowed users with Overall/Read access to Jenkins to invoke a form validation method that allowed them to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
This has been addressed in Extensible Choice Parameter Plugin version 1.4.0 by integrating with Script Security Plugin.
Existing scripts will be executed in the Groovy sandbox by default after updating the plugin. They can be reconfigured to run outside the sandbox, requiring approval by Jenkins administrators instead.
The pre-defined variable jenkins has been removed.
Scripts requiring it will need to access jenkins.model.Jenkins.getInstance().
This should never be approved for scripts running inside the sandbox.
To find out whether you’re likely to be impacted by these changes, use these scripts.
SECURITY-458
This plugin allows users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM by configuring a Groovy expression for the grails.work.dir option in a job configuration.
As of publication of this advisory, there is no fix.
SECURITY-292
One of the Groovy Plugin’s major features is the ability to run "System Groovy". This allows users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
While the plugin previously did not allow users to interactively configure System Groovy build steps unless they had the Overall/Run Scripts permission, this could be circumvented by using the Remote API or Jenkins CLI.
This has been addressed in Groovy Plugin version 2.0 by integrating with Script Security Plugin.
To find out whether you’re likely to be impacted by these changes, use these scripts.
JENKINS-27535
This plugin allowed users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
This vulnerability has been previously disclosed, and fixed in Groovy Label Assignment Plugin 1.2.0, independently released by its maintainer in 2016.
JENKINS-15212
This plugin allowed users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
This vulnerability has been previously disclosed, and fixed in Groovy Postbuild Plugin 2.0, independently released by its maintainer in 2014.
SECURITY-460
This plugin allows users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
It also allowed users with Overall/Read access to Jenkins to invoke a form validation method that allowed them to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
As of publication of this advisory, there is no fix.
SECURITY-369
This plugin allows users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
Additionally, since the jobDsl Pipeline step was implemented, anyone with commit access to an SCM repository used by Pipeline can run arbitrary Groovy code on a Jenkins instance with this plugin installed.
This has been addressed in Job DSL version 1.60 by integrating with Script Security Plugin. Script security for Job DSL scripts is now enabled by default if Jenkins security is enabled. As a consequence, DSL scripts have either to be approved by an Jenkins administrator or run in an restricted sandbox. Further limitations apply, see the documentation linked below for details. To restore the old behavior, Job DSL script security can be disabled on the "Configure Global Security" page. It is strongly recommended not to do this.
More information:
SECURITY-368
Lockable Resources Plugin allows users with Job/Configure permission to define a label expression to determine the resources to use.
If this label expression starts with groovy: the rest of it is evaluated as a Groovy script inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
This has been addressed in Lockable Resources version 2.0 by integrating with Script Security Plugin.
While this plugin integrates with Pipeline, the vulnerability did not affect this project type.
To find out whether you’re likely to be impacted by these changes, use these scripts.
SECURITY-495
This plugin allows users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM using the Ontrack DSL feature, effectively elevating privileges to Overall/Run Scripts.
As of publication of this advisory, there is no fix.
SECURITY-295
This plugin allows users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
As of publication of this advisory, there is no fix.
SECURITY-489
This plugin allows users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM of the node the build is running on, effectively elevating privileges to Overall/Run Scripts.
As of publication of this advisory, there is no fix.
SECURITY-176
This plugin allows users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM by supplying a Groovy script for the checkpoint label option, effectively elevating privileges to Overall/Run Scripts.
This plugin also allowed users with Overall/Read access to Jenkins to invoke a form validation method that allowed them to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
As of publication of this advisory, there is no fix.
SECURITY-487
This plugin allows users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM by defining a Reactor Script that will be run when a Reactor Event triggers, effectively elevating privileges to Overall/Run Scripts.
As of publication of this advisory, there is no fix.
SECURITY-461
This plugin allows users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
As of publication of this advisory, there is no fix.
SECURITY-456
This plugin allows users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
As of publication of this advisory, there is no fix.
SECURITY-496
Splunk Extension Plugin allows users able to configure a Pipeline to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts. This includes both users with Job/Configure privilege, as well as users with SCM commit access (Pipeline as Code).
As of publication of this advisory, there is no fix.
SECURITY-298
Subversion Tagging Plugin allows specifying a Groovy GString expression to define the tag for the build.
This allows users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
This plugin also allowed users with Overall/Read access to Jenkins to invoke a form validation method that allowed them to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
As of publication of this advisory, there is no fix.
SECURITY-379
This plugin allows users with Job/Configure permission to run arbitrary TCL code inside the Jenkins JVM, effectively elevating that permission to Overall/Run Scripts.
As of publication of this advisory, there is no fix.
SECURITY-405
Warnings Plugin allowed users with Overall/Read access to Jenkins to invoke a form validation method that allowed them to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
This has been addressed in Warnings Plugin 4.61 and the affected form validation methods are now limited to users with Overall/Run Scripts permissions.
SECURITY-464
Youtrack Plugin allowed users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM as part of a Groovy template for a comment to be posted to Youtrack, effectively elevating that permission to Overall/Run Scripts.
As of publication of this advisory, there is no fix.
These vulnerabilities are related to the arbitrary code execution vulnerabilities above in that they allow users with insufficient permissions to run arbitrary code. The difference is that all of these require users to have Overall/Administer permission. In typical Jenkins deployments, Overall/Administer implies Overall/Run Scripts, so there is no difference between the two. These are only an issue in very specific circumstances, typically hosted Jenkins environments.
To determine whether these issues affect you, log into Jenkins as administrator, navigate to Manage Jenkins and look for a link titled Script Console. If it exists, you also have Overall/Run Scripts permission.
SECURITY-296
Claim Plugin 2.6 and newer allows Jenkins administrators to run arbitrary Groovy code inside the Jenkins JVM to be executed whenever a claim is changed.
This mistakes the Overall/Administer permission for the Overall/Run Scripts permission. For most Jenkins instances, there is no difference between the two, but hosted Jenkins services may be configured to only grant the former, but not the latter.
As of publication of this advisory, there is no fix.
SECURITY-492
Extreme Notification Plugin allows administrators to run arbitrary Groovy code inside the Jenkins JVM as part of notifications.
This mistakes the Overall/Administer permission for the Overall/Run Scripts permission. For most Jenkins instances, there is no difference between the two, but hosted Jenkins services may be configured to only grant the former, but not the latter.
As of publication of this advisory, there is no fix.
SECURITY-367
Scriptler Plugin allows administrators to run arbitrary Groovy code inside the Jenkins JVM.
This mistakes the Overall/Administer permission for the Overall/Run Scripts permission. For most Jenkins instances, there is no difference between the two, but hosted Jenkins services may be configured to only grant the former, but not the latter.
Additionally, the plugin recommends granting non-admin users the Overall/Run Scripts permission to be able to run specific, preconfigured scripts. This mistakes Overall/Run Scripts for a lesser permission than Overall/Administer.
As of publication of this advisory, there is no fix.
SECURITY-493
Shared Objects Plugin allows administrators to run arbitrary Groovy code inside the Jenkins JVM.
This mistakes the Overall/Administer permission for the Overall/Run Scripts permission. For most Jenkins instances, there is no difference between the two, but hosted Jenkins services may be configured to only grant the former, but not the latter.
As of publication of this advisory, there is no fix.
SECURITY-479
Splunk Plugin allows administrators to run arbitrary Groovy code inside the Jenkins JVM.
This mistakes the Overall/Administer permission for the Overall/Run Scripts permission. For most Jenkins instances, there is no difference between the two, but hosted Jenkins services may be configured to only grant the former, but not the latter.
As of publication of this advisory, there is no fix.
SECURITY-297
Warnings Plugin allows administrators to run arbitrary Groovy code inside the Jenkins JVM as part of custom warning parsers.
This mistakes the Overall/Administer permission for the Overall/Run Scripts permission. For most Jenkins instances, there is no difference between the two, but hosted Jenkins services may be configured to only grant the former, but not the latter.
This has been addressed in Warnings Plugin version 4.61 by integrating with Script Security Plugin.
Custom warning parsers are now subject to the Script Security sandbox, and methods used there need to be added to the list of approved signatures before they can be used.
To find out whether you’re likely to be impacted by these changes, use these scripts.
These issues fit in neither of the previous two categories.
SECURITY-333
Administrators are able to submit arbitrary HTML as description of Scriptler scripts that are shown verbatim to other administrators, allowing cross-site scripting attacks.
As of publication of this advisory, there is no fix.
SECURITY-334
None of the script management functionality in Scriptler requires POST access, and is therefore vulnerable to CSRF exploits even with CSRF protection enabled in the Jenkins global security configuration.
As of publication of this advisory, there is no fix.
SECURITY-365
Scriptler plugin lets users with Overall/Run Scripts or Overall/Administer permission add Scriptler script executions to job configurations. Users without these permissions are not supposed to be able to add this build step to jobs.
The protection mechanism used only affects submission of job configuration forms through the UI and can be circumvented e.g. by sending POST config.xml requests.
As of publication of this advisory, there is no fix.
SECURITY-366
Scriptler Plugin executes any Scriptler scripts specified for the Scriptler build step in job configurations even though it is documented to only allow specific scripts to be included.
Users can therefore POST config.xml or use a similar approach to submit a job configuration containing a script that is not available from the UI.
Additionally, jobs configured through the UI will continue to run specified scripts even after they have been reconfigured to not allow this inclusion.
As of publication of this advisory, there is no fix.
SECURITY-348
Environment Injector Plugin allowed users with Job/Configure permission to include properties files containing an environment definition from the Jenkins controller.
This also allowed loading contents of files in other formats than Java properties files, with (parts of) the content made available as environment variables to subsequent build steps. This could be used to access secret information on the Jenkins controller file system.
This has been addressed in Environment Injector Plugin 2.0.
The plugin now has a new global option to enable file loading from the Jenkins controller. It is disabled by default.
If disabled, any job previously configured to load a file from the Jenkins controller will fail. Once the option in the job has been unset, it’s also removed from the UI so it cannot (accidentally) be enabled again.
If enabled, the behavior is as before. This is strongly discouraged.
SECURITY-363
Job DSL plugin allowed users with the ability to edit Job DSL scripts in Jenkins or SCM to bypass permission checks. This included the following:
Redefining all existing items (jobs) without appropriate Item/Read and Item/Configure permission.
Deleting existing items (jobs) without Item/Delete permission.
Reading item (job) configurations without Item/ExtendedRead permission.
Reading files from any workspace without Item/Workspace permission.
Starting builds without Item/Build permission.
Creating new new items (jobs) without Item/Create permission.
Redefining views without View/Read or View/Configure permission.
Creating views without View/Create permission.
Creating or modifying /userContent directory contents without Overall/Administer permission.
Creating or updating config files from Config File Provider Plugin without Overall/Administer permission.
The list above may not be exhaustive.
This has been addressed in Job DSL Plugin 1.60.
Actions performing Jenkins model access or modification now perform permission checks.
By default, Jenkins executes all builds as the SYSTEM user with all permissions, but plugins such as Authorize Project allow configuring different build authorizations.
After installing Authorize Project plugin, you will find Access Control for Builds in Manage Jenkins » Configure Global Security. Adding Project default Build Authorization or Per-project configurable Build Authorization enables the Authorize Project plugin.
Choosing Per-project configurable Build Authorization allows the authentication that a job will run as to be configured from the job configuration page. A new side bar menu Authorization will appear in job pages where different strategies can be selected.
More information about this, including how the various options affect Job DSL, can be found in the plugin documentation:
SECURITY-410
The Matrix Authorization Strategy Plugin allowed configuring the following permissions independently from Overall/Administer:
Overall/Run Scripts
Overall/Upload Plugins
Overall/Configure Update Center
This gave the impression that these permissions are less powerful than Overall/Administer when the opposite is actually the case. Jenkins just grants these permissions to anyone who has Overall/Administer by default for historical reasons, when in fact, these permissions are intended to be removed from administrators (in specific circumstances, and with plugins allowing to do this) rather than granted to non-administrators.
Administrators unaware of the exact meaning of these permissions may inadvertently grant them to users who are not trusted to be administrators.
This has been addressed in Matrix Authorization Strategy Plugin 1.5.
If none of the affected permissions were granted to users who aren’t also granted the Overall/Administer permission before updating, the UI for doing so is hidden, and there are no behavior changes.
If any of the affected permissions were granted to users who aren’t also granted the Overall/Administer permission before updating, the UI for doing so remains unchanged, the the plugin will only grant these permissions to users who also have Overall/Administer. Additionally, an administrative monitor will inform administrators about this possible misconfiguration. If the additional permissions are then removed from the affected non-admin users, the columns for these permissions will no longer be shown.
If you want to retain the old, unsafe behavior, set the system property hudson.security.GlobalMatrixAuthorizationStrategy.dangerousPermissions to true.
The plugin retains permissions configured before upgrading, so there should be no changes in behavior afterwards.
SECURITY-410
The Role-based Authorization Strategy Plugin allowed configuring the following permissions independently from Overall/Administer:
Overall/Run Scripts
Overall/Upload Plugins
Overall/Configure Update Center
This gave the impression that these permissions are less powerful than Overall/Administer when the opposite is actually the case. Jenkins just grants these permissions to anyone who has Overall/Administer by default for historical reasons, when in fact, these permissions are intended to be removed from administrators (in specific circumstances, and with plugins allowing to do this) rather than granted to non-administrators.
Administrators unaware of the exact meaning of these permissions may inadvertently grant them to users who are not trusted to be administrators.
This has been addressed in Role-based Authorization Strategy Plugin 2.4.0.
If none of the affected permissions were granted to users who aren’t also granted the Overall/Administer permission before updating, the UI for doing so is hidden, and there are no behavior changes.
If any of the affected permissions were granted to users who aren’t also granted the Overall/Administer permission before updating, the UI for doing so remains unchanged, the the plugin will only grant these permissions to users who also have Overall/Administer. Additionally, an administrative monitor will inform administrators about this possible misconfiguration. If the additional permissions are then removed from the affected non-admin users, the columns for these permissions will no longer be shown.
If you want to retain the old, unsafe behavior, set the system property org.jenkinsci.plugins.rolestrategy.permissions.DangerousPermissionHandlingMode.enableDangerousPermissions to true.
The plugin retains permissions configured before upgrading, so there should be no changes in behavior afterwards.
SECURITY-123: high
SECURITY-176: high
SECURITY-187: high
SECURITY-256: high
SECURITY-257: high
SECURITY-292: high
SECURITY-293: high
SECURITY-294: high
SECURITY-295: high
SECURITY-296: high
SECURITY-297: high
SECURITY-298: high
SECURITY-333: medium
SECURITY-334: high
SECURITY-348: medium
SECURITY-363: high
SECURITY-365: high combined with SECURITY-367
SECURITY-366: medium
SECURITY-367: high combined with SECURITY-365
SECURITY-368: high
SECURITY-369: critical
SECURITY-379: high
SECURITY-405: high
SECURITY-410: hardening
SECURITY-456: high
SECURITY-457: high
SECURITY-458: high
SECURITY-459: high
SECURITY-460: high
SECURITY-461: high
SECURITY-462: high
SECURITY-464: high
SECURITY-479: high
SECURITY-487: high
SECURITY-488: high
SECURITY-489: high
SECURITY-491: high
SECURITY-492: high
SECURITY-493: high
SECURITY-494: high
SECURITY-495: high
SECURITY-496: critical
JENKINS-15212: high
JENKINS-27535: high
JENKINS-28732: high
Active Choices up to and including version 1.4
Adaptive DSL (all versions)
Application Detector (all versions)
Artifact Deployer (all versions)
Build Flow (all versions)
CAS protocol version 1 (all versions)
CAS (all versions)
Claim (all versions)
CVS Tagging (all versions)
Dynamic Parameter (all versions)
Email Extension (Email-ext) up to and including version 2.57.1
Environment Injector (EnvInject) up to and including version 1.93.1
Extended Choice Parameter up to and including version 0.61
Extensible Choice Parameter up to and including version 1.3.4
Extreme Notification (all versions)
Grails (all versions)
Groovy up to and including version 1.31
Groovy Label Assignment up to and including version 1.1.1
Groovy Postbuild up to and including version 1.10
GroovyAxis (all versions)
Job DSL up to and including version 1.59
Lockable Resources up to and including version 1.11.2
Matrix Authorization Strategy up to and including version 1.4
Ontrack (all versions)
Post-Build Script (all versions)
Process Cleaner (all versions)
PTC Integrity CM (all versions)
Reactor (all versions)
Role-based Authorization Strategy up to and including version 2.3.2
Script SCM (all versions)
Scriptler (all versions)
scripttrigger (all versions)
Shared Objects (all versions)
Splunk (all versions)
Splunk Extension (all versions)
Subversion Tagging (all versions)
tcl (all versions)
Warnings up to and including version 4.60
youtrack-plugin (all versions)
| For plugins affected by scripting vulnerabilities, upgrading them to releases containing fixes will necessarily require administrators to approve the scripts or specific method signatures used. Builds may fail or otherwise misbehave. Upgrades of these plugins should be performed with this issue in mind if you are using the affected features. |
Fixes have been released for the following plugins:
Active Choices (uno-choice) Plugin should be updated to version 1.5.1 or newer. As this plugin depends on Scriptler, whose distribution has been suspended, you need to download this plugin from the Jenkins project Maven repository and upload it to Jenkins.
Email Extension (Email-ext) Plugin should be updated to version 2.57.2.
Environment Injector (EnvInject) Plugin should be updated to version 2.0.
Extended Choice Parameter Plugin should be updated to version 0.63 or newer.
Extensible Choice Parameter Plugin should be updated to version 1.4.0.
Groovy Label Assignment Plugin should be updated to version 1.2.0 or newer.
Groovy Plugin should be updated to version 2.0.
Groovy Postbuild Plugin should be updated to version 2.0 or newer.
Job DSL Plugin should be updated to version 1.60.
Lockable Resources Plugin should be updated to version 2.0.
Matrix Authorization Strategy Plugin should be updated to version 1.5.
Role-based Authorization Strategy Plugin should be updated to version 2.4.0.
Warnings Plugin should be updated to version 4.61, and its dependency Static Analysis Plugins to version 1.85.
Listed versions include fixes to the vulnerabilities described above. All prior versions containing the affected features are considered affected by these vulnerabilities unless otherwise noted.
Plugins not listed above have not been fixed in time for this security advisory. The Jenkins wiki tracks the current state of these plugins.
The Jenkins project would like to thank the following people for discovering and reporting these vulnerabilities:
Burak Kelebek for SECURITY-333
Daniel Beck, CloudBees, Inc. for SECURITY-123, SECURITY-176, SECURITY-256, and SECURITY-257
Jesse Glick, CloudBees, Inc. for SECURITY-348
Nedyalko Andreev for SECURITY-187