Total
159 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2019-16786 | 5 Agendaless, Debian, Fedoraproject and 2 more | 5 Waitress, Debian Linux, Fedora and 2 more | 2022-09-23 | 5.0 MEDIUM | 7.5 HIGH |
| Waitress through version 1.3.1 would parse the Transfer-Encoding header and only look for a single string value, if that value was not chunked it would fall through and use the Content-Length header instead. According to the HTTP standard Transfer-Encoding should be a comma separated list, with the inner-most encoding first, followed by any further transfer codings, ending with chunked. Requests sent with: "Transfer-Encoding: gzip, chunked" would incorrectly get ignored, and the request would use a Content-Length header instead to determine the body size of the HTTP message. This could allow for Waitress to treat a single request as multiple requests in the case of HTTP pipelining. This issue is fixed in Waitress 1.4.0. | |||||
| CVE-2019-16785 | 5 Agendaless, Debian, Fedoraproject and 2 more | 5 Waitress, Debian Linux, Fedora and 2 more | 2022-09-23 | 5.0 MEDIUM | 7.5 HIGH |
| Waitress through version 1.3.1 implemented a "MAY" part of the RFC7230 which states: "Although the line terminator for the start-line and header fields is the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR." Unfortunately if a front-end server does not parse header fields with an LF the same way as it does those with a CRLF it can lead to the front-end and the back-end server parsing the same HTTP message in two different ways. This can lead to a potential for HTTP request smuggling/splitting whereby Waitress may see two requests while the front-end server only sees a single HTTP message. This issue is fixed in Waitress 1.4.0. | |||||
| CVE-2019-16789 | 5 Agendaless, Debian, Fedoraproject and 2 more | 5 Waitress, Debian Linux, Fedora and 2 more | 2022-09-23 | 6.4 MEDIUM | 8.2 HIGH |
| In Waitress through version 1.4.0, if a proxy server is used in front of waitress, an invalid request may be sent by an attacker that bypasses the front-end and is parsed differently by waitress leading to a potential for HTTP request smuggling. Specially crafted requests containing special whitespace characters in the Transfer-Encoding header would get parsed by Waitress as being a chunked request, but a front-end server would use the Content-Length instead as the Transfer-Encoding header is considered invalid due to containing invalid characters. If a front-end server does HTTP pipelining to a backend Waitress server this could lead to HTTP request splitting which may lead to potential cache poisoning or unexpected information disclosure. This issue is fixed in Waitress 1.4.1 through more strict HTTP field validation. | |||||
| CVE-2022-24761 | 2 Agendaless, Debian | 2 Waitress, Debian Linux | 2022-09-23 | 5.0 MEDIUM | 7.5 HIGH |
| Waitress is a Web Server Gateway Interface server for Python 2 and 3. When using Waitress versions 2.1.0 and prior behind a proxy that does not properly validate the incoming HTTP request matches the RFC7230 standard, Waitress and the frontend proxy may disagree on where one request starts and where it ends. This would allow requests to be smuggled via the front-end proxy to waitress and later behavior. There are two classes of vulnerability that may lead to request smuggling that are addressed by this advisory: The use of Python's `int()` to parse strings into integers, leading to `+10` to be parsed as `10`, or `0x01` to be parsed as `1`, where as the standard specifies that the string should contain only digits or hex digits; and Waitress does not support chunk extensions, however it was discarding them without validating that they did not contain illegal characters. This vulnerability has been patched in Waitress 2.1.1. A workaround is available. When deploying a proxy in front of waitress, turning on any and all functionality to make sure that the request matches the RFC7230 standard. Certain proxy servers may not have this functionality though and users are encouraged to upgrade to the latest version of waitress instead. | |||||
| CVE-2019-0197 | 6 Apache, Canonical, Fedoraproject and 3 more | 12 Http Server, Ubuntu Linux, Fedora and 9 more | 2022-09-07 | 4.9 MEDIUM | 4.2 MEDIUM |
| A vulnerability was found in Apache HTTP Server 2.4.34 to 2.4.38. When HTTP/2 was enabled for a http: host or H2Upgrade was enabled for h2 on a https: host, an Upgrade request from http/1.1 to http/2 that was not the first request on a connection could lead to a misconfiguration and crash. Server that never enabled the h2 protocol or that only enabled it for https: and did not set "H2Upgrade on" are unaffected by this issue. | |||||
| CVE-2022-2466 | 1 Quarkus | 1 Quarkus | 2022-09-06 | N/A | 9.8 CRITICAL |
| It was found that Quarkus 2.10.x does not terminate HTTP requests header context which may lead to unpredictable behavior. | |||||
| CVE-2019-17569 | 5 Apache, Debian, Netapp and 2 more | 16 Tomcat, Tomee, Debian Linux and 13 more | 2022-09-02 | 5.8 MEDIUM | 4.8 MEDIUM |
| The refactoring present in Apache Tomcat 9.0.28 to 9.0.30, 8.5.48 to 8.5.50 and 7.0.98 to 7.0.99 introduced a regression. The result of the regression was that invalid Transfer-Encoding headers were incorrectly processed leading to a possibility of HTTP Request Smuggling if Tomcat was located behind a reverse proxy that incorrectly handled the invalid Transfer-Encoding header in a particular manner. Such a reverse proxy is considered unlikely. | |||||
| CVE-2022-26377 | 3 Apache, Fedoraproject, Netapp | 3 Http Server, Fedora, Clustered Data Ontap | 2022-08-24 | 5.0 MEDIUM | 7.5 HIGH |
| Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') vulnerability in mod_proxy_ajp of Apache HTTP Server allows an attacker to smuggle requests to the AJP server it forwards requests to. This issue affects Apache HTTP Server Apache HTTP Server 2.4 version 2.4.53 and prior versions. | |||||
| CVE-2022-33988 | 1 Dproxy-nexgen Project | 1 Dproxy-nexgen | 2022-08-17 | N/A | 7.5 HIGH |
| dproxy-nexgen (aka dproxy nexgen) re-uses the DNS transaction id (TXID) value from client queries, which allows attackers (able to send queries to the resolver) to conduct DNS cache-poisoning attacks because the TXID value is known to the attacker. | |||||
| CVE-2022-20713 | 1 Cisco | 1 Adaptive Security Appliance Software | 2022-08-12 | N/A | 6.1 MEDIUM |
| A vulnerability in the Clientless SSL VPN (WebVPN) component of Cisco Adaptive Security Appliance (ASA) Software could allow an unauthenticated, remote attacker to conduct browser-based attacks. This vulnerability is due to improper validation of input that is passed to the Clientless SSL VPN component. An attacker could exploit this vulnerability by convincing a targeted user to visit a website that can pass malicious requests to an ASA device that has the Clientless SSL VPN feature enabled. A successful exploit could allow the attacker to conduct browser-based attacks, including cross-site scripting attacks, against the targeted user. | |||||
| CVE-2022-31109 | 1 Getlaminas | 1 Laminas-diactoros | 2022-08-05 | N/A | 6.1 MEDIUM |
| laminas-diactoros is a PHP package containing implementations of the PSR-7 HTTP message interfaces and PSR-17 HTTP message factory interfaces. Applications that use Diactoros, and are either not behind a proxy, or can be accessed via untrusted proxies, can potentially have the host, protocol, and/or port of a `Laminas\Diactoros\Uri` instance associated with the incoming server request modified to reflect values from `X-Forwarded-*` headers. Such changes can potentially lead to XSS attacks (if a fully-qualified URL is used in links) and/or URL poisoning. Since the `X-Forwarded-*` headers do have valid use cases, particularly in clustered environments using a load balancer, the library offers mitigation measures only in the v2 releases, as doing otherwise would break these use cases immediately. Users of v2 releases from 2.11.1 can provide an additional argument to `Laminas\Diactoros\ServerRequestFactory::fromGlobals()` in the form of a `Laminas\Diactoros\RequestFilter\RequestFilterInterface` instance, including the shipped `Laminas\Diactoros\RequestFilter\NoOpRequestFilter` implementation which ignores the `X-Forwarded-*` headers. Starting in version 3.0, the library will reverse behavior to use the `NoOpRequestFilter` by default, and require users to opt-in to `X-Forwarded-*` header usage via a configured `Laminas\Diactoros\RequestFilter\LegacyXForwardedHeaderFilter` instance. Users are advised to upgrade to version 2.11.1 or later to resolve this issue. Users unable to upgrade may configure web servers to reject `X-Forwarded-*` headers at the web server level. | |||||
| CVE-2022-23959 | 4 Debian, Fedoraproject, Varnish-software and 1 more | 6 Debian Linux, Fedora, Varnich Cache and 3 more | 2022-08-02 | 6.4 MEDIUM | 9.1 CRITICAL |
| In Varnish Cache before 6.6.2 and 7.x before 7.0.2, Varnish Cache 6.0 LTS before 6.0.10, and and Varnish Enterprise (Cache Plus) 4.1.x before 4.1.11r6 and 6.0.x before 6.0.9r4, request smuggling can occur for HTTP/1 connections. | |||||
| CVE-2021-36740 | 5 Debian, Fedoraproject, Varnish-cache and 2 more | 5 Debian Linux, Fedora, Varnish Cache and 2 more | 2022-08-02 | 6.4 MEDIUM | 6.5 MEDIUM |
| Varnish Cache, with HTTP/2 enabled, allows request smuggling and VCL authorization bypass via a large Content-Length header for a POST request. This affects Varnish Enterprise 6.0.x before 6.0.8r3, and Varnish Cache 5.x and 6.x before 6.5.2, 6.6.x before 6.6.1, and 6.0 LTS before 6.0.8. | |||||
| CVE-2021-31922 | 1 Pulsesecure | 1 Virtual Traffic Manager | 2022-07-12 | 5.0 MEDIUM | 7.5 HIGH |
| An HTTP Request Smuggling vulnerability in Pulse Secure Virtual Traffic Manager before 21.1 could allow an attacker to smuggle an HTTP request through an HTTP/2 Header. This vulnerability is resolved in 21.1, 20.3R1, 20.2R1, 20.1R2, 19.2R4, and 18.2R3. | |||||
| CVE-2022-29361 | 1 Palletsprojects | 1 Werkzeug | 2022-06-07 | 7.5 HIGH | 9.8 CRITICAL |
| ** DISPUTED ** Improper parsing of HTTP requests in Pallets Werkzeug v2.1.0 and below allows attackers to perform HTTP Request Smuggling using a crafted HTTP request with multiple requests included inside the body. NOTE: the vendor's position is that this behavior can only occur in unsupported configurations involving development mode and an HTTP server from outside the Werkzeug project. | |||||
| CVE-2018-4030 | 1 Getcujo | 1 Smart Firewall | 2022-06-07 | 5.0 MEDIUM | 7.5 HIGH |
| An exploitable vulnerability exists the safe browsing function of the CUJO Smart Firewall, version 7003. The bug lies in the way the safe browsing function parses HTTP requests. The "Host" header is incorrectly extracted from captured HTTP requests, which would allow an attacker to visit any malicious websites and bypass the firewall. An attacker could send an HTTP request to exploit this vulnerability. | |||||
| CVE-2019-18277 | 1 Haproxy | 1 Haproxy | 2022-06-02 | 4.3 MEDIUM | 7.5 HIGH |
| A flaw was found in HAProxy before 2.0.6. In legacy mode, messages featuring a transfer-encoding header missing the "chunked" value were not being correctly rejected. The impact was limited but if combined with the "http-reuse always" setting, it could be used to help construct an HTTP request smuggling attack against a vulnerable component employing a lenient parser that would ignore the content-length header as soon as it saw a transfer-encoding one (even if not entirely valid according to the specification). | |||||
| CVE-2020-8201 | 3 Fedoraproject, Nodejs, Opensuse | 3 Fedora, Node.js, Leap | 2022-05-24 | 5.8 MEDIUM | 7.4 HIGH |
| Node.js < 12.18.4 and < 14.11 can be exploited to perform HTTP desync attacks and deliver malicious payloads to unsuspecting users. The payloads can be crafted by an attacker to hijack user sessions, poison cookies, perform clickjacking, and a multitude of other attacks depending on the architecture of the underlying system. The attack was possible due to a bug in processing of carrier-return symbols in the HTTP header names. | |||||
| CVE-2021-21409 | 5 Debian, Netapp, Netty and 2 more | 18 Debian Linux, Oncommand Api Services, Oncommand Workflow Automation and 15 more | 2022-05-12 | 4.3 MEDIUM | 5.9 MEDIUM |
| Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.61.Final there is a vulnerability that enables request smuggling. The content-length header is not correctly validated if the request only uses a single Http2HeaderFrame with the endStream set to to true. This could lead to request smuggling if the request is proxied to a remote peer and translated to HTTP/1.1. This is a followup of GHSA-wm47-8v5p-wjpj/CVE-2021-21295 which did miss to fix this one case. This was fixed as part of 4.1.61.Final. | |||||
| CVE-2021-21295 | 6 Apache, Debian, Netapp and 3 more | 8 Kudu, Zookeeper, Debian Linux and 5 more | 2022-05-12 | 2.6 LOW | 5.9 MEDIUM |
| Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. 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. For an example attack refer to the linked GitHub Advisory. 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, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`. | |||||