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.

550 vulnerabilities reference this CWE, most recent first.

GHSA-XHJ4-VRGC-HR34

Vulnerability from github – Published: 2026-04-22 14:37 – Updated: 2026-04-22 14:37
VLAI
Summary
actix-http has HTTP/1.1 CL.TE Request Smuggling
Details

A vulnerability in actix-http's HTTP/1.1 request parser allows an unauthenticated remote client to smuggle requests in deployments where a front-end HTTP intermediary and the Actix backend disagree about whether Content-Length or Transfer-Encoding: chunked defines the request body length.

Severity

Medium. This is an HTTP request smuggling vulnerability that can be triggered over the network without application-level credentials. Exploitation requires a specific proxy topology: an upstream proxy, WAF, load balancer, or similar intermediary must use Content-Length framing while forwarding the conflicting Transfer-Encoding: chunked request to an Actix backend over a reused HTTP/1.1 connection.

Affected Versions

  • actix-http: versions up to and including 3.12.0

Description

HTTP/1.1 requests that contain both Content-Length and Transfer-Encoding: chunked are ambiguous and must be rejected by recipients to avoid request smuggling.

Affected versions of actix-http accepted a request with a syntactically valid Content-Length header and Transfer-Encoding: chunked on the same HTTP/1.1 message. The parser then selected chunked decoding instead of rejecting the conflicting framing signals.

In a CL.TE proxy topology, an intermediary may treat bytes after the declared Content-Length body as part of the first request, while the Actix backend stops at the terminating chunk marker and parses the remaining bytes on the backend connection as a second HTTP request. This creates a backend-side request desynchronization primitive.

The issue is limited to HTTP/1.1 request parsing.

Impact

HTTP request smuggling

  • Attack Vector: Network, unauthenticated.
  • Effect: Backend request desynchronization with low integrity impact to requests processed by the vulnerable Actix service.
  • Scope: Actix services using affected actix-http versions behind an HTTP/1.1 intermediary that forwards ambiguous Content-Length plus Transfer-Encoding: chunked requests and reuses backend connections.

No direct confidentiality, availability, or subsequent-system impact is scored for this advisory.

Fixed Versions

This issue is fixed in actix-http 3.12.1.

The fix rejects HTTP/1.1 requests that contain both Content-Length and Transfer-Encoding: chunked instead of choosing one framing interpretation.

Mitigation

Users should upgrade to actix-http 3.12.1 or later.

Applications that depend on actix-http through actix-web, awc, or another Actix crate should ensure dependency resolution selects actix-http 3.12.1 or later. For example:

cargo update -p actix-http

If an immediate upgrade is not possible, configure all upstream HTTP intermediaries to reject HTTP/1.1 requests that contain both Content-Length and Transfer-Encoding, and avoid forwarding ambiguous request framing to Actix backends.

Credits

Actix thanks mufeedvh who disclosed this issue through coordinated disclosure.

Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "actix-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.12.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-22T14:37:30Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "A vulnerability in `actix-http`\u0027s HTTP/1.1 request parser allows an unauthenticated remote client to smuggle requests in deployments where a front-end HTTP intermediary and the Actix backend disagree about whether `Content-Length` or `Transfer-Encoding: chunked` defines the request body length.\n\n## Severity\n\n**Medium**.\nThis is an HTTP request smuggling vulnerability that can be triggered over the network without application-level credentials. Exploitation requires a specific proxy topology: an upstream proxy, WAF, load balancer, or similar intermediary must use `Content-Length` framing while forwarding the conflicting `Transfer-Encoding: chunked` request to an Actix backend over a reused HTTP/1.1 connection.\n\n## Affected Versions\n\n- `actix-http`: versions up to and including **3.12.0**\n\n## Description\n\nHTTP/1.1 requests that contain both `Content-Length` and `Transfer-Encoding: chunked` are ambiguous and must be rejected by recipients to avoid request smuggling.\n\nAffected versions of `actix-http` accepted a request with a syntactically valid `Content-Length` header and `Transfer-Encoding: chunked` on the same HTTP/1.1 message. The parser then selected chunked decoding instead of rejecting the conflicting framing signals.\n\nIn a CL.TE proxy topology, an intermediary may treat bytes after the declared `Content-Length` body as part of the first request, while the Actix backend stops at the terminating chunk marker and parses the remaining bytes on the backend connection as a second HTTP request. This creates a backend-side request desynchronization primitive.\n\nThe issue is limited to HTTP/1.1 request parsing.\n\n## Impact\n\n**HTTP request smuggling**\n\n* **Attack Vector:** Network, unauthenticated.\n* **Effect:** Backend request desynchronization with low integrity impact to requests processed by the vulnerable Actix service.\n* **Scope:** Actix services using affected `actix-http` versions behind an HTTP/1.1 intermediary that forwards ambiguous `Content-Length` plus `Transfer-Encoding: chunked` requests and reuses backend connections.\n\nNo direct confidentiality, availability, or subsequent-system impact is scored for this advisory.\n\n## Fixed Versions\n\nThis issue is fixed in **actix-http 3.12.1**.\n\nThe fix rejects HTTP/1.1 requests that contain both `Content-Length` and `Transfer-Encoding: chunked` instead of choosing one framing interpretation.\n\n## Mitigation\n\nUsers should upgrade to **actix-http 3.12.1** or later.\n\nApplications that depend on `actix-http` through `actix-web`, `awc`, or another Actix crate should ensure dependency resolution selects `actix-http` 3.12.1 or later. For example:\n\n```bash\ncargo update -p actix-http\n```\n\nIf an immediate upgrade is not possible, configure all upstream HTTP intermediaries to reject HTTP/1.1 requests that contain both `Content-Length` and `Transfer-Encoding`, and avoid forwarding ambiguous request framing to Actix backends.\n## Credits\n\nActix thanks [mufeedvh](https://github.com/mufeedvh) who disclosed this issue through coordinated disclosure.",
  "id": "GHSA-xhj4-vrgc-hr34",
  "modified": "2026-04-22T14:37:30Z",
  "published": "2026-04-22T14:37:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/actix/actix-web/security/advisories/GHSA-xhj4-vrgc-hr34"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/actix/actix-web"
    },
    {
      "type": "WEB",
      "url": "https://github.com/actix/actix-web/releases/tag/http-v3.12.1"
    },
    {
      "type": "WEB",
      "url": "https://www.rfc-editor.org/rfc/rfc9112.html#name-message-body-length"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "actix-http has HTTP/1.1 CL.TE Request Smuggling "
}

GHSA-XJCJ-RMFC-7Q3P

Vulnerability from github – Published: 2022-08-16 00:00 – Updated: 2022-08-18 00:00
VLAI
Details

dproxy-nexgen (aka dproxy nexgen) re-uses the DNS transaction id (TXID) value from client queries, which allows attackers (able to send queries to the resolver) to conduct DNS cache-poisoning attacks because the TXID value is known to the attacker.

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": [],
  "aliases": [
    "CVE-2022-33988"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-15T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "dproxy-nexgen (aka dproxy nexgen) re-uses the DNS transaction id (TXID) value from client queries, which allows attackers (able to send queries to the resolver) to conduct DNS cache-poisoning attacks because the TXID value is known to the attacker.",
  "id": "GHSA-xjcj-rmfc-7q3p",
  "modified": "2022-08-18T00:00:16Z",
  "published": "2022-08-16T00:00:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33988"
    },
    {
      "type": "WEB",
      "url": "https://sourceforge.net/projects/dproxy"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2022/08/14/3"
    },
    {
      "type": "WEB",
      "url": "https://www.usenix.org/conference/usenixsecurity22/presentation/jeitner"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XQ2H-P299-VJWV

Vulnerability from github – Published: 2026-03-05 20:55 – Updated: 2026-03-09 20:45
VLAI
Summary
Pingora vulnerable to HTTP Request Smuggling via Premature Upgrade
Details

Impact

Pingora versions prior to 0.8.0 would immediately forward bytes following a request with an Upgrade header to the backend, without waiting for a 101 Switching Protocols response. This allows an attacker to smuggle requests to the backend and bypass proxy-level security controls.

This vulnerability primarily affects standalone Pingora deployments where a Pingora proxy is exposed to external traffic. An attacker could exploit this to bypass proxy-level ACL controls and WAF logic, poison caches and upstream connections, or perform cross-user attacks by hijacking sessions.

Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as ingress proxies in the CDN stack maintain proper HTTP parsing boundaries and do not prematurely switch to upgraded connection forwarding mode.

Patches

Pingora users should upgrade to Pingora v0.8.0 or higher, which fixes this issue by only switching connection modes after receiving a 101 Switching Protocols response from the backend (hash 824bdeefc61e121cc8861de1b35e8e8f39026ecd). Without a 101 response, subsequent bytes continue to be parsed as HTTP requests.

Workarounds

As a workaround, users may return an error on requests with the Upgrade header present in their request filter logic in order to stop processing bytes beyond the request header and disable downstream connection reuse.

References

See CVE-2026-2833 and the Cloudflare blog post for more details.

Credits

Disclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare Bug Bounty Program.

Severity
9.3 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.7.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "pingora-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-2833"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-05T20:55:29Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Impact\nPingora versions prior to 0.8.0 would immediately forward bytes following a request with an Upgrade header to the backend, without waiting for a 101 Switching Protocols response. This allows an attacker to smuggle requests to the backend and bypass proxy-level security controls.\n\nThis vulnerability primarily affects standalone Pingora deployments where a Pingora proxy is exposed to external traffic. An attacker could exploit this to bypass proxy-level ACL controls and WAF logic, poison caches and upstream connections, or perform cross-user attacks by hijacking sessions.\n\nNote: Cloudflare customers and Cloudflare\u0027s CDN infrastructure were not affected by this vulnerability, as ingress proxies in the CDN stack maintain proper HTTP parsing boundaries and do not prematurely switch to upgraded connection forwarding mode.\n\n### Patches\nPingora users should upgrade to Pingora v0.8.0 or higher, which fixes this issue by only switching connection modes after receiving a 101 Switching Protocols response from the backend (hash 824bdeefc61e121cc8861de1b35e8e8f39026ecd). Without a 101 response, subsequent bytes continue to be parsed as HTTP requests.\n\n### Workarounds\nAs a workaround, users may return an error on requests with the Upgrade header present in their request filter logic in order to stop processing bytes beyond the request header and disable downstream connection reuse.\n\n### References\nSee [CVE-2026-2833](https://www.cve.org/cverecord?id=CVE-2026-2833) and the [Cloudflare blog post](https://blog.cloudflare.com/pingora-oss-smuggling-vulnerabilities/) for more details.\n\n### Credits\nDisclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare [Bug Bounty Program](https://www.cloudflare.com/disclosure/).",
  "id": "GHSA-xq2h-p299-vjwv",
  "modified": "2026-03-09T20:45:48Z",
  "published": "2026-03-05T20:55:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cloudflare/pingora/security/advisories/GHSA-xq2h-p299-vjwv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2833"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cloudflare/pingora"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0033.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Pingora vulnerable to HTTP Request Smuggling via Premature Upgrade"
}

GHSA-XRR7-82JR-V58X

Vulnerability from github – Published: 2026-06-28 03:33 – Updated: 2026-06-28 03:33
VLAI
Details

nghttp2's nghttpx proxy through 1.69.0 forwards an HTTP/1.1 Upgrade request that also carries a Content-Length header and body onto reusable keep-alive backend connections, re-adding the Upgrade and Connection headers while passing Content-Length verbatim. A backend that resolves the resulting ambiguous message in the attacker's favor enables HTTP request/response smuggling and cross-client response-queue poisoning.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-58055"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-28T02:16:32Z",
    "severity": "MODERATE"
  },
  "details": "nghttp2\u0027s nghttpx proxy through 1.69.0 forwards an HTTP/1.1 Upgrade request that also carries a Content-Length header and body onto reusable keep-alive backend connections, re-adding the Upgrade and Connection headers while passing Content-Length verbatim. A backend that resolves the resulting ambiguous message in the attacker\u0027s favor enables HTTP request/response smuggling and cross-client response-queue poisoning.",
  "id": "GHSA-xrr7-82jr-v58x",
  "modified": "2026-06-28T03:33:40Z",
  "published": "2026-06-28T03:33:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58055"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nghttp2/nghttp2/commit/ab28105c4a0197da24f8bfc414bc116055249e1e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bikini/exploitarium/tree/main/nghttp2-nghttpx-upgrade-queue-poison-poc"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/nghttp2-nghttpx-http-request-response-smuggling-via-upgrade-request-with-content-length"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-XRR9-RH8P-433V

Vulnerability from github – Published: 2020-01-27 19:28 – Updated: 2021-01-08 20:32
VLAI
Summary
Request smuggling is possible when both chunked TE and content length specified
Details

Impact

Request smuggling is possible when running behind a proxy that doesn't handle Content-Length and Transfer-Encoding properly or doesn't handle alone \n as a headers separator.

Patches

https://github.com/ktorio/ktor/pull/1547

Workarounds

None except migrating to a better proxy.

References

https://portswigger.net/web-security/request-smuggling https://tools.ietf.org/html/rfc7230#section-9.5

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.ktor:ktor-client-cio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.ktor:ktor-server-cio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-5207"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-01-27T19:28:00Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Impact\nRequest smuggling is possible when running behind a proxy that doesn\u0027t handle Content-Length and Transfer-Encoding properly or doesn\u0027t handle alone \\n as a headers separator.\n\n### Patches\nhttps://github.com/ktorio/ktor/pull/1547\n\n### Workarounds\nNone except migrating to a better proxy.\n\n### References\nhttps://portswigger.net/web-security/request-smuggling\nhttps://tools.ietf.org/html/rfc7230#section-9.5",
  "id": "GHSA-xrr9-rh8p-433v",
  "modified": "2021-01-08T20:32:37Z",
  "published": "2020-01-27T19:28:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ktorio/ktor/security/advisories/GHSA-xrr9-rh8p-433v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5207"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ktorio/ktor/pull/1547"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Request smuggling is possible when both chunked TE and content length specified"
}

GHSA-XV49-34RF-RQV4

Vulnerability from github – Published: 2026-02-03 21:31 – Updated: 2026-03-19 15:31
VLAI
Details

A flaw was found in libsoup, an HTTP client/server library. This HTTP Request Smuggling vulnerability arises from non-RFC-compliant parsing in the soup_filter_input_stream_read_line() logic, where libsoup accepts malformed chunk headers, such as lone line feed (LF) characters instead of the required carriage return and line feed (CRLF). A remote attacker can exploit this without authentication or user interaction by sending specially crafted chunked requests. This allows libsoup to parse and process multiple HTTP requests from a single network message, potentially leading to information disclosure.

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-1801"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-03T21:16:12Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in libsoup, an HTTP client/server library. This HTTP Request Smuggling vulnerability arises from non-RFC-compliant parsing in the soup_filter_input_stream_read_line() logic, where libsoup accepts malformed chunk headers, such as lone line feed (LF) characters instead of the required carriage return and line feed (CRLF). A remote attacker can exploit this without authentication or user interaction by sending specially crafted chunked requests. This allows libsoup to parse and process multiple HTTP requests from a single network message, potentially leading to information disclosure.",
  "id": "GHSA-xv49-34rf-rqv4",
  "modified": "2026-03-19T15:31:10Z",
  "published": "2026-02-03T21:31:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1801"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-1801"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2436315"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.gnome.org/GNOME/libsoup/-/issues/481"
    }
  ],
  "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-XV7J-JR8Q-MHMM

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

Go before 1.12.10 and 1.13.x before 1.13.1 allow HTTP Request Smuggling.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-16276"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-09-30T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "Go before 1.12.10 and 1.13.x before 1.13.1 allow HTTP Request Smuggling.",
  "id": "GHSA-xv7j-jr8q-mhmm",
  "modified": "2022-05-24T16:57:06Z",
  "published": "2022-05-24T16:57:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-16276"
    },
    {
      "type": "WEB",
      "url": "https://github.com/golang/go/issues/34540"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0101"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0329"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0652"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/forum/#!msg/golang-announce/cszieYyuL9Q/g4Z7pKaqAgAJ"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/03/msg00014.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/03/msg00015.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LULL72EUUKIY4NWDZVJVN2LIB4MXHS5P"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/O7GMJ3VXF5RXK2C7CL66KJ6XOOTOL5BJ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/Q5MD2F7ATWSTB45ZJIPJHBAAHVRGRAKG"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20191122-0004"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-11/msg00043.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-11/msg00044.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-XX9P-XXVH-7G8J

Vulnerability from github – Published: 2023-11-14 20:36 – Updated: 2025-11-03 22:31
VLAI
Summary
Aiohttp has inconsistent interpretation of `Content-Length` vs. `Transfer-Encoding` differing in C and Python fallbacks
Details

Impact

Aiohttp has a security vulnerability regarding the inconsistent interpretation of the http protocol. As we know that HTTP/1.1 is persistent, if we have both Content-Length(CL) and Transfer-Encoding(TE) it can lead to incorrect interpretation of two entities that parse the HTTP and we can poison other sockets with this incorrect interpretation.

A possible Proof-of-Concept (POC) would be a configuration with a reverse proxy(frontend) that accepts both CL and TE headers and aiohttp as backend. As aiohttp parses anything with chunked, we can pass a chunked123 as TE, the frontend entity will ignore this header and will parse Content-Length. I can give a Dockerfile with the configuration if you want.

The impact of this vulnerability is that it is possible to bypass any proxy rule, poisoning sockets to other users like passing Authentication Headers, also if it is present an Open Redirect (just like CVE-2021-21330) we can combine it to redirect random users to our website and log the request.

References

  • https://github.com/aio-libs/aiohttp/commit/f016f0680e4ace6742b03a70cb0382ce86abe371
Severity
3.4 (Low)
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:N/A:N
2.3 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "aiohttp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-47641"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-11-14T20:36:25Z",
    "nvd_published_at": "2023-11-14T21:15:13Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nAiohttp has a security vulnerability regarding the inconsistent interpretation of the http protocol. As we know that HTTP/1.1 is persistent, if we have both Content-Length(CL) and Transfer-Encoding(TE) it can lead to incorrect interpretation of two entities that parse the HTTP and we can poison other sockets with this incorrect interpretation.\n\nA possible Proof-of-Concept (POC) would be a configuration with a reverse proxy(frontend) that accepts both CL and TE headers and aiohttp as backend. As aiohttp parses anything with chunked, we can pass a chunked123 as TE, the frontend entity will ignore this header and will parse Content-Length. I can give a Dockerfile with the configuration if you want.\n\nThe impact of this vulnerability is that it is possible to bypass any proxy rule, poisoning sockets to other users like passing Authentication Headers, also if it is present an Open Redirect (just like CVE-2021-21330) we can combine it to redirect random users to our website and log the request.\n\n\n### References\n\n- https://github.com/aio-libs/aiohttp/commit/f016f0680e4ace6742b03a70cb0382ce86abe371",
  "id": "GHSA-xx9p-xxvh-7g8j",
  "modified": "2025-11-03T22:31:34Z",
  "published": "2023-11-14T20:36:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/aio-libs/aiohttp/security/advisories/GHSA-xx9p-xxvh-7g8j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47641"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aio-libs/aiohttp/commit/f016f0680e4ace6742b03a70cb0382ce86abe371"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/aio-libs/aiohttp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aio-libs/aiohttp/releases/tag/v3.8.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/aiohttp/PYSEC-2023-247.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/02/msg00002.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Aiohttp has inconsistent interpretation of `Content-Length` vs. `Transfer-Encoding` differing in C and Python fallbacks"
}

GHSA-XXGG-H2VH-MC43

Vulnerability from github – Published: 2025-12-04 18:30 – Updated: 2025-12-08 18:30
VLAI
Details

Akamai Ghost on Akamai CDN edge servers before 2025-11-17 has a chunked request body processing error that can result in HTTP request smuggling. When Akamai Ghost receives an invalid chunked body that includes a chunk size different from the actual size of the following chunk data, under certain circumstances, Akamai Ghost erroneously forwards the invalid request and subsequent superfluous bytes to the origin server. An attacker could hide a smuggled request in these superfluous bytes. Whether this is exploitable depends on the origin server's behavior and how it processes the invalid request it receives from Akamai Ghost.

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": [],
  "aliases": [
    "CVE-2025-66373"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-04T17:15:56Z",
    "severity": "MODERATE"
  },
  "details": "Akamai Ghost on Akamai CDN edge servers before 2025-11-17 has a chunked request body processing error that can result in HTTP request smuggling. When Akamai Ghost receives an invalid chunked body that includes a chunk size different from the actual size of the following chunk data, under certain circumstances, Akamai Ghost erroneously forwards the invalid request and subsequent superfluous bytes to the origin server. An attacker could hide a smuggled request in these superfluous bytes. Whether this is exploitable depends on the origin server\u0027s behavior and how it processes the invalid request it receives from Akamai Ghost.",
  "id": "GHSA-xxgg-h2vh-mc43",
  "modified": "2025-12-08T18:30:25Z",
  "published": "2025-12-04T18:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66373"
    },
    {
      "type": "WEB",
      "url": "https://en.wikipedia.org/wiki/HTTP_request_smuggling"
    },
    {
      "type": "WEB",
      "url": "https://www.akamai.com/blog/security/cve-2025-66373-http-request-smuggling-chunked-body-size"
    }
  ],
  "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"
    }
  ]
}

GHSA-XXQH-MFJM-7MV9

Vulnerability from github – Published: 2026-05-07 00:18 – Updated: 2026-05-14 20:41
VLAI
Summary
Netty HTTP/1.0 TE+CL Coexistence Bypasses Smuggling Sanitization
Details

NETTY HTTP/1.0 TE+CL Coexistence Bypasses Smuggling Sanitization

Field Value
Library io.netty:netty-codec-http
Component codec-http — HttpObjectDecoder
Severity HIGH
Affects HEAD, commit 4f3533ae confirmed

Summary

HttpObjectDecoder strips a conflicting Content-Length header when a request carries both Transfer-Encoding: chunked and Content-Length, but only for HTTP/1.1 messages. The guard is absent for HTTP/1.0. An attacker that sends an HTTP/1.0 request with both headers causes Netty to decode the body as chunked while leaving Content-Length intact in the forwarded HttpMessage. Any downstream proxy or handler that trusts Content-Length over Transfer-Encoding will disagree on message boundaries, enabling request smuggling.

Root Cause

// HttpObjectDecoder.java:828-833
if (HttpUtil.isTransferEncodingChunked(message)) {
    this.chunked = true;
    if (!contentLengthFields.isEmpty() && message.protocolVersion() == HttpVersion.HTTP_1_1) {
        handleTransferEncodingChunkedWithContentLength(message);  // strips CL — HTTP/1.1 only
    }
    return State.READ_CHUNK_SIZE;
}

// HttpObjectDecoder.java:870-873
protected void handleTransferEncodingChunkedWithContentLength(HttpMessage message) {
    message.headers().remove(HttpHeaderNames.CONTENT_LENGTH);
    contentLength = Long.MIN_VALUE;
}

The conflict-resolution path is gated on message.protocolVersion() == HttpVersion.HTTP_1_1. When the request declares HTTP/1.0, the condition is false, handleTransferEncodingChunkedWithContentLength is never called, and the Content-Length header survives into the forwarded message. Netty still processes the body as chunked; a downstream component that is CL-first interprets the same bytes as a separate request.

Proof of Concept

POST /api HTTP/1.0\r\n
Host: internal.example.com\r\n
Transfer-Encoding: chunked\r\n
Content-Length: 0\r\n
\r\n
5\r\n
GPOST\r\n
0\r\n
\r\n

Netty consumes the full chunked body (5 bytes + terminator). A downstream CL-first proxy reads Content-Length: 0, considers the request complete at the blank line, and treats 5\r\nGPOST\r\n0\r\n\r\n as the start of a second request.

Conditions Required

  1. Netty is deployed behind a reverse proxy or load balancer that is Content-Length-first (nginx, some HAProxy configs, AWS ALB in certain modes).
  2. Attacker can send HTTP/1.0 requests (either directly or by downgrading via connection manipulation).
  3. No additional HTTP/1.0 stripping layer between attacker and Netty.

Impact

Request smuggling at the Netty edge. Allows cache poisoning, session fixation against other users, unauthorized access to internal endpoints, and bypassing of WAF or authentication layers that inspect only the first logical request.

Confirmed PoC Test

Verified against HEAD (4f3533ae) using EmbeddedChannel. Both tests pass, confirming the vulnerability and the HTTP/1.1 contrast.

package io.netty.handler.codec.http;

import io.netty.buffer.Unpooled;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.util.CharsetUtil;
import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.*;

public class NettySmugglingSec001Test {

    // VULNERABLE: Content-Length survives in HTTP/1.0 TE+CL conflict
    @Test
    public void http10_contentLengthNotStripped() {
        EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestDecoder());
        ch.writeInbound(Unpooled.copiedBuffer(
                "POST /api HTTP/1.0\r\n" +
                "Transfer-Encoding: chunked\r\n" +
                "Content-Length: 0\r\n" +
                "\r\n" +
                "5\r\nGPOST\r\n0\r\n\r\n", CharsetUtil.US_ASCII));

        HttpRequest req = ch.readInbound();
        assertEquals(HttpVersion.HTTP_1_0, req.protocolVersion());
        // Content-Length: 0 survives — downstream CL-first proxy treats chunked body as new request
        assertNotNull(req.headers().get(HttpHeaderNames.CONTENT_LENGTH), "VULNERABLE: CL not stripped");
        ch.finishAndReleaseAll();
    }

    // SAFE: HTTP/1.1 correctly strips Content-Length on TE+CL conflict
    @Test
    public void http11_contentLengthStripped() {
        EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestDecoder());
        ch.writeInbound(Unpooled.copiedBuffer(
                "POST /api HTTP/1.1\r\n" +
                "Transfer-Encoding: chunked\r\n" +
                "Content-Length: 0\r\n" +
                "\r\n" +
                "5\r\nGPOST\r\n0\r\n\r\n", CharsetUtil.US_ASCII));

        HttpRequest req = ch.readInbound();
        assertNull(req.headers().get(HttpHeaderNames.CONTENT_LENGTH), "SAFE: CL correctly stripped");
        ch.finishAndReleaseAll();
    }
}

Fix Guidance

Remove the message.protocolVersion() == HttpVersion.HTTP_1_1 guard in HttpObjectDecoder, applying handleTransferEncodingChunkedWithContentLength unconditionally whenever both Transfer-Encoding: chunked and Content-Length are present, regardless of protocol version.

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": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.12.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Alpha1"
            },
            {
              "fixed": "4.2.13.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.132.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.133.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42581"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T00:18:41Z",
    "nvd_published_at": "2026-05-13T19:17:23Z",
    "severity": "MODERATE"
  },
  "details": "# NETTY HTTP/1.0 TE+CL Coexistence Bypasses Smuggling Sanitization\n\n| Field     | Value |\n|-----------|-------|\n| Library   | `io.netty:netty-codec-http` |\n| Component | `codec-http` \u2014 `HttpObjectDecoder` |\n| Severity  | **HIGH** |\n| Affects   | HEAD, commit `4f3533ae` confirmed |\n\n---\n\n## Summary\n\n`HttpObjectDecoder` strips a conflicting `Content-Length` header when a request carries both `Transfer-Encoding: chunked` and `Content-Length`, but only for HTTP/1.1 messages. The guard is absent for HTTP/1.0. An attacker that sends an HTTP/1.0 request with both headers causes Netty to decode the body as chunked while leaving `Content-Length` intact in the forwarded `HttpMessage`. Any downstream proxy or handler that trusts `Content-Length` over `Transfer-Encoding` will disagree on message boundaries, enabling request smuggling.\n\n---\n\n## Root Cause\n\n```java\n// HttpObjectDecoder.java:828-833\nif (HttpUtil.isTransferEncodingChunked(message)) {\n    this.chunked = true;\n    if (!contentLengthFields.isEmpty() \u0026\u0026 message.protocolVersion() == HttpVersion.HTTP_1_1) {\n        handleTransferEncodingChunkedWithContentLength(message);  // strips CL \u2014 HTTP/1.1 only\n    }\n    return State.READ_CHUNK_SIZE;\n}\n\n// HttpObjectDecoder.java:870-873\nprotected void handleTransferEncodingChunkedWithContentLength(HttpMessage message) {\n    message.headers().remove(HttpHeaderNames.CONTENT_LENGTH);\n    contentLength = Long.MIN_VALUE;\n}\n```\n\nThe conflict-resolution path is gated on `message.protocolVersion() == HttpVersion.HTTP_1_1`. When the request declares `HTTP/1.0`, the condition is false, `handleTransferEncodingChunkedWithContentLength` is never called, and the `Content-Length` header survives into the forwarded message. Netty still processes the body as chunked; a downstream component that is CL-first interprets the same bytes as a separate request.\n\n---\n\n## Proof of Concept\n\n```\nPOST /api HTTP/1.0\\r\\n\nHost: internal.example.com\\r\\n\nTransfer-Encoding: chunked\\r\\n\nContent-Length: 0\\r\\n\n\\r\\n\n5\\r\\n\nGPOST\\r\\n\n0\\r\\n\n\\r\\n\n```\n\nNetty consumes the full chunked body (5 bytes + terminator). A downstream CL-first proxy reads `Content-Length: 0`, considers the request complete at the blank line, and treats `5\\r\\nGPOST\\r\\n0\\r\\n\\r\\n` as the start of a second request.\n\n---\n\n## Conditions Required\n\n1. Netty is deployed behind a reverse proxy or load balancer that is `Content-Length`-first (nginx, some HAProxy configs, AWS ALB in certain modes).\n2. Attacker can send HTTP/1.0 requests (either directly or by downgrading via connection manipulation).\n3. No additional HTTP/1.0 stripping layer between attacker and Netty.\n\n---\n\n## Impact\n\nRequest smuggling at the Netty edge. Allows cache poisoning, session fixation against other users, unauthorized access to internal endpoints, and bypassing of WAF or authentication layers that inspect only the first logical request.\n\n---\n\n## Confirmed PoC Test\n\nVerified against HEAD (`4f3533ae`) using `EmbeddedChannel`. Both tests pass, confirming the vulnerability and the HTTP/1.1 contrast.\n\n```java\npackage io.netty.handler.codec.http;\n\nimport io.netty.buffer.Unpooled;\nimport io.netty.channel.embedded.EmbeddedChannel;\nimport io.netty.util.CharsetUtil;\nimport org.junit.jupiter.api.Test;\n\nimport static org.junit.jupiter.api.Assertions.*;\n\npublic class NettySmugglingSec001Test {\n\n    // VULNERABLE: Content-Length survives in HTTP/1.0 TE+CL conflict\n    @Test\n    public void http10_contentLengthNotStripped() {\n        EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestDecoder());\n        ch.writeInbound(Unpooled.copiedBuffer(\n                \"POST /api HTTP/1.0\\r\\n\" +\n                \"Transfer-Encoding: chunked\\r\\n\" +\n                \"Content-Length: 0\\r\\n\" +\n                \"\\r\\n\" +\n                \"5\\r\\nGPOST\\r\\n0\\r\\n\\r\\n\", CharsetUtil.US_ASCII));\n\n        HttpRequest req = ch.readInbound();\n        assertEquals(HttpVersion.HTTP_1_0, req.protocolVersion());\n        // Content-Length: 0 survives \u2014 downstream CL-first proxy treats chunked body as new request\n        assertNotNull(req.headers().get(HttpHeaderNames.CONTENT_LENGTH), \"VULNERABLE: CL not stripped\");\n        ch.finishAndReleaseAll();\n    }\n\n    // SAFE: HTTP/1.1 correctly strips Content-Length on TE+CL conflict\n    @Test\n    public void http11_contentLengthStripped() {\n        EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestDecoder());\n        ch.writeInbound(Unpooled.copiedBuffer(\n                \"POST /api HTTP/1.1\\r\\n\" +\n                \"Transfer-Encoding: chunked\\r\\n\" +\n                \"Content-Length: 0\\r\\n\" +\n                \"\\r\\n\" +\n                \"5\\r\\nGPOST\\r\\n0\\r\\n\\r\\n\", CharsetUtil.US_ASCII));\n\n        HttpRequest req = ch.readInbound();\n        assertNull(req.headers().get(HttpHeaderNames.CONTENT_LENGTH), \"SAFE: CL correctly stripped\");\n        ch.finishAndReleaseAll();\n    }\n}\n```\n\n---\n\n## Fix Guidance\n\nRemove the `message.protocolVersion() == HttpVersion.HTTP_1_1` guard in `HttpObjectDecoder`, applying `handleTransferEncodingChunkedWithContentLength` unconditionally whenever both `Transfer-Encoding: chunked` and `Content-Length` are present, regardless of protocol version.",
  "id": "GHSA-xxqh-mfjm-7mv9",
  "modified": "2026-05-14T20:41:05Z",
  "published": "2026-05-07T00:18:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-xxqh-mfjm-7mv9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42581"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty HTTP/1.0 TE+CL Coexistence Bypasses Smuggling Sanitization"
}
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