CWE-444
AllowedInconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Abstraction: Base · Status: Incomplete
The product acts as an intermediary HTTP agent (such as a proxy or firewall) in the data flow between two entities such as a client and server, but it does not interpret malformed HTTP requests or responses in ways that are consistent with how the messages will be processed by those entities that are at the ultimate destination.
627 vulnerabilities reference this CWE, most recent first.
GHSA-JRMQ-RV9W-63RV
Vulnerability from github – Published: 2022-01-21 23:34 – Updated: 2022-01-19 22:24Within the Umbraco CMS, a configuration element named "UmbracoApplicationUrl" (or just "ApplicationUrl") is used whenever application code needs to build a URL pointing back to the site. For example, when a user resets their password and the application builds a password reset URL or when the administrator invites users to the site. For Umbraco versions less than 9.2.0, if the Application URL is not specifically configured, the attacker can manipulate this value and store it persistently affecting all users for components where the "UmbracoApplicationUrl" is used. For example, the attacker is able to change the URL users receive when resetting their password so that it points to the attackers server, when the user follows this link the reset token can be intercepted by the attacker resulting in account takeover.
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "Umbraco.Cms.Core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-22690"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2022-01-19T22:24:06Z",
"nvd_published_at": "2022-01-18T17:15:00Z",
"severity": "HIGH"
},
"details": "Within the Umbraco CMS, a configuration element named \"UmbracoApplicationUrl\" (or just \"ApplicationUrl\") is used whenever application code needs to build a URL pointing back to the site. For example, when a user resets their password and the application builds a password reset URL or when the administrator invites users to the site. For Umbraco versions less than 9.2.0, if the Application URL is not specifically configured, the attacker can manipulate this value and store it persistently affecting all users for components where the \"UmbracoApplicationUrl\" is used. For example, the attacker is able to change the URL users receive when resetting their password so that it points to the attackers server, when the user follows this link the reset token can be intercepted by the attacker resulting in account takeover.",
"id": "GHSA-jrmq-rv9w-63rv",
"modified": "2022-01-19T22:24:06Z",
"published": "2022-01-21T23:34:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22690"
},
{
"type": "WEB",
"url": "https://appcheck-ng.com/umbraco-applicationurl-overwrite-persistent-password-reset-poison-cve-2022-22690-cve-2022-22691"
},
{
"type": "PACKAGE",
"url": "https://github.com/umbraco/Umbraco-CMS"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Umbraco ApplicationURL Overwrite"
}
GHSA-JRPC-7VXP-69P6
Vulnerability from github – Published: 2026-06-19 21:15 – Updated: 2026-06-19 21:15Impact
reverseProxy() and reverseProxyRouting() matched configured vhosts by substring on the Host header (Contains matcher) by default. The intended use of these functions in http4k is outbound dispatch (e.g. matching AWS service subdomains, per the Contains docstring) and test-time composition of fake backend networks. In either of those contexts the matched Host is set by the calling application, not by an external attacker, so the loose match has no exploit surface.
If, however, reverseProxy() was deployed as a public-facing inbound HTTP handler — which the function technically supports but is not the documented intent — an external attacker could send Host: admin.evil.com and reach a vhost configured as admin, bypassing routing-based authorization.
The Contains matcher's docstring explicitly documented this loose behaviour, but because Contains was the default, callers who never read the matcher docs would still get the loose behaviour.
Who is affected: only deployments using reverseProxy() / reverseProxyRouting() as a public-facing inbound HTTP handler with two or more configured virtual hosts. The intended outbound / test-time usage is unaffected. If you did deploy reverseProxy() inbound and rely on multi-vhost routing for authorization, treat upgrade as urgent.
Patches
| Line | Fixed in | Edition |
|---|---|---|
| v6.x (Community) | 6.49.0.0 | Community |
| v5.x (LTS) | 5.42.0.0 | Enterprise — contact enterprise@http4k.org (if reverseProxy() is present in your v5.x line) |
| v4.x (LTS) | 4.51.0.0 | Enterprise — contact enterprise@http4k.org (if reverseProxy() is present in your v4.x line) |
The fix changes the default matcher to Exact. Existing callers that genuinely need substring matching (e.g. AWS subdomain dispatch) must explicitly pass matcher = Contains.
Workarounds
For deployments that cannot upgrade immediately: wrap your reverseProxy() with a host-allow-list filter that requires an exact match against expected vhost names before delegating.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c 6.48.0.0"
},
"package": {
"ecosystem": "Maven",
"name": "org.http4k:http4k-core"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0.0"
},
{
"fixed": "6.49.0.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.http4k:http4k-core"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0.0"
},
{
"fixed": "5.42.0.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.http4k:http4k-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.51.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T21:15:59Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\n`reverseProxy()` and `reverseProxyRouting()` matched configured vhosts by substring on the `Host` header (`Contains` matcher) by default. The intended use of these functions in http4k is **outbound dispatch** (e.g. matching AWS service subdomains, per the `Contains` docstring) and **test-time composition** of fake backend networks. In either of those contexts the matched `Host` is set by the calling application, not by an external attacker, so the loose match has no exploit surface.\n\nIf, however, `reverseProxy()` was deployed as a public-facing inbound HTTP handler \u2014 which the function technically supports but is not the documented intent \u2014 an external attacker could send `Host: admin.evil.com` and reach a vhost configured as `admin`, bypassing routing-based authorization.\n\nThe `Contains` matcher\u0027s docstring explicitly documented this loose behaviour, but because `Contains` was the default, callers who never read the matcher docs would still get the loose behaviour.\n\n**Who is affected:** only deployments using `reverseProxy()` / `reverseProxyRouting()` as a public-facing inbound HTTP handler with two or more configured virtual hosts. The intended outbound / test-time usage is unaffected. If you *did* deploy `reverseProxy()` inbound and rely on multi-vhost routing for authorization, treat upgrade as urgent.\n\n### Patches\n\n| Line | Fixed in | Edition |\n|------|----------|---------|\n| v6.x (Community) | **6.49.0.0** | Community |\n| v5.x (LTS) | **5.42.0.0** | Enterprise \u2014 contact [enterprise@http4k.org](mailto:enterprise@http4k.org) (if `reverseProxy()` is present in your v5.x line) |\n| v4.x (LTS) | **4.51.0.0** | Enterprise \u2014 contact [enterprise@http4k.org](mailto:enterprise@http4k.org) (if `reverseProxy()` is present in your v4.x line) |\n\nThe fix changes the default matcher to `Exact`. Existing callers that genuinely need substring matching (e.g. AWS subdomain dispatch) must explicitly pass `matcher = Contains`.\n\n### Workarounds\n\nFor deployments that cannot upgrade immediately: wrap your `reverseProxy()` with a host-allow-list filter that requires an exact match against expected vhost names before delegating.",
"id": "GHSA-jrpc-7vxp-69p6",
"modified": "2026-06-19T21:15:59Z",
"published": "2026-06-19T21:15:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/http4k/http4k/security/advisories/GHSA-jrpc-7vxp-69p6"
},
{
"type": "WEB",
"url": "https://github.com/http4k/http4k/commit/0121b05537"
},
{
"type": "WEB",
"url": "https://github.com/http4k/http4k/commit/54c6385615"
},
{
"type": "PACKAGE",
"url": "https://github.com/http4k/http4k"
},
{
"type": "WEB",
"url": "https://github.com/http4k/http4k/releases/tag/6.49.0.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "http4k: `reverseProxy()` defaulted to substring (`Contains`) matching on `Host`; tightened to `Exact`"
}
GHSA-JW78-2435-W3R6
Vulnerability from github – Published: 2022-05-24 19:10 – Updated: 2022-05-24 19:10Belledonne Belle-sip before 4.5.20, as used in Linphone and other products, can crash via an invalid From header in a SIP message.
{
"affected": [],
"aliases": [
"CVE-2021-33056"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Belledonne Belle-sip before 4.5.20, as used in Linphone and other products, can crash via an invalid From header in a SIP message.",
"id": "GHSA-jw78-2435-w3r6",
"modified": "2022-05-24T19:10:48Z",
"published": "2022-05-24T19:10:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33056"
},
{
"type": "WEB",
"url": "https://github.com/BelledonneCommunications/belle-sip/commit/116e3eb48fe43ea63eb9f3c4b4b30c48d58d6ff0"
},
{
"type": "WEB",
"url": "https://github.com/BelledonneCommunications/belle-sip/compare/4.5.15...4.5.20"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-JX9R-X782-9R4M
Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-20 12:32HTTP Request Smuggling vulnerability in netease-youdao/qanything version 1.4.1 allows attackers to exploit inconsistencies in the interpretation of HTTP requests between a proxy and a server. This can lead to unauthorized access, bypassing security controls, session hijacking, data leakage, and potentially arbitrary code execution.
{
"affected": [],
"aliases": [
"CVE-2024-10264"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-20T10:15:15Z",
"severity": "HIGH"
},
"details": "HTTP Request Smuggling vulnerability in netease-youdao/qanything version 1.4.1 allows attackers to exploit inconsistencies in the interpretation of HTTP requests between a proxy and a server. This can lead to unauthorized access, bypassing security controls, session hijacking, data leakage, and potentially arbitrary code execution.",
"id": "GHSA-jx9r-x782-9r4m",
"modified": "2025-03-20T12:32:38Z",
"published": "2025-03-20T12:32:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10264"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/988247d5-fd60-4d85-845a-e867d62c0d02"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M3HQ-GRV6-H853
Vulnerability from github – Published: 2022-10-14 19:00 – Updated: 2022-10-18 19:00Requests forwarded by ReverseProxy include the raw query parameters from the inbound request, including unparseable parameters rejected by net/http. This could permit query parameter smuggling when a Go proxy forwards a parameter with an unparseable value. After fix, ReverseProxy sanitizes the query parameters in the forwarded query when the outbound request's Form field is set after the ReverseProxy. Director function returns, indicating that the proxy has parsed the query parameters. Proxies which do not parse query parameters continue to forward the original query parameters unchanged.
{
"affected": [],
"aliases": [
"CVE-2022-2880"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-14T15:15:00Z",
"severity": "HIGH"
},
"details": "Requests forwarded by ReverseProxy include the raw query parameters from the inbound request, including unparseable parameters rejected by net/http. This could permit query parameter smuggling when a Go proxy forwards a parameter with an unparseable value. After fix, ReverseProxy sanitizes the query parameters in the forwarded query when the outbound request\u0027s Form field is set after the ReverseProxy. Director function returns, indicating that the proxy has parsed the query parameters. Proxies which do not parse query parameters continue to forward the original query parameters unchanged.",
"id": "GHSA-m3hq-grv6-h853",
"modified": "2022-10-18T19:00:31Z",
"published": "2022-10-14T19:00:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2880"
},
{
"type": "WEB",
"url": "https://go.dev/cl/432976"
},
{
"type": "WEB",
"url": "https://go.dev/issue/54663"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/golang-announce/c/xtuG5faxtaU"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/THKJHFMX4DAZXJ5MFPN3BNHZDN7BW5RI"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2022-1038"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202311-09"
},
{
"type": "WEB",
"url": "https://www.oxeye.io/blog/golang-parameter-smuggling-attack"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-M454-3XV7-QJ85
Vulnerability from github – Published: 2025-04-12 03:41 – Updated: 2025-04-23 15:06Impact
When using the ch-go library, under a specific condition when the query includes a large, uncompressed malicious external data, it is possible for an attacker in control of such data to smuggle another query packet into the connection stream.
Patches
If you are using ch-go library, we recommend you to update to at least version 0.65.0.
Credit
This issue was found by lixts and reported through our bugcrowd program.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/ClickHouse/ch-go"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.65.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-1386"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-12T03:41:21Z",
"nvd_published_at": "2025-04-11T05:15:29Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nWhen using the ch-go library, under a specific condition when the query includes a large, uncompressed malicious external data, it is possible for an attacker in control of such data to smuggle another query packet into the connection stream.\n\n### Patches\n\nIf you are using ch-go library, we recommend you to update to at least version 0.65.0.\n\n### Credit\n\nThis issue was found by lixts and reported through our bugcrowd program.",
"id": "GHSA-m454-3xv7-qj85",
"modified": "2025-04-23T15:06:50Z",
"published": "2025-04-12T03:41:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ClickHouse/ch-go/security/advisories/GHSA-m454-3xv7-qj85"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1386"
},
{
"type": "WEB",
"url": "https://github.com/ClickHouse/ch-go/commit/0e835663df32b09b828528c07a5507686e6d975e"
},
{
"type": "PACKAGE",
"url": "https://github.com/ClickHouse/ch-go"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2025-3603"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "CVE-2025-1386- Query smuggling in ch-go library"
}
GHSA-M4CV-J2PX-7723
Vulnerability from github – Published: 2026-05-07 00:13 – Updated: 2026-05-14 20:41Summary
Netty's chunk size parser silently overflows int, enabling request smuggling attacks.
Details
io.netty.handler.codec.http.HttpObjectDecoder#getChunkSize silently overflows int.
The size is accumulated as follows:
result *= 16; result += digit;
The result is checked only for negative values. However, with a carefully crafted chunk size, the result can be a valid size.
PoC
The test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a chunked body.
@Test
public void test() {
String requestStr = "POST / HTTP/1.1\r\n" +
"Host: localhost\r\n" +
"Transfer-Encoding: chunked\r\n\r\n" +
"100000004\r\n" +
"test\r\n" +
"0\r\n" +
"\r\n" +
"GET /smuggled HTTP/1.1\r\n" +
"Host: localhost\r\n" +
"Content-Length: 0\r\n" +
"\r\n";
EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());
assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr, CharsetUtil.US_ASCII)));
// Request 1
HttpRequest request = channel.readInbound();
assertTrue(request.decoderResult().isSuccess());
HttpContent content = channel.readInbound();
assertTrue(content.decoderResult().isSuccess());
assertEquals("test", content.content().toString(CharsetUtil.US_ASCII));
content.release();
LastHttpContent last = channel.readInbound();
assertTrue(last.decoderResult().isSuccess());
last.release();
// Request 2
request = channel.readInbound();
assertTrue(request.decoderResult().isSuccess());
last = channel.readInbound();
assertTrue(last.decoderResult().isSuccess());
last.release();
}
Impact
HTTP Request Smuggling: Attacker injects arbitrary HTTP requests
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.12.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.13.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.132.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.133.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42580"
],
"database_specific": {
"cwe_ids": [
"CWE-190",
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-07T00:13:05Z",
"nvd_published_at": "2026-05-13T19:17:23Z",
"severity": "MODERATE"
},
"details": "### Summary\nNetty\u0027s chunk size parser silently overflows int, enabling request smuggling attacks.\n\n### Details\nio.netty.handler.codec.http.HttpObjectDecoder#getChunkSize silently overflows int.\n\nThe size is accumulated as follows:\n\nresult *= 16;\nresult += digit;\n\nThe result is checked only for negative values. However, with a carefully crafted chunk size, the result can be a valid size.\n\n### PoC\nThe test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a chunked body.\n\n```java\n@Test\npublic void test() {\n String requestStr = \"POST / HTTP/1.1\\r\\n\" +\n \"Host: localhost\\r\\n\" +\n \"Transfer-Encoding: chunked\\r\\n\\r\\n\" +\n \"100000004\\r\\n\" +\n \"test\\r\\n\" +\n \"0\\r\\n\" +\n \"\\r\\n\" +\n \"GET /smuggled HTTP/1.1\\r\\n\" +\n \"Host: localhost\\r\\n\" +\n \"Content-Length: 0\\r\\n\" +\n \"\\r\\n\";\n\n EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());\n assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr, CharsetUtil.US_ASCII)));\n\n // Request 1\n HttpRequest request = channel.readInbound();\n assertTrue(request.decoderResult().isSuccess());\n HttpContent content = channel.readInbound();\n assertTrue(content.decoderResult().isSuccess());\n assertEquals(\"test\", content.content().toString(CharsetUtil.US_ASCII));\n content.release();\n LastHttpContent last = channel.readInbound();\n assertTrue(last.decoderResult().isSuccess());\n last.release();\n\n // Request 2\n request = channel.readInbound();\n assertTrue(request.decoderResult().isSuccess());\n last = channel.readInbound();\n assertTrue(last.decoderResult().isSuccess());\n last.release();\n}\n```\n\n### Impact\nHTTP Request Smuggling: Attacker injects arbitrary HTTP requests",
"id": "GHSA-m4cv-j2px-7723",
"modified": "2026-05-14T20:41:01Z",
"published": "2026-05-07T00:13:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-m4cv-j2px-7723"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42580"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Netty vulnerable to HTTP Request Smuggling due to incorrect chunk size parsing"
}
GHSA-M56V-PQJG-V632
Vulnerability from github – Published: 2026-04-01 21:30 – Updated: 2026-04-01 21:30IBM Verify Identity Access Container 11.0 through 11.0.2 and IBM Security Verify Access Container 10.0 through 10.0.9.1 and IBM Verify Identity Access 11.0 through 11.0.2 and IBM Security Verify Access 10.0 through 10.0.9.1 IBM Security Verify could allow a remote attacker to access sensitive information due to an inconsistent interpretation of an HTTP request by a reverse proxy.
{
"affected": [],
"aliases": [
"CVE-2026-1491"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-01T21:16:58Z",
"severity": "MODERATE"
},
"details": "IBM Verify Identity Access Container 11.0 through 11.0.2 and IBM Security Verify Access Container 10.0 through 10.0.9.1 and IBM Verify Identity Access 11.0 through 11.0.2 and IBM Security Verify Access 10.0 through 10.0.9.1 IBM Security Verify could allow a remote attacker to access sensitive information due to an inconsistent interpretation of an HTTP request by a reverse proxy.",
"id": "GHSA-m56v-pqjg-v632",
"modified": "2026-04-01T21:30:31Z",
"published": "2026-04-01T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1491"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7268253"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-M5FF-3WJ3-8PH4
Vulnerability from github – Published: 2019-12-26 16:34 – Updated: 2019-12-26 16:34Impact
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.
Content-Length: 10
Transfer-Encoding: [\x0b]chunked
For clarity:
0x0b == vertical tab
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.
Patches
Please upgrade to Waitress 1.4.1 which fixes this issue with stricter HTTP field validation.
Waitress 1.4.1 due to this change has become much more strict in what is allowed in header values, while the maintainers don't believe that these changes will cause any issues, it may cause failures with non-conformist reverse proxies or clients, and it is highly recommend that users validate the changes in their environment and make sure it won't cause any unacceptable failures.
Workarounds
You may enable additional protections on front-end servers, those that follow RFC7230 correctly would drop the request with a 400 Bad Request.
Waitress will now correctly responds to the request with a 400 Bad Request, and will drop the connection to avoid any potential HTTP pipelining issues.
References
This was mentioned in https://portswigger.net/research/http-desync-attacks-what-happened-next and was specifically mentioned as being an issue in HAProxy which did not properly filter it in this article: https://nathandavison.com/blog/haproxy-http-request-smuggling
Thanks
The Pylons Project would like to thank ZeddYu Lu for doing extended testing against Waitress 1.4.0 and bringing this to our attention!
For more information
If you have any questions or comments about this advisory:
- open an issue at https://github.com/Pylons/waitress/issues (if not sensitive or security related)
- email the Pylons Security mailing list: pylons-project-security@googlegroups.com (if security related)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "waitress"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2019-12-26T16:34:06Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\n\nIf 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.\n\n```\nContent-Length: 10\nTransfer-Encoding: [\\x0b]chunked\n```\n\nFor clarity:\n\n```\n0x0b == vertical tab\n```\n\nWould 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.\n\nIf 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.\n\n### Patches\n\nPlease upgrade to Waitress 1.4.1 which fixes this issue with stricter HTTP field validation.\n\nWaitress 1.4.1 due to this change has become much more strict in what is allowed in header values, while the maintainers don\u0027t believe that these changes will cause any issues, it may cause failures with non-conformist reverse proxies or clients, and it is highly recommend that users validate the changes in their environment and make sure it won\u0027t cause any unacceptable failures.\n\n### Workarounds\n\nYou may enable additional protections on front-end servers, those that follow RFC7230 correctly would drop the request with a 400 Bad Request.\n\nWaitress will now correctly responds to the request with a 400 Bad Request, and will drop the connection to avoid any potential HTTP pipelining issues.\n\n### References\n\nThis was mentioned in https://portswigger.net/research/http-desync-attacks-what-happened-next and was specifically mentioned as being an issue in HAProxy which did not properly filter it in this article: https://nathandavison.com/blog/haproxy-http-request-smuggling\n\n### Thanks\n\nThe Pylons Project would like to thank ZeddYu Lu for doing extended testing against Waitress 1.4.0 and bringing this to our attention!\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* open an issue at https://github.com/Pylons/waitress/issues (if not sensitive or security related)\n* email the Pylons Security mailing list: pylons-project-security@googlegroups.com (if security related)",
"id": "GHSA-m5ff-3wj3-8ph4",
"modified": "2019-12-26T16:34:06Z",
"published": "2019-12-26T16:34:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Pylons/waitress/security/advisories/GHSA-m5ff-3wj3-8ph4"
},
{
"type": "WEB",
"url": "https://github.com/Pylons/waitress/commit/11d9e138125ad46e951027184b13242a3c1de017"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "HTTP Request Smuggling: Invalid whitespace characters in headers in Waitress"
}
GHSA-M6M2-J477-JFG8
Vulnerability from github – Published: 2022-05-24 19:06 – Updated: 2022-05-24 19:06Incorrect handling of url fragment vulnerability of Apache Traffic Server allows an attacker to poison the cache. This issue affects Apache Traffic Server 7.0.0 to 7.1.12, 8.0.0 to 8.1.1, 9.0.0 to 9.0.1.
{
"affected": [],
"aliases": [
"CVE-2021-27577"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-29T12:15:00Z",
"severity": "HIGH"
},
"details": "Incorrect handling of url fragment vulnerability of Apache Traffic Server allows an attacker to poison the cache. This issue affects Apache Traffic Server 7.0.0 to 7.1.12, 8.0.0 to 8.1.1, 9.0.0 to 9.0.1.",
"id": "GHSA-m6m2-j477-jfg8",
"modified": "2022-05-24T19:06:34Z",
"published": "2022-05-24T19:06:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27577"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/ra1a41ff92a70d25bf576d7da2590575e8ff430393a3f4a0c34de4277%40%3Cusers.trafficserver.apache.org%3E"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-4957"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
Use a web server that employs a strict HTTP parsing procedure, such as Apache [REF-433].
Mitigation
Use only SSL communication.
Mitigation
Terminate the client session after each request.
Mitigation
Turn all pages to non-cacheable.
CAPEC-273: HTTP Response Smuggling
An adversary manipulates and injects malicious content in the form of secret unauthorized HTTP responses, into a single HTTP response from a vulnerable or compromised back-end HTTP agent (e.g., server).
See CanPrecede relationships for possible consequences.
CAPEC-33: HTTP Request Smuggling
An adversary abuses the flexibility and discrepancies in the parsing and interpretation of HTTP Request messages using various HTTP headers, request-line and body parameters as well as message sizes (denoted by the end of message signaled by a given HTTP header) by different intermediary HTTP agents (e.g., load balancer, reverse proxy, web caching proxies, application firewalls, etc.) to secretly send unauthorized and malicious HTTP requests to a back-end HTTP agent (e.g., web server).
See CanPrecede relationships for possible consequences.