Child pages
  • Plugins affected by fix for SECURITY-170

Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata


In a May 2016 security advisory, a vulnerability was announced (SECURITY-170 / CVE-2016-3721) whereby attackers could potentially exploit the fact that certain Jenkins plugins allow the definition of arbitrary build parameters — which are in turn injected into the build envirionment.

The fix for this issue — which was first included in Jenkins versions 1.651.2 and Jenkins 2.3 — means that only build parameters that have been explicitly defined in a job's configuration will be available by default at build time. Any other arbitrary parameters added to a build by plugins will not be available by default.

As there are a number of plugins that rely on the behaviour in older Jenkins versions, upgrading to 1.651.2 or 2.3 means that certain build behaviours may be broken.

This page attempts to list the affected plugins, how the plugin behaves in current versions of Jenkins, and whether those plugins have been fixed to work with the new parameter filtering behaviour of Jenkins.


Note that there are a couple of global workarounds to either turn off the new parameter-filtering behaviour, or to whitelist certain parameter names, preventing them from being filtered out.

These are described in the security advisory and in the accompanying blog post.

Affected plugins

Note that this list is not exhaustive. If you encounter a plugin that no longer works as expected due to the fix for SECURITY-170, please add it to the list.
More importantly, please file a bug report, if one doesn't exist, to help ensure that the appropriate plugin maintainer is informed.

Some items here include a list of the parameter names that they use, which could be added to the whitelist mentioned in the "Workarounds" section above.

Plugin name




Assembla Merge Request Builder Plugin

Parameters are stripped unless defined.

 Parameter names used



PR - fixed in 1.1.4

CloudBees Docker Hub Notification



Fixed in 2.1.0 (fix)

Delivery Pipeline Plugin

PIPELINE_VERSION doesn't get created


PR - fixed in 0.9.12

Gearman Plugin

Parameters are stripped unless defined. Should be made to autowhitelist.


Not fixed

Gerrit Trigger

Builds fail with message "stderr: fatal: Couldn't find remote ref $GERRIT_REFSPEC"

 Parameter names used



PR - fixed in 2.21.0

GitHub Pull Request Builder Plugin

If using the standard ${sha1} branch spec, builds will fail with "Couldn't find any revision to build".
Pull requests remain in the "pending" state as the plugin fails to update the PR with the build outcome

 Parameter names used



Fixed in 1.32.3 (fix)
Fix removed from 1.32.2
Tentative fix in 1.32.1 (fix)

HP Application Automation Tools

HP_RUN_ID not available to subsequent build steps.


Not fixed

Inheritance Plugin

Parameters defined on a `super` project are not expanded in a derived project


Not fixed

Job Generator Plugin

Parameters aren't passed to child jobs


Not fixed

Lockable Resources Plugin

Reserved resources variable name will not pass to the build


PR - fixed in 1.9

Matrix Project Plugin

Parameters defined on a project are not passed to child jobs


PR - fixed in 1.7

Parameterized Trigger Plugin

Parameters (e.g. when using properties files as source) are only passed if they are defined on the downstream job. This is the behavior intended by the SECURITY-170, see Jenkins Security Advisory 2016-05-11


Won't fix (hopefully)

Poll Mailbox Trigger Plugin

pmt_* job parameters are no longer injected into the job. e.g. pmt_from, pmt_replyTo, pmt_content, etc


Fixed in 1.024 (fix)

Promoted Builds Plugin

Promoted builds do not receive parameter values defined at the job level


Fixed in 2.27 (fix)

Release Plugin

Release parameters are not passed to the build


PR - fixed in 2.6

Stash PullRequest Builder Plugin

Builds will fail with "Couldn't find any revision to build".
As this plugin accepts arbitrary parameters, it's one of the plugins that caused SECURITY-170.

 Parameter names used



Fixed in 1.7.0 - PR

P4 Plugin

Parameters generated for review builds are not passed.

 Parameter names used

json, review, change, status, pass,
fail, label, Submit

Note that there may be more missing parameters for other special build types.



M2 Release Plugin

SCM username and password environment variables, if configured, are not set


Not fixed

Multijob Plugin (tikal-multijob-plugin)

see description in JENKINS-36124


Fixed in 1.22 (fix)

Repository Connector Plugin

Artifact version chosen does not get set.


Not fixed. PR pending

Maven Metadata Plugin

The following parameters do not get passed on from parent to child jobs in Matrix Project Plugin. Version 1.7 (May 24, 2016)
 Version 1.7 broke the ability to pass these parameters to child jobs.JENKINS-34758 Parameters visibility in child builds (related to SECURITY-170)



Not fixed

  • No labels


  1. Unknown User (grayaii)

    Whoa! I usually assume it's pretty safe going from one minor version of an LTS to another, but going from 1.651.1 to 1.652.2 COMPLETELY breaks all of our builds.

    Rather than saying "security fixes" in this update:, something along the lines in BOLD LETTERS:

    Upgrading to 1.652.2 COMPLETELY breaks your builds if you use the plugins listed on this page.

    1. Unknown User (15knots)

      Yes, having broken builds as a sudden is annoying.
      At least, the newest version gives you a chance to apply workarounds, it gives you a choice.

      But what, if your Jenkins instance starts to produce end-user install packages containing viruses/trojans/ransomware and these get delivered? I would not call that annoying.

  2. Unknown User (tommysdk)

    Where do you find the parent org.jenkins-ci.plugins:plugin artifact with version corresponding to 1.651.2 which contains the security fix? I can't find it when looking through

  3. Unknown User (bhicks)

    So on this page,,  you claim that a workaround can be put in place to revert back to old behavior. You even mention what needs to be changed to do so: "it's possible to restore the previous behavior by setting the system property hudson.model.ParametersAction.keepUndefinedParameters to true." But do you explain where to make that change? Nope, not a chance. Now I have to look into restoring the VM which my Jenkins server runs on so I can get Jenkins back to the version before this upgrade AND I have to look into alternatives to the Jenkins server. Thanks, really. Thank you very much.

    Edit: I found where to make this modification on a Windows server running Jenkins as a service. By default Jenkins installs to C:\Program Files (x86)\Jenkins, so open that directory, then open jenkins.xml. It should be fairly obvious as this text file is small, but somewhere around lines 40-41 should be the <arguments> string which is passed to java.exe to start & run Jenkins. 

    Example from jenkins.xml:

    Original: <arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "%BASE%\jenkins.war" --httpPort=-1 --httpsPort=443 </arguments>

    Modified: <arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -Dhudson.model.ParametersAction.keepUndefinedParameters=true -jar "%BASE%\jenkins.war" --httpPort=-1 --httpsPort=443 </arguments>

  4. Unknown User (killdash9)

    Yeah - this took us down for 24 hours. Frustrating. Took us a while to find the issue. Also, keepUndefinedParameters=true did not work for us. Ended up rolling back. This was a bad one.

  5. Unknown User (jimklimov)

    We use a successfully (it works), with a build somewhat newer than the official Git head (so including the fix above for 1.7.0), however error messages are logged about passing variables into the build which are not the job's official build arguments. As one corollary, we also can not quickly "Rebuild with Arguments" the same job setup, though in case of this plugin it is just an annoyance - rescheduling a PR build goes via posting comments to the PR in Stash.

    In fact, there still was a practical problem: those warnings swamped our Jenkins master log partition on one occasion faster than the logs were rotated away, causing a server outage, so then we've seen them and set an appropriate `-Dhudson.model.ParametersAction....` into the configuration (`/etc/sysconfig/jenkins` in our Unix/Linux case).