HTTP/2 Rapid reset attack The HTTP/2 protocol allows clients to indicate to the server that a previous stream should be canceled by sending a RSTSTREAM frame. The protocol does not require the client and server to coordinate the cancellation in any way, the client may do it unilaterally. The client may also assume that the cancellation will take effect immediately when the server receives the RSTSTREAM frame, before any other data from that TCP connection is processed.

Abuse of this feature is called a Rapid Reset attack because it relies on the ability for an endpoint to send a RSTSTREAM frame immediately after sending a request frame, which makes the other endpoint start working and then rapidly resets the request. The request is canceled, but leaves the HTTP/2 connection open.

The HTTP/2 Rapid Reset attack built on this capability is simple: The client opens a large number of streams at once as in the standard HTTP/2 attack, but rather than waiting for a response to each request stream from the server or proxy, the client cancels each request immediately.

The ability to reset streams immediately allows each connection to have an indefinite number of requests in flight. By explicitly canceling the requests, the attacker never exceeds the limit on the number of concurrent open streams. The number of in-flight requests is no longer dependent on the round-trip time (RTT), but only on the available network bandwidth.

In a typical HTTP/2 server implementation, the server will still have to do significant amounts of work for canceled requests, such as allocating new stream data structures, parsing the query and doing header decompression, and mapping the URL to a resource. For reverse proxy implementations, the request may be proxied to the backend server before the RSTSTREAM frame is processed. The client on the other hand paid almost no costs for sending the requests. This creates an exploitable cost asymmetry between the server and the client.

Multiple software artifacts implementing HTTP/2 are affected. This advisory was originally ingested from the swift-nio-http2 repo advisory and their original conent follows.

swift-nio-http2 specific advisory swift-nio-http2 is vulnerable to a denial-of-service vulnerability in which a malicious client can create and then reset a large number of HTTP/2 streams in a short period of time. This causes swift-nio-http2 to commit to a large amount of expensive work which it then throws away, including creating entirely new Channels to serve the traffic. This can easily overwhelm an EventLoop and prevent it from making forward progress.

swift-nio-http2 1.28 contains a remediation for this issue that applies reset counter using a sliding window. This constrains the number of stream resets that may occur in a given window of time. Clients violating this limit will have their connections torn down. This allows clients to continue to cancel streams for legitimate reasons, while constraining malicious actors.

Jenkins 2.587 and earlier, LTS 2.580.1 and earlier provides an HTTP endpoint that loads agents by name without validating the name, allowing attackers with Overall/Read permission to load any config.xml file on the controller file system as an agent configuration, and to overwrite an arbitrary config.xml file when that agent is saved, potentially resulting in arbitrary code execution.

A cross-site request forgery (CSRF) vulnerability in Jenkins Subversion Plugin 2.15.3 and earlier allows attackers to connect to an attacker-specified URL.

A flaw was found in the Jenkins Subversion plugin. The Jenkins subversion plugin does not escape the name and description of List Subversion tags and parameters on views displaying the parameters. This issue results in a stored Cross-site scripting (XSS) vulnerability, exploitable by attackers with Item/Configure permission.

Jenkins Subversion Plugin 2.15.0 and earlier does not restrict the name of a file when looking up a subversion key file on the controller from an agent.

A flaw was found in the subversion Jenkins plugin. The XML parser is not properly configured to prevent XML external entity (XXE) attacks allowing an attacker the ability to control an agent process and have Jenkins parse a crafted changelog file that uses external entities for extraction of secrets from the Jenkins controller or server-side request forgery. The highest threat from this vulnerability is to data confidentiality.

Jenkins Subversion Plugin 2.13.0 and earlier does not escape the error message for the Project Repository Base URL field form validation, resulting in a stored cross-site scripting vulnerability.

An improper authorization vulnerability exists in Jenkins Subversion Plugin version 2.10.2 and earlier in SubversionStatus.java and SubversionRepositoryStatus.java that allows an attacker with network access to obtain a list of nodes and users. As of version 2.10.3, the class handling requests to /subversion/ no longer extends the class handling requests to the …/search/ sub-path, therefore any such requests will fail.

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.

Jenkins Kubernetes Plugin 3909.v1f2c633e8590 and earlier does not properly mask (i.e., replace with asterisks) credentials in the build log when push mode for durable task logging is enabled.

Jenkins Git Plugin 4.11.4 and earlier does not properly mask (i.e., replace with asterisks) credentials in the build log provided by the Git Username and Password (gitUsernamePassword) credentials binding.

Git Plugin provides a webhook endpoint at /git/notifyCommit that can be used to notify Jenkins of changes to an SCM repository. For its most basic functionality, this endpoint receives a repository URL, and Jenkins will schedule polling for all jobs configured with the specified repository. In Git Plugin 4.11.3 and earlier, this endpoint can be accessed with GET requests and without authentication. In addition to this basic functionality, the endpoint also accept a sha1 parameter specifying a commit ID. If this parameter is specified, jobs configured with the specified repo will be triggered immediately, and the build will check out the specified commit. Additionally, the output of the webhook endpoint will provide information about which jobs were triggered or scheduled for polling, including jobs the user has no permission to access. This allows attackers with knowledge of Git repository URLs to trigger builds of jobs using a specified Git repository and to cause them to check out an attacker-specified commit, and to obtain information about the existence of jobs configured with this Git repository. Additionally, this webhook endpoint does not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability. Git Plugin 4.11.4 requires a token parameter which will act as an authentication for the webhook endpoint. While GET requests remain allowed, attackers would need to be able to provide a webhook token. For more information see the plugin documentation.

A missing permission check in Jenkins Git Plugin 4.11.3 and earlier allows unauthenticated attackers to trigger builds of jobs configured to use an attacker-specified Git repository and to cause them to check out an attacker-specified commit.

Jenkins Git Plugin 4.11.1 and earlier allows attackers able to configure pipelines to check out some SCM repositories stored on the Jenkins controller's file system using local paths as SCM URLs, obtaining limited information about other projects' SCM contents.

Jenkins Git Plugin 4.8.2 and earlier does not escape the Git SHA-1 checksum parameters provided to commit notifications when displaying them in a build cause, resulting in a stored cross-site scripting (XSS) vulnerability.

Jenkins Git Plugin 4.2.0 and earlier does not escape the error message for the repository URL for Microsoft TFS field form validation resulting in a stored cross-site scripting vulnerability.

A cross-site request forgery vulnerability exists in Jenkins Git Plugin 3.9.1 and earlier

A server-side request forgery vulnerability exists in Jenkins Git Plugin 3.9.0 and older in AssemblaWeb.java, GitBlitRepositoryBrowser.java, Gitiles.java, TFS2013GitRepositoryBrowser.java, ViewGitWeb.java that allows attackers with Overall/Read access to cause Jenkins to send a GET request to a specified URL.

An improper authorization vulnerability exists in Jenkins Git Plugin version 3.7.0 and earlier in GitStatus.java that allows an attacker with network access to obtain a list of nodes and users.

A cross-site request forgery vulnerability in Jenkins Ansible Tower Plugin 0.9.1 and earlier in the TowerInstallation.TowerInstallationDescriptor#doTestTowerConnection form validation method allowed attackers permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins

An exposure of sensitive information vulnerability exists in Jenkins SaltStack Plugin 3.1.6 and earlier in SaltAPIBuilder.java, SaltAPIStep.java that allows attackers to capture credentials with a known credentials ID stored in Jenkins.

A missing permission check in Jenkins Ansible Tower Plugin 0.9.1 and earlier in the TowerInstallation.TowerInstallationDescriptor#doFillTowerCredentialsIdItems method allowed attackers with Overall/Read permission to enumerate credentials ID of credentials stored in Jenkins.

A missing permission check in Jenkins Ansible Tower Plugin 0.9.1 and earlier in the TowerInstallation.TowerInstallationDescriptor#doTestTowerConnection form validation method allowed attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

A data modification vulnerability exists in Jenkins Resource Disposer Plugin 0.11 and earlier in AsyncResourceDisposer.java that allows attackers to stop tracking a resource.

A cross-site request forgery vulnerability exists in Jenkins vSphere Plugin 2.16 and older in Clone.java, CloudSelectorParameter.java, ConvertToTemplate.java, ConvertToVm.java, Delete.java, DeleteSnapshot.java, Deploy.java, ExposeGuestInfo.java, FolderVSphereCloudProperty.java, PowerOff.java, PowerOn.java, Reconfigure.java, Rename.java, RenameSnapshot.java, RevertToSnapshot.java, SuspendVm.java, TakeSnapshot.java, VSphereBuildStepContainer.java, vSphereCloudProvisionedSlave.java, vSphereCloudSlave.java, vSphereCloudSlaveTemplate.java, VSphereConnectionConfig.java, vSphereStep.java that allows attackers to perform form validation related actions, including sending numerous requests to the configured vSphere server, potentially resulting in denial of service, or send credentials stored in Jenkins with known ID to an attacker-specified server ("test connection").

A cross-site request forgery vulnerability exists in Jenkins vSphere Plugin 2.16 and older in Clone.java, CloudSelectorParameter.java, ConvertToTemplate.java, ConvertToVm.java, Delete.java, DeleteSnapshot.java, Deploy.java, ExposeGuestInfo.java, FolderVSphereCloudProperty.java, PowerOff.java, PowerOn.java, Reconfigure.java, Rename.java, RenameSnapshot.java, RevertToSnapshot.java, SuspendVm.java, TakeSnapshot.java, VSphereBuildStepContainer.java, vSphereCloudProvisionedSlave.java, vSphereCloudSlave.java, vSphereCloudSlaveTemplate.java, VSphereConnectionConfig.java, vSphereStep.java that allows attackers to perform form validation related actions, including sending numerous requests to the configured vSphere server, potentially resulting in denial of service, or send credentials stored in Jenkins with known ID to an attacker-specified server ("test connection").

Jenkins project Jenkins AWS CodeDeploy Plugin version 1.19 and earlier contains a File and Directory Information Exposure vulnerability in AWSCodeDeployPublisher.java that can result in Disclosure of environment variables. This vulnerability appears to have been fixed in 1.20 and later.

Jenkins project Jenkins AWS CodeDeploy Plugin version 1.19 and earlier contains a File and Directory Information Exposure vulnerability in AWSCodeDeployPublisher.java that can result in Disclosure of environment variables. This vulnerability appears to have been fixed in 1.20 and later.

An arbitrary file write vulnerability in Jenkins Cobertura Plugin 1.15 and earlier allows attackers able to control the coverage report file contents to overwrite any file on the Jenkins master file system.

Jenkins Upload to pgyer Plugin stores credentials unencrypted in job config.xml files on the Jenkins master where they can be viewed by users with Extended Read permission, or access to the master file system.