H2.TE desync is a request smuggling condition created when a downgraded HTTP/2 request reaches a back end that still honours Transfer-Encoding. If the front end and back end disagree on which framing rule applies, the attacker can split or redirect requests and sometimes hijack downstream traffic.
Expanded Definition
H2.TE desync is a specific request smuggling variant that appears when HTTP/2 traffic is translated or downgraded in a way that leaves the front end and back end using different parsing assumptions. The core issue is not HTTP/2 itself, but a disagreement about whether framing is governed by HTTP/2 rules or by the older OWASP Non-Human Identity Top 10 Transfer-Encoding path on the receiving side.
That boundary matters because the attacker is not trying to “break HTTP” in the abstract. They are exploiting a parser mismatch to make one component finish the request at a different point than another component does. In practice, that can let malicious bytes become the start of a separate request, or let a crafted request be attached to a different downstream session than the operator intended. The term is usually discussed alongside other desynchronisation flaws, but H2.TE is narrower: it depends on a downgrade path and a back end that still honours Transfer-Encoding.
Examples and Use Cases
H2.TE desync is most often discussed in layered web architectures where a proxy or load balancer accepts HTTP/2 and forwards traffic to an HTTP/1.1 origin. The problem shows up when the translation layer preserves headers or framing in a way the back end interprets differently.
- A reverse proxy receives an HTTP/2 request, downgrades it, and forwards a message whose framing is understood one way by the proxy and another way by the origin.
- An application gateway normalises some headers but leaves a Transfer-Encoding path available to the back end, creating a split interpretation of where one request ends.
- A shared edge service carries traffic for many tenants, so a successful desync can affect requests beyond the attacker’s own session.
- A security team tests an API gateway and finds that an apparently valid request can be reassembled differently once it reaches the origin server.
The implementation tradeoff is that protocol translation improves compatibility and performance, but every downgrade path increases parser complexity. When the front end and back end are not treated as a single framing system, the weakest interpretation tends to dominate security outcomes.
Security Implications
When H2.TE desync exists, the immediate danger is request boundary confusion. That can let an attacker inject or prefix data that the origin server treats as a separate request, potentially causing cache poisoning, session interference, credential confusion, or response mix-ups. The observable symptom is often inconsistent behaviour: one client sees an unexpected response, a request hangs, or downstream traffic appears to belong to the wrong transaction.
These failures matter because the attack does not need to break authentication directly to create impact. A smuggled request can reach privileged application paths, interfere with routing, or poison shared intermediaries that other users rely on. In environments with high request volume, the blast radius can extend beyond a single user because the desynchronisation affects shared infrastructure rather than one endpoint. For operators, a key warning sign is that the same request succeeds at the edge but behaves differently once it reaches the origin.
Domain and Governance Relevance
H2.TE desync sits in the intersection of web application security, edge proxy governance, and protocol translation control. It is especially relevant where organisations rely on layered delivery chains, because security depends on the front end and back end agreeing on message framing as well as on access policy. In governance terms, this is a control-alignment problem: the architecture can be “working” from a connectivity standpoint while still being unsafe from a request-integrity standpoint.
For identity-adjacent systems, the risk becomes more sensitive when the affected application handles login flows, session tokens, delegated access, or service-to-service calls. A desync in those paths can undermine trust in which request belongs to which actor, even if the identity layer itself is otherwise sound. That is why protocol normalization, origin consistency, and edge-to-back-end testing are part of trustworthy application delivery, not just tuning exercises.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | H2.TE desync enables remote exploitation of exposed web infrastructure. |
| Recommendation — Map desync exposure to T1190 and test public endpoints for parser mismatch abuse. | ||
| CIS Controls v8 | 16 — Application Software Security | H2.TE desync is a web application design and testing issue. |
| Recommendation — Validate edge-to-origin parsing behavior under Control 16 before deploying protocol translation. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Request smuggling can corrupt request integrity and downstream data handling. |
| DE.CM — Security Continuous Monitoring | Desync issues surface through behavioral anomalies and inconsistent responses. | |
| Recommendation — Enforce consistent message framing to preserve request integrity under PR.DS. Monitor for mismatched responses, hangs, and replay-like anomalies under DE.CM. | ||
| OWASP Non-Human Identity Top 10 | NHI-06 — Secrets and Credential Exposure | Desync can redirect or expose sessions and tokens in identity-bearing traffic. |
| Recommendation — Treat token-bearing request paths as high-risk and verify they cannot be smuggled across boundaries. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
