On Darwin, user's trust preferences for root certificates were not honored. If the user had a root certificate loaded in their Keychain that was explicitly not trusted, a Go program would still verify a connection using that root certificate.

Arbitrary code execution due to incomplete sandbox protection: Constructors, instance variable initializers, and instance initializers in Pipeline scripts were not subject to sandbox protection, and could therefore execute arbitrary code. This could be exploited e.g. by regular Jenkins users with the permission to configure Pipelines in Jenkins, or by trusted committers to repositories containing Jenkinsfiles.

The default whitelist included the following unsafe entries: DefaultGroovyMethods.putAt(Object, String, Object); DefaultGroovyMethods.getAt(Object, String). These allowed circumventing many of the access restrictions implemented in the script sandbox by using e.g. currentBuild['rawBuild'] rather than currentBuild.rawBuild. Additionally, the following entries allowed accessing private data that would not be accessible otherwise due to script security: groovy.json.JsonOutput.toJson(Closure); groovy.json.JsonOutput.toJson(Object).

Docker Commons Plugin provides a list of applicable credential IDs to allow users configuring a job to select the one they'd like to use to authenticate with a Docker Registry. This functionality did not check permissions, allowing any user with Overall/Read permission to get a list of valid credentials IDs. Those could be used as part of an attack to capture the credentials using another vulnerability.

Poll SCM Plugin was not requiring requests to its API be sent via POST, thereby opening itself to Cross-Site Request Forgery attacks. This allowed attackers to initiate polling of projects with a known name. While Jenkins in general does not consider polling to be a protection-worthy action as it's similar to cache invalidation, the plugin specifically adds a permission to be able to use this functionality, and this issue undermines that permission.

Git Plugin connects to a user-specified Git repository as part of form validation. An attacker with no direct access to Jenkins but able to guess at a username/password credentials ID could trick a developer with job configuration permissions into following a link with a maliciously crafted Jenkins URL which would result in the Jenkins Git client sending the username and password to an attacker-controlled server.

GitHub Branch Source Plugin connects to a user-specified GitHub API URL (e.g. GitHub Enterprise) as part of form validation and completion (e.g. to verify Scan Credentials are correct). This functionality improperly checked permissions, allowing any user with Overall/Read access to Jenkins to connect to any web server and send credentials with a known ID, thereby possibly capturing them. Additionally, this functionality did not require POST requests be used, thereby allowing the above to be performed without direct access to Jenkins via Cross-Site Request Forgery.

Role-based Authorization Strategy Plugin was not requiring requests to its API be sent via POST, thereby opening itself to Cross-Site Request Forgery attacks. This allowed attackers to add administrator role to any user, or to remove the authorization configuration, preventing legitimate access to Jenkins.

Builds in Jenkins are associated with an authentication that controls the permissions that the build has to interact with other elements in Jenkins. The Pipeline: Build Step Plugin did not check the build authentication it was running as and allowed triggering any other project in Jenkins.

The Sidebar Link plugin allows users able to configure jobs, views, and agents to add entries to the sidebar of these objects. There was no input validation, which meant users were able to use javascript: schemes for these links.

GitHub Branch Source provides a list of applicable credential IDs to allow users configuring a job to select the one they'd like to use. This functionality did not check permissions, allowing any user with Overall/Read permission to get a list of valid credentials IDs. Those could be used as part of an attack to capture the credentials using another vulnerability.

The Periodic Backup Plugin did not perform any permission checks, allowing any user with Overall/Read access to change its settings, trigger backups, restore backups, download backups, and also delete all previous backups via log rotation. Additionally, the plugin was not requiring requests to its API be sent via POST, thereby opening itself to Cross-Site Request Forgery attacks.

Subversion Plugin connects to a user-specified Subversion repository as part of form validation (e.g. to retrieve a list of tags). This functionality improperly checked permissions, allowing any user with Item/Build permission (but not Item/Configure) to connect to any web server or Subversion server and send credentials with a known ID, thereby possibly capturing them. Additionally, this functionality did not require POST requests be used, thereby allowing the above to be performed without direct access to Jenkins via Cross-Site Request Forgery attacks.

Parameterized Trigger Plugin fails to check Item/Build permission: The Parameterized Trigger Plugin did not check the build authentication it was running as and allowed triggering any other project in Jenkins.

In Jboss Application Server as shipped with Red Hat Enterprise Application Platform 5.2, it was found that the doFilter method in the ReadOnlyAccessFilter of the HTTP Invoker does not restrict classes for which it performs deserialization and thus allowing an attacker to execute arbitrary code via crafted serialized data.

In Apache Impala (incubating) before 2.10.0, a malicious user with "ALTER" permissions on an Impala table can access any other Kudu table data by altering the table properties to make it "external" and then changing the underlying table mapping to point to other Kudu tables. This violates and works around the authorization requirement that creating a Kudu external table via Impala requires an "ALL" privilege at the server scope. This privilege requirement for "CREATE" commands is enforced to precisely avoid this scenario where a malicious user can change the underlying Kudu table mapping. The fix is to enforce the same privilege requirement for "ALTER" commands that would make existing non-external Kudu tables external.

In Cloud Foundry capi-release versions 1.33.0 and later, prior to 1.42.0 and cf-release versions 268 and later, prior to 274, the original fix for CVE-2017-8033 introduces an API regression that allows a space developer to execute arbitrary code on the Cloud Controller VM by pushing a specially crafted application. NOTE: 274 resolves the vulnerability but has a serious bug that is fixed in 275.

In Cloud Foundry router routing-release all versions prior to v0.163.0 and cf-release all versions prior to v274, in some applications, it is possible to append a combination of characters to the URL that will allow for an open redirect. An attacker could exploit this as a phishing attack to gain access to user credentials or other sensitive data. NOTE: 274 resolves the vulnerability but has a serious bug that is fixed in 275.

A flaw in the AIX 5.3, 6.1, 7.1, and 7.2 JRE/SDK installp and updatep packages prevented the java.security, java.policy and javaws.policy files from being updated correctly. IBM X-Force ID: 130809.

The named pipes in qtsingleapp in Qt 5.x, as used in qBittorrent and SugarSync, are configured for remote access and allow remote attackers to cause a denial of service (application crash) via an unspecified string.