VulnerableCode Package Details - pkg:rpm/redhat/jenkins@2.277.3.1620393611-1?arch=el8

Search for packages

Vulnerability	Summary	Fixed by
VCID-9prj-5zwe-7kc5 Aliases: CVE-2021-21639 GHSA-pvwx-3jx5-24r2	Lack of type validation in agent related REST API in Jenkins Jenkins 2.286 and earlier, LTS 2.277.1 and earlier does not validate the type of object created after loading the data submitted to the `config.xml` REST API endpoint of a node. This allows attackers with Computer/Configure permission to replace a node with one of a different type. Jenkins 2.287, LTS 2.277.2 validates the type of object created and rejects objects of unexpected types.	There are no reported fixed by versions.
VCID-dkr2-9c7r-q3g9 Aliases: CVE-2021-21640 GHSA-w2hv-rcqr-2h7r	View name validation bypass in Jenkins Jenkins 2.286 and earlier, LTS 2.277.1 and earlier does not properly check that a newly created view has an allowed name. When a form to create a view is submitted, the name is included twice in the submission. One instance is validated, but the other instance is used to create the value. This allows attackers with View/Create permission to create views with invalid or already-used names. Jenkins 2.287, LTS 2.277.2 uses the same submitted value for validation and view creation.	There are no reported fixed by versions.
VCID-kxtv-ma18-8fer Aliases: CVE-2021-28163 GHSA-j6qj-j888-vvgq	Directory exposure in jetty ### Impact If the `${jetty.base}` directory or the `${jetty.base}/webapps` directory is a symlink (soft link in Linux), the contents of the `${jetty.base}/webapps` directory may be deployed as a static web application, exposing the content of the directory for download. For example, the problem manifests in the following `${jetty.base}`: ```$ tree demo-base/ demo-base/ ├── etc ├── lib ├── resources ├── start.d ├── deploy │ └── async-rest.war └── webapps -> deploy ``` ### Workarounds Do not use a symlink	There are no reported fixed by versions.
VCID-prd3-mmuv-n3dc Aliases: CVE-2021-28165 GHSA-26vr-8j45-3r4w	Jetty vulnerable to incorrect handling of invalid large TLS frame, exhausting CPU resources ### Impact When using SSL/TLS with Jetty, either with HTTP/1.1, HTTP/2, or WebSocket, the server may receive an invalid large (greater than 17408) TLS frame that is incorrectly handled, causing CPU resources to eventually reach 100% usage. ### Workarounds The problem can be worked around by compiling the following class: ```java package org.eclipse.jetty.server.ssl.fix6072; import java.nio.ByteBuffer; import javax.net.ssl.SSLEngine; import javax.net.ssl.SSLEngineResult; import javax.net.ssl.SSLException; import javax.net.ssl.SSLHandshakeException; import org.eclipse.jetty.io.EndPoint; import org.eclipse.jetty.io.ssl.SslConnection; import org.eclipse.jetty.server.Connector; import org.eclipse.jetty.server.SslConnectionFactory; import org.eclipse.jetty.util.BufferUtil; import org.eclipse.jetty.util.annotation.Name; import org.eclipse.jetty.util.ssl.SslContextFactory; public class SpaceCheckingSslConnectionFactory extends SslConnectionFactory { public SpaceCheckingSslConnectionFactory(@Name("sslContextFactory") SslContextFactory factory, @Name("next") String nextProtocol) { super(factory, nextProtocol); } @Override protected SslConnection newSslConnection(Connector connector, EndPoint endPoint, SSLEngine engine) { return new SslConnection(connector.getByteBufferPool(), connector.getExecutor(), endPoint, engine, isDirectBuffersForEncryption(), isDirectBuffersForDecryption()) { @Override protected SSLEngineResult unwrap(SSLEngine sslEngine, ByteBuffer input, ByteBuffer output) throws SSLException { SSLEngineResult results = super.unwrap(sslEngine, input, output); if ((results.getStatus() == SSLEngineResult.Status.BUFFER_UNDERFLOW \|\| results.getStatus() == SSLEngineResult.Status.OK && results.bytesConsumed() == 0 && results.bytesProduced() == 0) && BufferUtil.space(input) == 0) { BufferUtil.clear(input); throw new SSLHandshakeException("Encrypted buffer max length exceeded"); } return results; } }; } } ``` This class can be deployed by: + The resulting class file should be put into a jar file (eg sslfix6072.jar) + The jar file should be made available to the server. For a normal distribution this can be done by putting the file into ${jetty.base}/lib + Copy the file `${jetty.home}/modules/ssl.mod` to `${jetty.base}/modules` + Edit the `${jetty.base}/modules/ssl.mod` file to have the following section: ``` [lib] lib/sslfix6072.jar ``` + Copy the file `${jetty.home}/etc/jetty-https.xml` and`${jetty.home}/etc/jetty-http2.xml` to `${jetty.base}/etc` + Edit files `${jetty.base}/etc/jetty-https.xml` and `${jetty.base}/etc/jetty-http2.xml`, changing any reference of `org.eclipse.jetty.server.SslConnectionFactory` to `org.eclipse.jetty.server.ssl.fix6072.SpaceCheckingSslConnectionFactory`. For example: ```xml <Call name="addIfAbsentConnectionFactory"> <Arg> <New class="org.eclipse.jetty.server.ssl.fix6072.SpaceCheckingSslConnectionFactory"> <Arg name="next">http/1.1</Arg> <Arg name="sslContextFactory"><Ref refid="sslContextFactory"/></Arg> </New> </Arg> </Call> ``` + Restart Jetty	There are no reported fixed by versions.

Vulnerability

Summary

Fixed by

VCID-9prj-5zwe-7kc5
Aliases:
CVE-2021-21639
GHSA-pvwx-3jx5-24r2

Lack of type validation in agent related REST API in Jenkins Jenkins 2.286 and earlier, LTS 2.277.1 and earlier does not validate the type of object created after loading the data submitted to the `config.xml` REST API endpoint of a node. This allows attackers with Computer/Configure permission to replace a node with one of a different type. Jenkins 2.287, LTS 2.277.2 validates the type of object created and rejects objects of unexpected types.

There are no reported fixed by versions.

VCID-dkr2-9c7r-q3g9
Aliases:
CVE-2021-21640
GHSA-w2hv-rcqr-2h7r

View name validation bypass in Jenkins Jenkins 2.286 and earlier, LTS 2.277.1 and earlier does not properly check that a newly created view has an allowed name. When a form to create a view is submitted, the name is included twice in the submission. One instance is validated, but the other instance is used to create the value. This allows attackers with View/Create permission to create views with invalid or already-used names. Jenkins 2.287, LTS 2.277.2 uses the same submitted value for validation and view creation.

There are no reported fixed by versions.

VCID-kxtv-ma18-8fer
Aliases:
CVE-2021-28163
GHSA-j6qj-j888-vvgq

Directory exposure in jetty ### Impact If the `${jetty.base}` directory or the `${jetty.base}/webapps` directory is a symlink (soft link in Linux), the contents of the `${jetty.base}/webapps` directory may be deployed as a static web application, exposing the content of the directory for download. For example, the problem manifests in the following `${jetty.base}`: ```$ tree demo-base/ demo-base/ ├── etc ├── lib ├── resources ├── start.d ├── deploy │ └── async-rest.war └── webapps -> deploy ``` ### Workarounds Do not use a symlink

There are no reported fixed by versions.

VCID-prd3-mmuv-n3dc
Aliases:
CVE-2021-28165
GHSA-26vr-8j45-3r4w

Jetty vulnerable to incorrect handling of invalid large TLS frame, exhausting CPU resources ### Impact When using SSL/TLS with Jetty, either with HTTP/1.1, HTTP/2, or WebSocket, the server may receive an invalid large (greater than 17408) TLS frame that is incorrectly handled, causing CPU resources to eventually reach 100% usage. ### Workarounds The problem can be worked around by compiling the following class: ```java package org.eclipse.jetty.server.ssl.fix6072; import java.nio.ByteBuffer; import javax.net.ssl.SSLEngine; import javax.net.ssl.SSLEngineResult; import javax.net.ssl.SSLException; import javax.net.ssl.SSLHandshakeException; import org.eclipse.jetty.io.EndPoint; import org.eclipse.jetty.io.ssl.SslConnection; import org.eclipse.jetty.server.Connector; import org.eclipse.jetty.server.SslConnectionFactory; import org.eclipse.jetty.util.BufferUtil; import org.eclipse.jetty.util.annotation.Name; import org.eclipse.jetty.util.ssl.SslContextFactory; public class SpaceCheckingSslConnectionFactory extends SslConnectionFactory { public SpaceCheckingSslConnectionFactory(@Name("sslContextFactory") SslContextFactory factory, @Name("next") String nextProtocol) { super(factory, nextProtocol); } @Override protected SslConnection newSslConnection(Connector connector, EndPoint endPoint, SSLEngine engine) { return new SslConnection(connector.getByteBufferPool(), connector.getExecutor(), endPoint, engine, isDirectBuffersForEncryption(), isDirectBuffersForDecryption()) { @Override protected SSLEngineResult unwrap(SSLEngine sslEngine, ByteBuffer input, ByteBuffer output) throws SSLException { SSLEngineResult results = super.unwrap(sslEngine, input, output); if ((results.getStatus() == SSLEngineResult.Status.BUFFER_UNDERFLOW || results.getStatus() == SSLEngineResult.Status.OK && results.bytesConsumed() == 0 && results.bytesProduced() == 0) && BufferUtil.space(input) == 0) { BufferUtil.clear(input); throw new SSLHandshakeException("Encrypted buffer max length exceeded"); } return results; } }; } } ``` This class can be deployed by: + The resulting class file should be put into a jar file (eg sslfix6072.jar) + The jar file should be made available to the server. For a normal distribution this can be done by putting the file into ${jetty.base}/lib + Copy the file `${jetty.home}/modules/ssl.mod` to `${jetty.base}/modules` + Edit the `${jetty.base}/modules/ssl.mod` file to have the following section: ``` [lib] lib/sslfix6072.jar ``` + Copy the file `${jetty.home}/etc/jetty-https.xml` and`${jetty.home}/etc/jetty-http2.xml` to `${jetty.base}/etc` + Edit files `${jetty.base}/etc/jetty-https.xml` and `${jetty.base}/etc/jetty-http2.xml`, changing any reference of `org.eclipse.jetty.server.SslConnectionFactory` to `org.eclipse.jetty.server.ssl.fix6072.SpaceCheckingSslConnectionFactory`. For example: ```xml <Call name="addIfAbsentConnectionFactory"> <Arg> <New class="org.eclipse.jetty.server.ssl.fix6072.SpaceCheckingSslConnectionFactory"> <Arg name="next">http/1.1</Arg> <Arg name="sslContextFactory"><Ref refid="sslContextFactory"/></Arg> </New> </Arg> </Call> ``` + Restart Jetty

There are no reported fixed by versions.

Vulnerability	Summary	Aliases
This package is not known to fix vulnerabilities.

Vulnerability

Summary

Aliases

This package is not known to fix vulnerabilities.

Date	Actor	Action	Vulnerability	Source	VulnerableCode Version
2026-04-01T14:02:36.291297+00:00	RedHat Importer	Affected by	VCID-prd3-mmuv-n3dc	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2021-28165.json	38.0.0
2026-04-01T14:02:36.164422+00:00	RedHat Importer	Affected by	VCID-kxtv-ma18-8fer	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2021-28163.json	38.0.0
2026-04-01T14:02:35.510192+00:00	RedHat Importer	Affected by	VCID-dkr2-9c7r-q3g9	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2021-21640.json	38.0.0
2026-04-01T14:02:35.466717+00:00	RedHat Importer	Affected by	VCID-9prj-5zwe-7kc5	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2021-21639.json	38.0.0