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.

551 vulnerabilities reference this CWE, most recent first.

GHSA-694P-XRHG-X3WM

Vulnerability from github – Published: 2020-03-30 20:54 – Updated: 2023-11-06 11:08
VLAI
Summary
Micronaut's HTTP client is vulnerable to HTTP Request Header Injection
Details

Vulnerability

Micronaut's HTTP client is vulnerable to "HTTP Request Header Injection" due to not validating request headers passed to the client.

Example of vulnerable code:

@Controller("/hello")
public class HelloController {

    @Inject
    @Client("/")
    RxHttpClient client;

    @Get("/external-exploit")
    @Produces(MediaType.TEXT_PLAIN)
    public String externalExploit(@QueryValue("header-value") String headerValue) {
        return client.toBlocking().retrieve(
            HttpRequest.GET("/hello")
                .header("Test", headerValue)
        );
    }
}

In the above case a query value received from a user is passed as a header value to the client. Since the client doesn't validate the header value the request headers and body have the potential to be manipulated.

For example, a user that supplies the following payload, can force the client to make multiple attacker-controlled HTTP requests.

List<String> headerData = List.of(
    "Connection: Keep-Alive", // This keeps the connection open so another request can be stuffed in.
    "",
    "",
    "POST /hello/super-secret HTTP/1.1",
    "Host: 127.0.0.1",
    "Content-Length: 31",
    "",
    "{\"new\":\"json\",\"content\":\"here\"}",
    "",
    ""
);
String headerValue = "H\r\n" + String.join("\r\n", headerData);;
URI theURI =
    UriBuilder
        .of("/hello/external-exploit")
        .queryParam("header-value", headerValue) // Automatically URL encodes data
        .build();
HttpRequest<String> request = HttpRequest.GET(theURI);
String body = client.toBlocking().retrieve(request);

Note that using @HeaderValue instead of @QueryValue is not vulnerable since Micronaut's HTTP server does validate the headers passed to the server, so the exploit can only be triggered by using user data that is not an HTTP header (query values, form data etc.).

Impact

The attacker is able to control the entirety of the HTTP body for their custom requests. As such, this vulnerability enables attackers to perform a variant of Server Side Request Forgery.

Patches

The problem has been patched in the micronaut-http-client versions 1.2.11 and 1.3.2 and above.

Workarounds

Do not pass user data directly received from HTTP request parameters as headers in the HTTP client.

References

Fix commits - https://github.com/micronaut-projects/micronaut-core/commit/9d1eff5c8df1d6cda1fe00ef046729b2a6abe7f1 - https://github.com/micronaut-projects/micronaut-core/commit/6deb60b75517f80c57b42d935f07955c773b766d - https://github.com/micronaut-projects/micronaut-core/commit/bc855e439c4a5ced3d83195bb59d0679cbd95add

For more information

If you have any questions or comments about this advisory:

Credit

Originally reported by @JLLeitschuh

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.micronaut:micronaut-http-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.micronaut:micronaut-http-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.0"
            },
            {
              "fixed": "1.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-7611"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-03-30T20:54:42Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Vulnerability\n\nMicronaut\u0027s HTTP client is vulnerable to \"HTTP Request Header Injection\" due to not validating request headers passed to the client.\n\nExample of vulnerable code:\n\n```java\n@Controller(\"/hello\")\npublic class HelloController {\n\n    @Inject\n    @Client(\"/\")\n    RxHttpClient client;\n\n    @Get(\"/external-exploit\")\n    @Produces(MediaType.TEXT_PLAIN)\n    public String externalExploit(@QueryValue(\"header-value\") String headerValue) {\n        return client.toBlocking().retrieve(\n            HttpRequest.GET(\"/hello\")\n                .header(\"Test\", headerValue)\n        );\n    }\n}\n```\n\nIn the above case a query value received from a user is passed as a header value to the client. Since the client doesn\u0027t validate the header value the request headers and body have the potential to be manipulated.\n\nFor example, a user that supplies the following payload, can force the client to make multiple attacker-controlled HTTP requests.\n\n```java\nList\u003cString\u003e headerData = List.of(\n    \"Connection: Keep-Alive\", // This keeps the connection open so another request can be stuffed in.\n    \"\",\n    \"\",\n    \"POST /hello/super-secret HTTP/1.1\",\n    \"Host: 127.0.0.1\",\n    \"Content-Length: 31\",\n    \"\",\n    \"{\\\"new\\\":\\\"json\\\",\\\"content\\\":\\\"here\\\"}\",\n    \"\",\n    \"\"\n);\nString headerValue = \"H\\r\\n\" + String.join(\"\\r\\n\", headerData);;\nURI theURI =\n    UriBuilder\n        .of(\"/hello/external-exploit\")\n        .queryParam(\"header-value\", headerValue) // Automatically URL encodes data\n        .build();\nHttpRequest\u003cString\u003e request = HttpRequest.GET(theURI);\nString body = client.toBlocking().retrieve(request);\n```\n\nNote that using `@HeaderValue` instead of `@QueryValue` is not vulnerable since Micronaut\u0027s HTTP server does validate the headers passed to the server, so the exploit can only be triggered by using user data that is not an HTTP header (query values, form data etc.).\n\n### Impact\n\nThe attacker is able to control the entirety of the HTTP body for their custom requests.\nAs such, this vulnerability enables attackers to perform a variant of [Server Side Request Forgery](https://cwe.mitre.org/data/definitions/918.html).\n\n### Patches\n\nThe problem has been patched in the `micronaut-http-client` versions 1.2.11 and 1.3.2 and above.\n\n### Workarounds\n\nDo not pass user data directly received from HTTP request parameters as headers in the HTTP client.\n\n### References\n\nFix commits\n- https://github.com/micronaut-projects/micronaut-core/commit/9d1eff5c8df1d6cda1fe00ef046729b2a6abe7f1\n- https://github.com/micronaut-projects/micronaut-core/commit/6deb60b75517f80c57b42d935f07955c773b766d\n- https://github.com/micronaut-projects/micronaut-core/commit/bc855e439c4a5ced3d83195bb59d0679cbd95add\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [micronaut-core](https://github.com/micronaut-projects/micronaut-core)\n* Email us at [info@micronaut.io](mailto:info@micronaut.io)\n\n### Credit\n\nOriginally reported by @JLLeitschuh \n",
  "id": "GHSA-694p-xrhg-x3wm",
  "modified": "2023-11-06T11:08:02Z",
  "published": "2020-03-30T20:54:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/micronaut-projects/micronaut-core/security/advisories/GHSA-694p-xrhg-x3wm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7611"
    },
    {
      "type": "WEB",
      "url": "https://github.com/micronaut-projects/micronaut-core/commit/6deb60b75517f80c57b42d935f07955c773b766d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/micronaut-projects/micronaut-core/commit/9d1eff5c8df1d6cda1fe00ef046729b2a6abe7f1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/micronaut-projects/micronaut-core/commit/bc855e439c4a5ced3d83195bb59d0679cbd95add"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/micronaut-projects/micronaut-core"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JAVA-IOMICRONAUT-561342"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Micronaut\u0027s HTTP client is vulnerable to HTTP Request Header Injection"
}

GHSA-694Q-MQC8-23W4

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

HPE has identified a remote HOST header attack vulnerability in HPE CentralView Fraud Risk Management earlier than version CV 6.1. This issue is resolved in HF16 for HPE CV 6.1 or subsequent version.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-7068"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-08-06T20:29:00Z",
    "severity": "MODERATE"
  },
  "details": "HPE has identified a remote HOST header attack vulnerability in HPE CentralView Fraud Risk Management earlier than version CV 6.1. This issue is resolved in HF16 for HPE CV 6.1 or subsequent version.",
  "id": "GHSA-694q-mqc8-23w4",
  "modified": "2022-05-14T02:41:32Z",
  "published": "2022-05-14T02:41:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7068"
    },
    {
      "type": "WEB",
      "url": "https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbmu03837en_us"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-69F9-5GXW-WVC2

Vulnerability from github – Published: 2026-01-05 22:58 – Updated: 2026-01-06 16:06
VLAI
Summary
AIOHTTP's unicode processing of header values could cause parsing discrepancies
Details

Summary

The Python HTTP parser may allow a request smuggling attack with the presence of non-ASCII characters.

Impact

If a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or AIOHTTP_NO_EXTENSIONS is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections.

Patch: https://github.com/aio-libs/aiohttp/commit/32677f2adfd907420c078dda6b79225c6f4ebce0

Severity
2.7 (Low)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.13.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "aiohttp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.13.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-69224"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-05T22:58:57Z",
    "nvd_published_at": "2026-01-05T23:15:40Z",
    "severity": "LOW"
  },
  "details": "### Summary\nThe Python HTTP parser may allow a request smuggling attack with the presence of non-ASCII characters.\n\n### Impact\nIf a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or AIOHTTP_NO_EXTENSIONS is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections.\n\n------\n\nPatch: https://github.com/aio-libs/aiohttp/commit/32677f2adfd907420c078dda6b79225c6f4ebce0",
  "id": "GHSA-69f9-5gxw-wvc2",
  "modified": "2026-01-06T16:06:40Z",
  "published": "2026-01-05T22:58:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/aio-libs/aiohttp/security/advisories/GHSA-69f9-5gxw-wvc2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69224"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aio-libs/aiohttp/commit/32677f2adfd907420c078dda6b79225c6f4ebce0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/aio-libs/aiohttp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "AIOHTTP\u0027s unicode processing of header values could cause parsing discrepancies"
}

GHSA-6F62-3596-G6W7

Vulnerability from github – Published: 2024-09-22 03:30 – Updated: 2024-09-25 17:53
VLAI
Summary
HTTP Request Smuggling in ruby webrick
Details

An issue was discovered in the WEBrick toolkit through 1.8.1 for Ruby. It allows HTTP request smuggling by providing both a Content-Length header and a Transfer-Encoding header, e.g., "GET /admin HTTP/1.1\r\n" inside of a "POST /user HTTP/1.1\r\n" request. NOTE: the supplier's position is "Webrick should not be used in production."

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": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.8.1"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "webrick"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-47220"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-23T20:43:55Z",
    "nvd_published_at": "2024-09-22T01:15:11Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in the WEBrick toolkit through 1.8.1 for Ruby. It allows HTTP request smuggling by providing both a Content-Length header and a Transfer-Encoding header, e.g., \"GET /admin HTTP/1.1\\r\\n\" inside of a \"POST /user HTTP/1.1\\r\\n\" request. NOTE: the supplier\u0027s position is \"Webrick should not be used in production.\"",
  "id": "GHSA-6f62-3596-g6w7",
  "modified": "2024-09-25T17:53:10Z",
  "published": "2024-09-22T03:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47220"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/webrick/issues/145"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/webrick/issues/145#issuecomment-2369994610"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/webrick/issues/145#issuecomment-2372838285"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/webrick/pull/146/commits/d88321da45dcd230ac2b4585cad4833d6d5e8841"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/webrick/commit/f5faca9222541591e1a7c3c97552ebb0c92733c7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ruby/webrick"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/webrick/CVE-2024-47220.yml"
    }
  ],
  "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 ruby webrick"
}

GHSA-6GPV-F676-PRM8

Vulnerability from github – Published: 2022-05-24 17:12 – Updated: 2022-10-07 00:00
VLAI
Details

There is a vulnerability in Apache Traffic Server 6.0.0 to 6.2.3, 7.0.0 to 7.1.8, and 8.0.0 to 8.0.5 with a smuggling attack and Transfer-Encoding and Content length headers. Upgrade to versions 7.1.9 and 8.0.6 or later versions.

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-1944"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-03-23T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "There is a vulnerability in Apache Traffic Server 6.0.0 to 6.2.3, 7.0.0 to 7.1.8, and 8.0.0 to 8.0.5 with a smuggling attack and Transfer-Encoding and Content length headers. Upgrade to versions 7.1.9 and 8.0.6 or later versions.",
  "id": "GHSA-6gpv-f676-prm8",
  "modified": "2022-10-07T00:00:52Z",
  "published": "2022-05-24T17:12:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1944"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r99d18d0bc4daa05e7d0e5a63e0e22701a421b2ef5a8f4f7694c43869%40%3Cannounce.trafficserver.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2020/dsa-4672"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6HC3-539H-6XC6

Vulnerability from github – Published: 2022-02-11 00:00 – Updated: 2025-10-22 00:32
VLAI
Details

SAP NetWeaver Application Server ABAP, SAP NetWeaver Application Server Java, ABAP Platform, SAP Content Server 7.53 and SAP Web Dispatcher are vulnerable for request smuggling and request concatenation. An unauthenticated attacker can prepend a victim's request with arbitrary data. This way, the attacker can execute functions impersonating the victim or poison intermediary Web caches. A successful attack could result in complete compromise of Confidentiality, Integrity and Availability of the system.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-22536"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-09T23:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "SAP NetWeaver Application Server ABAP, SAP NetWeaver Application Server Java, ABAP Platform, SAP Content Server 7.53 and SAP Web Dispatcher are vulnerable for request smuggling and request concatenation. An unauthenticated attacker can prepend a victim\u0027s request with arbitrary data. This way, the attacker can execute functions impersonating the victim or poison intermediary Web caches. A successful attack could result in complete compromise of Confidentiality, Integrity and Availability of the system.",
  "id": "GHSA-6hc3-539h-6xc6",
  "modified": "2025-10-22T00:32:29Z",
  "published": "2022-02-11T00:00:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22536"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/3123396"
    },
    {
      "type": "WEB",
      "url": "https://wiki.scn.sap.com/wiki/display/PSR/SAP+Security+Patch+Day+-+February+2022"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2022-22536"
    },
    {
      "type": "WEB",
      "url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6HFQ-H8HQ-87MF

Vulnerability from github – Published: 2021-08-25 20:56 – Updated: 2021-08-18 21:07
VLAI
Summary
HTTP Request Smuggling in hyper
Details

Summary

hyper's HTTP server code had a flaw that incorrectly understands some requests with multiple transfer-encoding headers to have a chunked payload, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that understands the request payload boundary differently can result in "request smuggling" or "desync attacks".

Vulnerability

The flaw was introduced in https://github.com/hyperium/hyper/commit/26417fc24a7d05df538e0f39239b373c5c3d61f6, released in v0.12.0.

Consider this example request:

POST /yolo HTTP/1.1
Transfer-Encoding: chunked
Transfer-Encoding: cow

This request should be rejected, according to RFC 7230, since it has a Transfer-Encoding header, but after folding, it does not end in chunked. hyper would notice the chunked in the first line, and then check the second line, and thanks to a missing boolean assignment, not set the error condition. hyper would treat the payload as being chunked. By differing from the spec, it is possible to send requests like these to endpoints that have different HTTP implementations, with different interpretations of the payload semantics, and cause "desync attacks".

There are several parts of the spec that must also be checked, and hyper correctly handles all of those. Additionally, hyper's client does not allow sending requests with improper headers, so the misunderstanding cannot be propagated further.

Read more about desync attacks: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn

Impact

To determine if vulnerable, all these things must be true:

  • Using hyper as an HTTP server. The client is not affected.
  • Using HTTP/1.1. HTTP/2 does not use transfer-encoding.
  • Using a vulnerable HTTP proxy upstream to hyper. If an upstream proxy correctly rejects the illegal transfer-encoding headers, the desync attack cannot succeed. If there is no proxy upstream of hyper, hyper cannot start the desync attack, as the client will repair the headers before forwarding.

Patches

We have released and backported the following patch versions:

  • v0.14.3
  • v0.13.10

Workarounds

Besides upgrading hyper, you can take the following options:

  • Reject requests that contain a transfer-encoding header.
  • Ensure any upstream proxy handles transfer-encoding correctly.

Credits

This issue was initially reported by ZeddYu Lu From Qi An Xin Technology Research Institute.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "hyper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.14.0"
            },
            {
              "fixed": "0.14.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "hyper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.13.0"
            },
            {
              "fixed": "0.13.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "hyper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.12.0"
            },
            {
              "fixed": "0.12.36"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-21299"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-18T21:07:17Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nhyper\u0027s HTTP server code had a flaw that incorrectly understands some requests with multiple transfer-encoding headers to have a chunked payload, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that understands the request payload boundary differently can result in \"request smuggling\" or \"desync attacks\".\n\n### Vulnerability\n\nThe flaw was introduced in https://github.com/hyperium/hyper/commit/26417fc24a7d05df538e0f39239b373c5c3d61f6, released in v0.12.0.\n\nConsider this example request:\n\n```\nPOST /yolo HTTP/1.1\nTransfer-Encoding: chunked\nTransfer-Encoding: cow\n```\n\nThis request *should* be rejected, according to RFC 7230, since it has a `Transfer-Encoding` header, but after folding, it does not end in `chunked`. hyper would notice the `chunked` in the first line, and then check the second line, and thanks to a missing boolean assignment, *not* set the error condition. hyper would treat the payload as being `chunked`. By differing from the spec, it is possible to send requests like these to endpoints that have different HTTP implementations, with different interpretations of the payload semantics, and cause \"desync attacks\".\n\nThere are several parts of the spec that must also be checked, and hyper correctly handles all of those. Additionally, hyper\u0027s *client* does not allow sending requests with improper headers, so the misunderstanding cannot be propagated further.\n\nRead more about desync attacks: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn\n\n### Impact\n\nTo determine if vulnerable, all these things must be true:\n\n- **Using hyper as an HTTP *server*.** The client is not affected.\n- **Using HTTP/1.1.** HTTP/2 does not use `transfer-encoding`.\n- **Using a vulnerable HTTP proxy upstream to hyper.** If an upstream proxy correctly rejects the illegal transfer-encoding headers, the desync attack cannot succeed. If there is *no* proxy upstream of hyper, hyper cannot *start* the desync attack, as the client will repair the headers before forwarding.\n\n### Patches\n\nWe have released and backported the following patch versions:\n\n- v0.14.3\n- v0.13.10\n\n### Workarounds\n\nBesides upgrading hyper, you can take the following options:\n\n- Reject requests that contain a `transfer-encoding` header.\n- Ensure any upstream proxy handles `transfer-encoding` correctly.\n\n### Credits\n\nThis issue was initially reported by ZeddYu Lu From Qi An Xin Technology Research Institute.",
  "id": "GHSA-6hfq-h8hq-87mf",
  "modified": "2021-08-18T21:07:17Z",
  "published": "2021-08-25T20:56:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/hyperium/hyper/security/advisories/GHSA-6hfq-h8hq-87mf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21299"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hyperium/hyper/commit/8f93123efef5c1361086688fe4f34c83c89cec02"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hyperium/hyper"
    },
    {
      "type": "WEB",
      "url": "https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2021-0020.html"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "HTTP Request Smuggling in hyper"
}

GHSA-6J2Q-C73V-97C5

Vulnerability from github – Published: 2025-05-30 06:30 – Updated: 2025-07-28 20:34
VLAI
Summary
Spring Cloud Gateway Server Forwards Headers from Untrusted Proxies
Details

Spring Cloud Gateway Server forwards the X-Forwarded-For and Forwarded headers from untrusted proxies.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.cloud:spring-cloud-gateway-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0"
            },
            {
              "fixed": "4.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.cloud:spring-cloud-gateway-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.1.0"
            },
            {
              "fixed": "4.1.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.cloud:spring-cloud-gateway-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "last_affected": "4.0.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.cloud:spring-cloud-gateway-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.cloud:spring-cloud-gateway-server-mvc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.1.7"
            },
            {
              "fixed": "4.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-41235"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-30T15:25:10Z",
    "nvd_published_at": "2025-05-30T06:15:26Z",
    "severity": "HIGH"
  },
  "details": "Spring Cloud Gateway Server forwards the X-Forwarded-For\u00a0and Forwarded\u00a0headers from untrusted proxies.",
  "id": "GHSA-6j2q-c73v-97c5",
  "modified": "2025-07-28T20:34:06Z",
  "published": "2025-05-30T06:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41235"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/spring-cloud/spring-cloud-gateway"
    },
    {
      "type": "WEB",
      "url": "https://spring.io/security/cve-2025-41235"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Spring Cloud Gateway Server Forwards Headers from Untrusted Proxies"
}

GHSA-6JV3-5F52-599M

Vulnerability from github – Published: 2026-06-15 20:22 – Updated: 2026-06-15 20:22
VLAI
Summary
python-multipart: Semicolon treated as querystring field separator enables parameter smuggling
Details

Summary

QuerystringParser treated ; as a field separator in application/x-www-form-urlencoded bodies, in addition to &. The WHATWG URL standard, modern browsers, and Python's urllib.parse (since the CVE-2021-23336 fix) treat only & as a separator. This creates a parser differential: the same bytes are tokenized into different fields than a WHATWG compliant intermediary would produce, allowing an attacker to smuggle extra form fields past an upstream body inspecting component.

Details

In python_multipart/multipart.py, the FIELD_NAME and FIELD_DATA states located the next separator by scanning for & and, failing that, for ;:

sep_pos = data.find(b"&", i)
if sep_pos == -1:
    sep_pos = data.find(b";", i)

As a result, ; acted as a field boundary. Because the fallback only triggered when no & remained in the current chunk, tokenization also depended on unrelated bytes later in the buffer and on how the body was split across write() calls. This is the same class of issue as CVE-2021-23336 in CPython's urllib.parse.

For example, a body inspecting WAF or gateway that follows the WHATWG rule (only & separates fields) receives:

role=user&x=;role=admin

The upstream parses two fields, role=user and x=";role=admin", sees a benign role=user, and forwards the request. QuerystringParser parsed the same bytes as three fields: role="user", x="", and role="admin". The application (for example via Starlette/FastAPI request.form(), where the last value wins) then received role=admin, a value the upstream validator never saw.

The parser is reachable through the public QuerystringParser class, the high level FormParser, create_form_parser, and parse_form APIs, and Starlette/FastAPI request.form() for url encoded bodies.

Impact

Interpretation conflict / HTTP parameter pollution. An attacker can smuggle extra or overriding form fields past an upstream component that applies the WHATWG separator rule, reaching the backend with parameters the intermediary did not observe.

Mitigation

Upgrade to python-multipart 0.0.30 or later, which treats only & as a field separator per the WHATWG URL standard. ; is parsed as ordinary field data, matching urllib.parse, browsers, and other compliant parsers.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "python-multipart"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.30"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53538"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436",
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T20:22:25Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\n\n`QuerystringParser` treated `;` as a field separator in `application/x-www-form-urlencoded` bodies, in addition to `\u0026`. The [WHATWG URL standard](https://url.spec.whatwg.org/#urlencoded-parsing), modern browsers, and Python\u0027s `urllib.parse` (since the CVE-2021-23336 fix) treat only `\u0026` as a separator. This creates a parser differential: the same bytes are tokenized into different fields than a WHATWG compliant intermediary would produce, allowing an attacker to smuggle extra form fields past an upstream body inspecting component.\n\n### Details\n\nIn `python_multipart/multipart.py`, the `FIELD_NAME` and `FIELD_DATA` states located the next separator by scanning for `\u0026` and, failing that, for `;`:\n\n```python\nsep_pos = data.find(b\"\u0026\", i)\nif sep_pos == -1:\n    sep_pos = data.find(b\";\", i)\n```\n\nAs a result, `;` acted as a field boundary. Because the fallback only triggered when no `\u0026` remained in the current chunk, tokenization also depended on unrelated bytes later in the buffer and on how the body was split across `write()` calls. This is the same class of issue as CVE-2021-23336 in CPython\u0027s `urllib.parse`.\n\nFor example, a body inspecting WAF or gateway that follows the WHATWG rule (only `\u0026` separates fields) receives:\n\n```\nrole=user\u0026x=;role=admin\n```\n\nThe upstream parses two fields, `role=user` and `x=\";role=admin\"`, sees a benign `role=user`, and forwards the request. `QuerystringParser` parsed the same bytes as three fields: `role=\"user\"`, `x=\"\"`, and `role=\"admin\"`. The application (for example via Starlette/FastAPI `request.form()`, where the last value wins) then received `role=admin`, a value the upstream validator never saw.\n\nThe parser is reachable through the public `QuerystringParser` class, the high level `FormParser`, `create_form_parser`, and `parse_form` APIs, and Starlette/FastAPI `request.form()` for url encoded bodies.\n\n### Impact\n\nInterpretation conflict / HTTP parameter pollution. An attacker can smuggle extra or overriding form fields past an upstream component that applies the WHATWG separator rule, reaching the backend with parameters the intermediary did not observe.\n\n### Mitigation\n\nUpgrade to `python-multipart` `0.0.30` or later, which treats only `\u0026` as a field separator per the [WHATWG URL standard](https://url.spec.whatwg.org/#urlencoded-parsing). `;` is parsed as ordinary field data, matching `urllib.parse`, browsers, and other compliant parsers.",
  "id": "GHSA-6jv3-5f52-599m",
  "modified": "2026-06-15T20:22:25Z",
  "published": "2026-06-15T20:22:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Kludex/python-multipart/security/advisories/GHSA-6jv3-5f52-599m"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Kludex/python-multipart"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "python-multipart: Semicolon treated as querystring field separator enables parameter smuggling"
}

GHSA-6JWC-QR2Q-7XWJ

Vulnerability from github – Published: 2023-08-03 16:36 – Updated: 2023-08-10 22:16
VLAI
Summary
protocol-http1 HTTP Request/Response Smuggling vulnerability
Details

Impact

RFC 9112 Section 7.1 defined the format of chunk size, chunk data and chunk extension (detailed ABNF is in Appendix section).

In summary:

  • The value of Content-Length header should be a string of 0-9 digits.
  • The chunk size should be a string of hex digits and should split from chunk data using CRLF.
  • The chunk extension shouldn't contain any invisible character.

However, we found that Falcon has following behaviors while disobey the corresponding RFCs.

  • Falcon accepts Content-Length header values that have "+" prefix.
  • Falcon accepts Content-Length header values that written in hexadecimal with "0x" prefix.
  • Falcon accepts "0x" and "+" prefixed chunk size.
  • Falcon accepts LF in chunk extension.

This behavior can lead to desync when forwarding through multiple HTTP parsers, potentially results in HTTP request smuggling and firewall bypassing. Note that while these issues were reproduced in Falcon (the server), the issue is with protocol-http1 which implements the HTTP/1 protocol parser. We have not yet been advised of any real world exploit or practical attack.

Patches

Fixed in protocol-http1 v0.15.1+.

Workarounds

None.

References

https://github.com/socketry/protocol-http1/pull/20

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "protocol-http1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.15.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-38697"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-08-03T16:36:34Z",
    "nvd_published_at": "2023-08-04T18:15:15Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\n[RFC 9112 Section 7.1](https://www.rfc-editor.org/rfc/rfc9112#name-chunked-transfer-coding) defined the format of chunk size, chunk data and chunk extension (detailed ABNF is in Appendix section).\n\nIn summary:\n\n- The value of Content-Length header should be a string of 0-9 digits.\n- The chunk size should be a string of hex digits and should split from chunk data using CRLF.\n- The chunk extension shouldn\u0027t contain any invisible character.\n\nHowever, we found that Falcon has following behaviors while disobey the corresponding RFCs.\n\n- Falcon accepts Content-Length header values that have \"+\" prefix.\n- Falcon accepts Content-Length header values that written in hexadecimal with \"0x\" prefix.\n- Falcon accepts \"0x\" and \"+\" prefixed chunk size.\n- Falcon accepts LF in chunk extension.\n\nThis behavior can lead to desync when forwarding through multiple HTTP parsers, potentially results in HTTP request smuggling and firewall bypassing. Note that while these issues were reproduced in Falcon (the server), the issue is with `protocol-http1` which implements the HTTP/1 protocol parser. We have not yet been advised of any real world exploit or practical attack.\n\n### Patches\n\nFixed in `protocol-http1` v0.15.1+.\n\n### Workarounds\n\nNone.\n\n### References\n\nhttps://github.com/socketry/protocol-http1/pull/20",
  "id": "GHSA-6jwc-qr2q-7xwj",
  "modified": "2023-08-10T22:16:47Z",
  "published": "2023-08-03T16:36:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/socketry/protocol-http1/security/advisories/GHSA-6jwc-qr2q-7xwj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38697"
    },
    {
      "type": "WEB",
      "url": "https://github.com/socketry/protocol-http1/pull/20"
    },
    {
      "type": "WEB",
      "url": "https://github.com/socketry/protocol-http1/commit/e11fc164fd2b36f7b7e785e69fa8859eb06bcedd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/protocol-http1/CVE-2023-38697.yml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/socketry/protocol-http1"
    },
    {
      "type": "WEB",
      "url": "https://www.rfc-editor.org/rfc/rfc9112#name-chunked-transfer-coding"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "protocol-http1 HTTP Request/Response Smuggling vulnerability"
}
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