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 request smuggling flaw that appears when HTTP message framing is interpreted differently across tiers, especially when a downgraded HTTP/2 request reaches a back end that still honours Transfer-Encoding. In practice, the front end may treat the request as one unit while the back end parses extra bytes as a separate request, creating an integrity break in the request stream.
For NHI and agentic systems, the concern is not only classic web compromise. A desynchronised request path can distort which identity, token, or session context is attached to downstream calls, especially where proxies, gateways, and service meshes are in the chain. Definitions vary across vendors on whether the term is used narrowly for HTTP/2 downgrade paths or more broadly for any framing mismatch, so implementation guidance should be read carefully. The most common misapplication is assuming that HTTP/2 support alone eliminates smuggling risk, which occurs when the front end is modernised but a legacy back end still accepts conflicting framing rules.
For control baselines, NIST Cybersecurity Framework 2.0 is useful for mapping this issue to secure communications and boundary protection, while Ultimate Guide to NHIs helps place request-path trust in the broader identity and secrets-risk model.
Examples and Use Cases
Implementing protections against H2.TE desync rigorously often introduces routing and proxy-configuration constraints, requiring organisations to weigh request-path safety against the operational cost of strict parsing and protocol normalisation.
- A public API gateway receives HTTP/2 traffic, but the origin server still interprets ambiguous transfer framing, allowing an attacker to smuggle a second request past the front end.
- An agentic workflow calls internal tools through a reverse proxy, and the smuggled payload causes the back end to associate the wrong service account context with a downstream action.
- A CI/CD webhook endpoint is fronted by a modern load balancer, yet inconsistent downgrade behaviour lets one request be split into two, resulting in queue poisoning or cache corruption.
- A multi-tenant platform routes third-party traffic through shared infrastructure, and desync creates a path for one tenant’s request metadata to influence another tenant’s response stream.
- Security teams validate mitigations against parsing behaviour described in the PortSwigger request smuggling guidance and use research such as Ultimate Guide to NHIs to understand how compromised request boundaries can expose service identities and secrets.
In practice, H2.TE desync is most often found during edge-proxy testing, cloud migration, or API gateway consolidation, when a new front end is deployed ahead of older application servers that still accept legacy framing assumptions.
Why It Matters in NHI Security
H2.TE desync matters because it can turn transport ambiguity into identity abuse. If an attacker can redirect or splice requests, they may bypass controls that depend on trusted gateway behavior, including token validation, service-to-service authorization, and audit attribution. That is especially dangerous in NHI-heavy environments where service accounts, API keys, and short-lived tokens are expected to move only through approved paths.
The risk is amplified by the broader NHI visibility problem. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, which means many teams cannot reliably trace which identity was used on a malformed or smuggled request. In a degraded incident, that gap makes containment harder and forensics less reliable. Aligning with NIST Cybersecurity Framework 2.0 supports boundary hardening, while Ultimate Guide to NHIs reinforces why identity observability must extend to machine traffic, not just human logins.
Organisations typically encounter this consequence only after an unusual downstream action, cache anomaly, or unexplained backend request appears, at which point H2.TE desync becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Request smuggling can expose or misuse secrets tied to non-human identities. |
| NIST CSF 2.0 | PR.DS | Desync affects the integrity of data in transit across application boundaries. |
| NIST Zero Trust (SP 800-207) | Zero Trust assumes no implicit trust in a request just because it crossed a proxy. | |
| NIST SP 800-63 | IAL/AAL | Smuggling can undermine how identity assertions are bound to a session or request. |
| NIST AI RMF | AI systems that call tools inherit risk from malformed or misparsed requests. |
Harden secret handling and gateway boundaries so machine credentials cannot be replayed or misrouted.
