VulnerableCode Package Details - pkg:rpm/redhat/eap7-mod_cluster@1.4.3-2.Final_redhat

Search for packages

Vulnerability	Summary	Fixed by
VCID-9bk7-2rsc-nbd6 Aliases: CVE-2020-13936 GHSA-59j4-wjwp-mw9m	Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') An attacker that is able to modify Velocity templates may execute arbitrary Java code or run arbitrary system commands with the same privileges as the account running the Servlet container. This applies to applications that allow untrusted users to upload/modify velocity templates running Apache Velocity Engine versions up to 2.2.	There are no reported fixed by versions.
VCID-e92u-331h-bkcb Aliases: CVE-2021-21290 GHSA-5mcr-gq6c-3hq2	This advisory has been marked as False Positive and moved to `netty-codec-http`, `netty-handler` and `netty-common`.	There are no reported fixed by versions.
VCID-ug8h-p8kf-t7e1 Aliases: CVE-2021-21295 GHSA-wm47-8v5p-wjpj	Possible request smuggling in HTTP/2 due missing validation ### Impact If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. A sample attack request looks like: ``` POST / HTTP/2 :authority:: externaldomain.com Content-Length: 4 asdfGET /evilRedirect HTTP/1.1 Host: internaldomain.com ``` Users are only affected if all of this is `true`: * `HTTP2MultiplexCodec` or `Http2FrameCodec` is used * `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects * These HTTP/1.1 objects are forwarded to another remote peer. ### Patches This has been patched in 4.1.60.Final ### Workarounds The user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`. ### References Related change to workaround the problem: https://github.com/Netflix/zuul/pull/980	There are no reported fixed by versions.

Vulnerability

Summary

Fixed by

VCID-9bk7-2rsc-nbd6
Aliases:
CVE-2020-13936
GHSA-59j4-wjwp-mw9m

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') An attacker that is able to modify Velocity templates may execute arbitrary Java code or run arbitrary system commands with the same privileges as the account running the Servlet container. This applies to applications that allow untrusted users to upload/modify velocity templates running Apache Velocity Engine versions up to 2.2.

There are no reported fixed by versions.

VCID-e92u-331h-bkcb
Aliases:
CVE-2021-21290
GHSA-5mcr-gq6c-3hq2

This advisory has been marked as False Positive and moved to `netty-codec-http`, `netty-handler` and `netty-common`.

There are no reported fixed by versions.

VCID-ug8h-p8kf-t7e1
Aliases:
CVE-2021-21295
GHSA-wm47-8v5p-wjpj

Possible request smuggling in HTTP/2 due missing validation ### Impact If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. A sample attack request looks like: ``` POST / HTTP/2 :authority:: externaldomain.com Content-Length: 4 asdfGET /evilRedirect HTTP/1.1 Host: internaldomain.com ``` Users are only affected if all of this is `true`: * `HTTP2MultiplexCodec` or `Http2FrameCodec` is used * `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects * These HTTP/1.1 objects are forwarded to another remote peer. ### Patches This has been patched in 4.1.60.Final ### Workarounds The user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`. ### References Related change to workaround the problem: https://github.com/Netflix/zuul/pull/980

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:03:16.602165+00:00	RedHat Importer	Affected by	VCID-e92u-331h-bkcb	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2021-21290.json	38.0.0
2026-04-01T14:02:56.460705+00:00	RedHat Importer	Affected by	VCID-9bk7-2rsc-nbd6	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2020-13936.json	38.0.0
2026-04-01T14:02:53.923050+00:00	RedHat Importer	Affected by	VCID-ug8h-p8kf-t7e1	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2021-21295.json	38.0.0