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.
715 vulnerabilities reference this CWE, most recent first.
GHSA-PCX7-8HXG-J823
Vulnerability from github – Published: 2024-11-25 09:30 – Updated: 2024-11-25 19:35Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-jgwc-jh89-rpgq. This link is maintained to preserve external references.
Original Description
A vulnerability was found in the Keycloak Server. The Keycloak Server is vulnerable to a denial of service (DoS) attack due to improper handling of proxy headers. When Keycloak is configured to accept incoming proxy headers, it may accept non-IP values, such as obfuscated identifiers, without proper validation. This issue can lead to costly DNS resolution operations, which an attacker could exploit to tie up IO threads and potentially cause a denial of service. The attacker must have access to send requests to a Keycloak instance that is configured to accept proxy headers, specifically when reverse proxies do not overwrite incoming headers, and Keycloak is configured to trust these headers.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-quarkus-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "24.0.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-quarkus-server"
},
"ranges": [
{
"events": [
{
"introduced": "25.0.0"
},
{
"fixed": "26.0.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2024-11-25T19:35:56Z",
"nvd_published_at": "2024-11-25T08:15:10Z",
"severity": "MODERATE"
},
"details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-jgwc-jh89-rpgq. This link is maintained to preserve external references.\n\n## Original Description\nA vulnerability was found in the Keycloak Server. The Keycloak Server is vulnerable to a denial of service (DoS) attack due to improper handling of proxy headers. When Keycloak is configured to accept incoming proxy headers, it may accept non-IP values, such as obfuscated identifiers, without proper validation. This issue can lead to costly DNS resolution operations, which an attacker could exploit to tie up IO threads and potentially cause a denial of service.\nThe attacker must have access to send requests to a Keycloak instance that is configured to accept proxy headers, specifically when reverse proxies do not overwrite incoming headers, and Keycloak is configured to trust these headers.",
"id": "GHSA-pcx7-8hxg-j823",
"modified": "2024-11-25T19:35:56Z",
"published": "2024-11-25T09:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9666"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:10175"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:10176"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:10177"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:10178"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-9666"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2317440"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Duplicate Advisory: Keycloak proxy header handling Denial-of-Service (DoS) vulnerability",
"withdrawn": "2024-11-25T19:35:56Z"
}
GHSA-PF96-P4FJ-6566
Vulnerability from github – Published: 2026-09-08 20:46 – Updated: 2026-09-08 20:46Summary
HTTPX2 can automatically add a Content-Length header to a request that already contains a caller-supplied Transfer-Encoding header. The resulting HTTP/1.1 request contains both framing headers, which can create an ambiguous message boundary and enable request smuggling or connection desynchronization when processed by intermediaries that disagree about which header takes precedence.
Details
When a request body has a known size, HTTPX2's content encoder returns a default Content-Length. Request._prepare() applies each default header with setdefault(), which only checks whether that same header is already present. It does not check whether the mutually exclusive Transfer-Encoding header is present.
For example:
import httpx2
request = httpx2.Request(
"POST",
"http://example.com/",
headers={"Transfer-Encoding": "chunked"},
content=b"test 123",
)
print(request.headers)
The request contains both:
Transfer-Encoding: chunked
Content-Length: 8
On an HTTP/1.1 connection, the body is serialized using chunked transfer coding while both headers are sent on the wire. This violates HTTP message-framing requirements. Fixed-size byte, JSON, form, and known-length multipart bodies can reach the affected path.
Streaming bodies with an explicit Content-Length are not affected in current HTTPX2 releases because the automatically generated Transfer-Encoding is already suppressed in that direction.
Impact
An attacker may be able to use the conflicting framing headers as a request-smuggling or desynchronization primitive. Exploitation requires an application to pass attacker-controlled request framing headers and associated body data to HTTPX2, use HTTP/1.1, and communicate through a proxy or origin that accepts conflicting headers and interprets them differently from another hop.
Depending on the downstream infrastructure, successful exploitation could interfere with requests sharing a persistent connection, bypass front-end routing or authorization decisions, or poison responses or caches. Applications that do not forward attacker-controlled Transfer-Encoding headers are not directly exposed.
Mitigation
Upgrade to HTTPX2 2.11.0 or later. Patched versions treat Content-Length and Transfer-Encoding as mutually exclusive when applying automatically generated request headers.
If upgrading is not immediately possible, remove Transfer-Encoding and other hop-by-hop framing headers from untrusted input before constructing outbound requests. Applications acting as proxies should derive outbound framing from the body rather than forwarding inbound Content-Length or Transfer-Encoding headers.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "httpx2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.11.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-84380"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-08T20:46:28Z",
"nvd_published_at": "2026-09-02T18:21:29Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nHTTPX2 can automatically add a `Content-Length` header to a request that already contains a caller-supplied `Transfer-Encoding` header. The resulting HTTP/1.1 request contains both framing headers, which can create an ambiguous message boundary and enable request smuggling or connection desynchronization when processed by intermediaries that disagree about which header takes precedence.\n\n### Details\n\nWhen a request body has a known size, HTTPX2\u0027s content encoder returns a default `Content-Length`. `Request._prepare()` applies each default header with `setdefault()`, which only checks whether that same header is already present. It does not check whether the mutually exclusive `Transfer-Encoding` header is present.\n\nFor example:\n\n```python\nimport httpx2\n\nrequest = httpx2.Request(\n \"POST\",\n \"http://example.com/\",\n headers={\"Transfer-Encoding\": \"chunked\"},\n content=b\"test 123\",\n)\n\nprint(request.headers)\n```\n\nThe request contains both:\n\n```text\nTransfer-Encoding: chunked\nContent-Length: 8\n```\n\nOn an HTTP/1.1 connection, the body is serialized using chunked transfer coding while both headers are sent on the wire. This violates HTTP message-framing requirements. Fixed-size byte, JSON, form, and known-length multipart bodies can reach the affected path.\n\nStreaming bodies with an explicit `Content-Length` are not affected in current HTTPX2 releases because the automatically generated `Transfer-Encoding` is already suppressed in that direction.\n\n### Impact\n\nAn attacker may be able to use the conflicting framing headers as a request-smuggling or desynchronization primitive. Exploitation requires an application to pass attacker-controlled request framing headers and associated body data to HTTPX2, use HTTP/1.1, and communicate through a proxy or origin that accepts conflicting headers and interprets them differently from another hop.\n\nDepending on the downstream infrastructure, successful exploitation could interfere with requests sharing a persistent connection, bypass front-end routing or authorization decisions, or poison responses or caches. Applications that do not forward attacker-controlled `Transfer-Encoding` headers are not directly exposed.\n\n### Mitigation\n\nUpgrade to HTTPX2 `2.11.0` or later. Patched versions treat `Content-Length` and `Transfer-Encoding` as mutually exclusive when applying automatically generated request headers.\n\nIf upgrading is not immediately possible, remove `Transfer-Encoding` and other hop-by-hop framing headers from untrusted input before constructing outbound requests. Applications acting as proxies should derive outbound framing from the body rather than forwarding inbound `Content-Length` or `Transfer-Encoding` headers.",
"id": "GHSA-pf96-p4fj-6566",
"modified": "2026-09-08T20:46:28Z",
"published": "2026-09-08T20:46:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pydantic/httpx2/security/advisories/GHSA-pf96-p4fj-6566"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84380"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/httpx2/pull/1137"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/httpx2/commit/829b93a2393212996f613e635261f777d9ec6eab"
},
{
"type": "PACKAGE",
"url": "https://github.com/pydantic/httpx2"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/httpx2/releases/tag/v2.11.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "HTTPX2: Conflicting Content-Length and Transfer-Encoding headers can be auto-generated"
}
GHSA-PG36-WPM5-G57P
Vulnerability from github – Published: 2019-12-20 23:03 – Updated: 2024-11-19 13:55Impact
Waitress implemented a "MAY" part of the RFC7230 (https://tools.ietf.org/html/rfc7230#section-3.5) 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.
Example:
Content-Length: 100[CRLF]
X-Header: x[LF]Content-Length: 0[CRLF]
Would get treated by Waitress as if it were:
Content-Length: 100
X-Header: x
Content-Length: 0
This could potentially get used by attackers to split the HTTP request and smuggle a second request in the body of the first.
Patches
This issue is fixed in Waitress 1.4.0. This brings a range of changes to harden Waitress against potential HTTP request confusions, and may change the behaviour of Waitress behind non-conformist proxies.
Waitress no longer implements the MAY part of the specification and instead requires that all lines are terminated correctly with CRLF. If any lines are found with a bare CR or LF a 400 Bad Request is sent back to the requesting entity.
The Pylons Project recommends upgrading as soon as possible, while validating that the changes in Waitress don't cause any changes in behavior.
Workarounds
Various reverse proxies may have protections against sending potentially bad HTTP requests to the backend, and or hardening against potential issues like this. If the reverse proxy doesn't use HTTP/1.1 for connecting to the backend issues are also somewhat mitigated, as HTTP pipelining does not exist in HTTP/1.0 and Waitress will close the connection after every single request (unless the Keep Alive header is explicitly sent... so this is not a fool proof security method)
Issues/more security issues:
- 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.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-16785"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2019-12-20T23:01:44Z",
"nvd_published_at": "2019-12-20T23:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nWaitress implemented a \u0026amp;quot;MAY\u0026amp;quot; part of the RFC7230 (https://tools.ietf.org/html/rfc7230#section-3.5) which states:\n\n Although the line terminator for the start-line and header fields is\n the sequence CRLF, a recipient MAY recognize a single LF as a line\n terminator and ignore any preceding CR.\n\nUnfortunately 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.\n\nExample:\n\n```\nContent-Length: 100[CRLF]\nX-Header: x[LF]Content-Length: 0[CRLF]\n```\n\nWould get treated by Waitress as if it were:\n\n```\nContent-Length: 100\nX-Header: x\nContent-Length: 0\n```\n\nThis could potentially get used by attackers to split the HTTP request and smuggle a second request in the body of the first.\n\n\n### Patches\n\nThis issue is fixed in Waitress 1.4.0. This brings a range of changes to harden Waitress against potential HTTP request confusions, and may change the behaviour of Waitress behind non-conformist proxies. \n\nWaitress no longer implements the MAY part of the specification and instead requires that all lines are terminated correctly with CRLF. If any lines are found with a bare CR or LF a 400 Bad Request is sent back to the requesting entity.\n\nThe Pylons Project recommends upgrading as soon as possible, while validating that the changes in Waitress don\u0026amp;#39;t cause any changes in behavior.\n\n### Workarounds\n\nVarious reverse proxies may have protections against sending potentially bad HTTP requests to the backend, and or hardening against potential issues like this. If the reverse proxy doesn\u0026amp;#39;t use HTTP/1.1 for connecting to the backend issues are also somewhat mitigated, as HTTP pipelining does not exist in HTTP/1.0 and Waitress will close the connection after every single request (unless the Keep Alive header is explicitly sent... so this is not a fool proof security method)\n\n### Issues/more security issues:\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-pg36-wpm5-g57p",
"modified": "2024-11-19T13:55:58Z",
"published": "2019-12-20T23:03:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Pylons/waitress/security/advisories/GHSA-pg36-wpm5-g57p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-16785"
},
{
"type": "WEB",
"url": "https://github.com/Pylons/waitress/commit/8eba394ad75deaf9e5cd15b78a3d16b12e6b0eba"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0720"
},
{
"type": "WEB",
"url": "https://docs.pylonsproject.org/projects/waitress/en/latest/#security-fixes"
},
{
"type": "PACKAGE",
"url": "https://github.com/Pylons/waitress"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/waitress/PYSEC-2019-136.yaml"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/05/msg00011.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GVDHR2DNKCNQ7YQXISJ45NT4IQDX3LJ7"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LYEOTGWJZVKPRXX2HBNVIYWCX73QYPM5"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "HTTP Request Smuggling: LF vs CRLF handling in Waitress"
}
GHSA-PH7P-H447-H4Q6
Vulnerability from github – Published: 2022-05-24 19:15 – Updated: 2022-05-24 19:15Ping Identity PingAccess before 5.3.3 allows HTTP request smuggling via header manipulation.
{
"affected": [],
"aliases": [
"CVE-2021-31923"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-24T03:15:00Z",
"severity": "MODERATE"
},
"details": "Ping Identity PingAccess before 5.3.3 allows HTTP request smuggling via header manipulation.",
"id": "GHSA-ph7p-h447-h4q6",
"modified": "2022-05-24T19:15:43Z",
"published": "2022-05-24T19:15:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31923"
},
{
"type": "WEB",
"url": "https://docs.pingidentity.com/bundle/pingaccess-53/page/wco1629833104567.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-PHP5-H4GR-Q7J6
Vulnerability from github – Published: 2024-12-14 03:32 – Updated: 2024-12-16 18:31In Menlo On-Premise Appliance before 2.88, web policy may not be consistently applied properly to intentionally malformed client requests. This is fixed in 2.88.2+, 2.89.1+, and 2.90.1+.
{
"affected": [],
"aliases": [
"CVE-2023-29476"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-14T02:15:05Z",
"severity": "CRITICAL"
},
"details": "In Menlo On-Premise Appliance before 2.88, web policy may not be consistently applied properly to intentionally malformed client requests. This is fixed in 2.88.2+, 2.89.1+, and 2.90.1+.",
"id": "GHSA-php5-h4gr-q7j6",
"modified": "2024-12-16T18:31:08Z",
"published": "2024-12-14T03:32:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29476"
},
{
"type": "WEB",
"url": "https://www.menlosecurity.com/published-security-vulnerabilities"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-PJJW-QHG8-P2P9
Vulnerability from github – Published: 2023-11-27 23:15 – Updated: 2023-11-27 23:15Summary
llhttp 8.1.1 is vulnerable to two request smuggling vulnerabilities. Details have not been disclosed yet, so refer to llhttp for future information. The issue is resolved by using llhttp 9+ (which is included in aiohttp 3.8.6+).
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "aiohttp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.8.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2023-11-27T23:15:38Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nllhttp 8.1.1 is vulnerable to two request smuggling vulnerabilities.\nDetails have not been disclosed yet, so refer to llhttp for future information.\nThe issue is resolved by using llhttp 9+ (which is included in aiohttp 3.8.6+).",
"id": "GHSA-pjjw-qhg8-p2p9",
"modified": "2023-11-27T23:15:38Z",
"published": "2023-11-27T23:15:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/security/advisories/GHSA-pjjw-qhg8-p2p9"
},
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/commit/996de2629ef6b4c2934a7c04dfd49d0950d4c43b"
},
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/commit/bcc416e533796d04fb8124ef1e7686b1f338767a"
},
{
"type": "PACKAGE",
"url": "https://github.com/aio-libs/aiohttp"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "aiohttp has vulnerable dependency that is vulnerable to request smuggling"
}
GHSA-PMF4-QHRQ-85QV
Vulnerability from github – Published: 2025-05-12 15:30 – Updated: 2025-05-13 00:31Radware Cloud Web Application Firewall (WAF) before 2025-05-07 allows remote attackers to bypass firewall filters by placing random data in the HTTP request body when using the HTTP GET method.
{
"affected": [],
"aliases": [
"CVE-2024-56523"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-12T15:15:58Z",
"severity": "CRITICAL"
},
"details": "Radware Cloud Web Application Firewall (WAF) before 2025-05-07 allows remote attackers to bypass firewall filters by placing random data in the HTTP request body when using the HTTP GET method.",
"id": "GHSA-pmf4-qhrq-85qv",
"modified": "2025-05-13T00:31:11Z",
"published": "2025-05-12T15:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56523"
},
{
"type": "WEB",
"url": "https://radware.com/solutions/cloud-security"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/722229"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PQXQ-W44R-73XW
Vulnerability from github – Published: 2026-10-20 19:52 – Updated: 2026-10-20 19:52Summary
The pure Python parser is vulnerable to an HTTP request smuggling attack.
Impact
If users are using the Python parser (AIOHTTP_NO_EXTENSIONS, or not a standard wheel installed), then an application may be vulnerable to a request smuggling attack.
Workaround
Switch to the default C parser.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.14.3"
},
"package": {
"ecosystem": "PyPI",
"name": "aiohttp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.14.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-111750"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-20T19:52:21Z",
"nvd_published_at": "2026-10-19T17:17:04Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe pure Python parser is vulnerable to an HTTP request smuggling attack.\n\n### Impact\n\nIf users are using the Python parser (`AIOHTTP_NO_EXTENSIONS`, or not a standard wheel installed), then an application may be vulnerable to a request smuggling attack.\n\n### Workaround\n\nSwitch to the default C parser.",
"id": "GHSA-pqxq-w44r-73xw",
"modified": "2026-10-20T19:52:22Z",
"published": "2026-10-20T19:52:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/security/advisories/GHSA-pqxq-w44r-73xw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-111750"
},
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/commit/9b27347e61454d9f8ca2055f4c67a37dee336e83"
},
{
"type": "PACKAGE",
"url": "https://github.com/aio-libs/aiohttp"
},
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/releases/tag/v3.14.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:L/SA:L",
"type": "CVSS_V4"
}
],
"summary": "AIOHTTP: Pure-Python parser request smuggling"
}
GHSA-PRG5-HG25-8GRQ
Vulnerability from github – Published: 2020-01-31 18:00 – Updated: 2021-01-08 20:32Impact
This vulnerability gives the ability to switch channels via the _channel_code GET parameter in production environments. This was meant to be enabled only when %kernel.debug% is set to true.
However, if no sylius_channel.debug is set explicitly in the configuration, the default value which is %kernel.debug% will be not resolved and cast to boolean, enabling this debug feature even if that parameter is set to false.
Patches
Patch has been provided for Sylius 1.3.x and newer - 1.3.16, 1.4.12, 1.5.9, 1.6.5. Versions older than 1.3 are not covered by our security support anymore.
Workarounds
Unsupported versions could be patched by adding the following configuration to run in production:
sylius_channel:
debug: false
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "sylius/sylius"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.16"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "sylius/sylius"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.0"
},
{
"fixed": "1.4.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "sylius/sylius"
},
"ranges": [
{
"events": [
{
"introduced": "1.5"
},
{
"fixed": "1.5.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "sylius/sylius"
},
"ranges": [
{
"events": [
{
"introduced": "1.6.0"
},
{
"fixed": "1.6.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-5218"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2020-01-27T20:21:16Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\n\nThis vulnerability gives the ability to switch channels via the `_channel_code` GET parameter in production environments. This was meant to be enabled only when `%kernel.debug%` is set to true. \n\nHowever, if no `sylius_channel.debug` is set explicitly in the configuration, the default value which is `%kernel.debug%` will be not resolved and cast to boolean, enabling this debug feature even if that parameter is set to false.\n\n### Patches\n\nPatch has been provided for Sylius 1.3.x and newer - **1.3.16, 1.4.12, 1.5.9, 1.6.5**. Versions older than 1.3 are not covered by our security support anymore.\n\n### Workarounds\n\nUnsupported versions could be patched by adding the following configuration to run in production:\n\n```yaml\nsylius_channel:\n debug: false\n```",
"id": "GHSA-prg5-hg25-8grq",
"modified": "2021-01-08T20:32:23Z",
"published": "2020-01-31T18:00:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Sylius/Sylius/security/advisories/GHSA-prg5-hg25-8grq"
},
{
"type": "WEB",
"url": "https://github.com/Sylius/SyliusResourceBundle/security/advisories/GHSA-8vp7-j5cj-vvm2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5218"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/sylius/resource-bundle/CVE-2020-5220.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Ability to switch channels via GET parameter enabled in production environments"
}
GHSA-PW9P-JVRM-F7RM
Vulnerability from github – Published: 2026-06-26 20:55 – Updated: 2026-06-26 20:55Impact
Psl\H2\ServerConnection does not validate that the total bytes received in DATA frames match the content-length header declared in the HEADERS frame, in violation of RFC 9113 §8.1.1.
A malicious client can: - Send more DATA bytes than declared, smuggling additional content past application-level size limits. - Send fewer DATA bytes than declared and close the stream early, causing applications that trust the declared length to behave incorrectly.
The vulnerability is only reachable for consumers using Psl\H2\ServerConnection directly to accept untrusted client traffic. The high-level Psl\HTTP\Server is in active development and was not yet released at the time of this advisory; consumers of documented high-level PSL APIs are not affected.
Patches
- Parses and validates the
content-lengthheader on incoming HEADERS (server-side only — clients do not enforce this per RFC 9110 §9.3.2). - Tracks cumulative DATA frame payload length per stream.
- Throws
StreamExceptionon mismatch or overflow.
Regression tests landed in #781, 9 of the new tests fail against the pre-fix code, proving the validation boundary is enforced.
Workarounds
None at the protocol layer. Applications using Psl\H2\ServerConnection directly should upgrade.
Resources
- RFC 9113 §8.1.1 (HTTP/2 request/response exchange)
- RFC 9110 §8.6 (content-length header)
- https://github.com/php-standard-library/php-standard-library/releases/tag/6.1.2
- https://github.com/php-standard-library/php-standard-library/releases/tag/6.2.1
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "php-standard-library/h2"
},
"ranges": [
{
"events": [
{
"introduced": "6.1.0"
},
{
"fixed": "6.1.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "php-standard-library/h2"
},
"ranges": [
{
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.2.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "php-standard-library/php-standard-library"
},
"ranges": [
{
"events": [
{
"introduced": "6.1.0"
},
{
"fixed": "6.1.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "php-standard-library/php-standard-library"
},
"ranges": [
{
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48979"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-26T20:55:55Z",
"nvd_published_at": "2026-06-17T21:16:23Z",
"severity": "HIGH"
},
"details": "## Impact\n\n`Psl\\H2\\ServerConnection` does not validate that the total bytes received in DATA frames match the `content-length` header declared in the HEADERS frame, in violation of RFC 9113 \u00a78.1.1.\n\nA malicious client can:\n- Send more DATA bytes than declared, smuggling additional content past application-level size limits.\n- Send fewer DATA bytes than declared and close the stream early, causing applications that trust the declared length to behave incorrectly.\n\nThe vulnerability is only reachable for consumers using `Psl\\H2\\ServerConnection` directly to accept untrusted client traffic. The high-level `Psl\\HTTP\\Server` is in active development and was not yet released at the time of this advisory; consumers of documented high-level PSL APIs are not affected.\n\n## Patches\n\nFixed in [6.1.2](https://github.com/php-standard-library/php-standard-library/releases/tag/6.1.2) and [6.2.1](https://github.com/php-standard-library/php-standard-library/releases/tag/6.2.1).\n\n- Parses and validates the `content-length` header on incoming HEADERS (server-side only \u2014 clients do not enforce this per RFC 9110 \u00a79.3.2).\n- Tracks cumulative DATA frame payload length per stream.\n- Throws `StreamException` on mismatch or overflow.\n\nRegression tests landed in [#781](https://github.com/php-standard-library/php-standard-library/pull/781), 9 of the new tests fail against the pre-fix code, proving the validation boundary is enforced.\n\n## Workarounds\n\nNone at the protocol layer. Applications using `Psl\\H2\\ServerConnection` directly should upgrade.\n\n## Resources\n\n- RFC 9113 \u00a78.1.1 (HTTP/2 request/response exchange)\n- RFC 9110 \u00a78.6 (content-length header)\n- https://github.com/php-standard-library/php-standard-library/releases/tag/6.1.2\n- https://github.com/php-standard-library/php-standard-library/releases/tag/6.2.1",
"id": "GHSA-pw9p-jvrm-f7rm",
"modified": "2026-06-26T20:55:55Z",
"published": "2026-06-26T20:55:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/php-standard-library/php-standard-library/security/advisories/GHSA-pw9p-jvrm-f7rm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48979"
},
{
"type": "PACKAGE",
"url": "https://github.com/php-standard-library/php-standard-library"
},
{
"type": "WEB",
"url": "https://github.com/php-standard-library/php-standard-library/releases/tag/6.1.2"
},
{
"type": "WEB",
"url": "https://github.com/php-standard-library/php-standard-library/releases/tag/6.2.1"
}
],
"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"
}
],
"summary": "PHP Standard Library: HTTP/2 server-side missing content-length validation enables request smuggling"
}
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.