How severe is CVE-2021-21299?

CVE-2021-21299 has a CVSS score of 8.1/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by CVE-2021-21299?

CVE-2021-21299 affects the following packages: hyper (crates.io), hyper (crates.io), hyper (crates.io). Ecosystems affected: crates.io.

How do I fix CVE-2021-21299?

Update hyper to 0.14.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2021-21299 is resolved across your whole dependency graph.

How do I detect CVE-2021-21299 in my crates.io dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for hyper, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate CVE-2021-21299 if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Is CVE-2021-21299 actively exploited in the wild?

No public exploit code has been indexed for CVE-2021-21299 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for CVE-2021-21299?

CVE-2021-21299 has an EPSS (Exploit Prediction Scoring System) score of 4.7%, placing it in the 92th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2021-21299?

CVE-2021-21299 is classified as CWE-444 (CWE-444). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was CVE-2021-21299 published, and has it been updated?

CVE-2021-21299 was published on February 11, 2021 and was last updated on July 9, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🦀

🦀 crates.io

Not in CISA KEV

HIGH severity

CVE-2021-21299 — hyper

HIGHFix: hyperium/hyper@8f93123

CVE-2021-21299 is a high-severity (CVSS 8.1) CWE-444 vulnerability in hyper. A fix is available for hyper — see the affected versions and patch details below.

HTTP Request Smuggling in hyper

Also known asGHSA-6hfq-h8hq-87mfRUSTSEC-2021-0020

Published

Feb 11, 2021

Updated

Jul 9, 2026

Affected

3 pkgs

Patched

3 / 3

Exploits

None indexed

Exploitation data as of Oct 12, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗

4.7%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs92th percentile — riskier than 92% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2021-21299 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 385,738 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

3 pkgs affected

🦀hyper🦀hyper🦀hyper

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.

Description

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.

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.

Affected Packages

3 total 3 fixed

Ecosystem	Package	Vulnerable range	Fix
🦀crates.io	`hyper`	≥ 0.14.0&&< 0.14.3	0.14.3`cargo update -p hyper --precise 0.14.3`
🦀crates.io	`hyper`	≥ 0.13.0&&< 0.13.10	0.13.10`cargo update -p hyper --precise 0.13.10`
🦀crates.io	`hyper`	≥ 0.12.0&&< 0.12.36	0.12.36`cargo update -p hyper --precise 0.12.36`

Affected Products

1 product · 2 configurations

Application

hyperhyper

≥ 0.14.0 && < 0.14.3

range

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for hyper, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update hyper to 0.14.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2021-21299 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

### 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 Trans