Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGuest runs in WASIp3 wasi-http embedder
-
ExploitForward existing request/response body with trailers
-
ExecutionTrailers bypass is_forbidden_header hook
-
ImpactEmbedder-restricted header passes through
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Alternate path protection
|
| Exploitation Conditions | Exploitation requires an embedder running the wasi-http p3 (WASIp3) implementation that has customized WasiHttpHooks::is_forbidden_header to enforce header restrictions beyond the DEFAULT_FORBIDDEN_HEADERS set, and a WASIp3 guest that forwards an existing request or response body carrying trailers. The bypass is strictly limited to forwarded-body trailers - the hook still applies to directly-set headers, and forwarded trailers are still checked against DEFAULT_FORBIDDEN_HEADERS, so embedders relying only on defaults are unaffected. Deployments not using wasi-http p3, or not customizing the forbidden-header hook, have no exposure. Importantly, even after installing 48.0.7 or 49.0.4, embedders that customized is_forbidden_header must additionally implement the new WasiHttpHooks::forbidden_header_filter method to fully receive the fix; otherwise forwarded trailers continue to be filtered only against DEFAULT_FORBIDDEN_HEADERS. |
| Impact | This is a genuinely low-to-moderate-priority issue despite being network-reachable, and the signals are consistent rather than conflicting. The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N) scores 6.3 (Medium), but the impact metrics tell the real story: only VI:L (low integrity) with VC:N and VA:N - no confidentiality or availability impact, and no scope change (SC/SI/SA all N). The high attack complexity (AC:H) and present attack requirement (AT:P) reflect that exploitation only matters in a specific, non-default embedder configuration. The vendor advisory explicitly states 'There is no known attack that this enables,' which strongly tempers the Medium score - this is a defense-in-depth / policy-integrity defect, not a directly exploitable breach. No EPSS score was provided in the input and the CVE is not in CISA KEV, so there is no evidence of exploitation probability or active use. No verified exploit code is referenced. The vuln.today priority is 'this_month,' aligning with a fix-on-normal-patch-cycle posture rather than emergency. Note the 'Information Disclosure' tag is in slight tension with the CVSS vector, which records an integrity impact (VI:L) and explicitly zero confidentiality impact (VC:N) - treat the impact as a header-filtering/policy bypass rather than confirmed data disclosure. |
| Exploit ScenarioDerived | In an embedder that has customized the WasiHttpHooks::is_forbidden_header hook to enforce header restrictions stricter than the default set, a malicious or buggy WASIp3 guest forwards an existing request or response body whose trailers carry a header the embedder intended to block. Because forwarded trailers skip the custom hook, the restricted header reaches its destination, undermining the embedder's intended policy. No public exploit is identified at time of analysis, and the vendor notes no known concrete attack this enables. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Nov 03, 2026
Wasmtime's wasi-http p3 (WASIp3) implementation does not pass forwarded body trailers through the embedder's WasiHttpHooks::is_forbidden_header check, so a WASIp3 guest that forwards an existing request or response body can attach trailers that escape embedder-customized forbidden-header restrictions. Versions 46.0.0 through 48.0.6 and 49.0.0 through 49.0.3 of the rust/wasmtime-wasi-http crate are affected; the issue is network-reachable and unauthenticated per the CVSS v4.0 vector (6.3), but impact is limited to integrity of trailer filtering with no confidentiality or availability effect, and it only matters to embedders that customized the hook beyond DEFAULT_FORBIDDEN_HEADERS. There is no CISA KEV entry and no public exploit identified at time of analysis, and the vendor advisory states there is no known attack this enables even though it can undermine a property the embedder intended to enforce.
RemediationAI
Vendor-released patch: upgrade to Wasmtime 48.0.7 or 49.0.4, or move to 50.0.0/main where the hook is replaced by WasiHttpHooks::forbidden_header_filter; details and patch notes are in GHSA-jxcf-8qw5-5c33 (https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-jxcf-8qw5-5c33). Installing the patch release alone is not sufficient for every deployment: because 48.0.7 and 49.0.4 keep is_forbidden_header for semver compatibility and define it in terms of the new method, embedders that customized is_forbidden_header must also implement WasiHttpHooks::forbidden_header_filter, otherwise forwarded body trailers continue to be filtered only against the DEFAULT_FORBIDDEN_HEADERS set and the bypass remains in place for those embedders. Deployments that do not use wasi-http p3, or that rely solely on the default forbidden-header set without customizing the hook, are unaffected and require no additional mitigation. The advisory describes no alternative workaround beyond upgrading and implementing the new hook method.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Wasmtime is the Bytecode Alliance's WebAssembly runtime, and its wasi-http p3 (WASIp3) implementation exposes HTTP request and response handling to component-model guests while letting embedders supply WasiHttpHooks implementations that constrain what guests may send, including through the is_forbidden_header hook. The root cause is CWE-424, Improper Protection of Alternate Path: when a guest forwards an existing request or response body, the trailers attached to that body are not run through is_forbidden_header, so a policy enforced on directly-set headers is silently not enforced on forwarded trailers. The gap is narrow in scope - the hook still governs directly-set headers, and forwarded trailers are still filtered against the built-in DEFAULT_FORBIDDEN_HEADERS set, so embedders relying only on defaults are unaffected, as are deployments not using wasi-http p3 or not customizing the hook. The upstream fix refactors the check into a new boxed-closure method, WasiHttpHooks::forbidden_header_filter; in the 48.0.7 and 49.0.4 patch releases is_forbidden_header is retained for semver compatibility but redefined in terms of the new method, while main and the 50.0.0 release branch replace it outright. The affected code is tracked at the crate level as rust/wasmtime-wasi-http, with the CPE cpe:2.3:a:bytecodealliance:wasmtime applying at the product level. The advisory does not describe a concrete attack beyond defeating the embedder's intended trailer restrictions, and the trigger is the forwarding of an existing request or response body carrying trailers.
Know when Wasmtime gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Network-reachable via an untrusted guest (PR:N) but gated on a non-default custom-hook configuration (AC:H); impact is a header-policy integrity bypass only (I:L), with no confidentiality or availability effect and no scope change.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
1DescriptionCVE.org
Wasmtime 46.0.0 before 48.0.7 and 49.0.0 before 49.0.4 fails to check forwarded trailers against the WasiHttpHooks::is_forbidden_header hook in wasi-http p3. WASIp3 guests can forward a request or response body so its trailers skip embedder-customized forbidden header filtering, undermining header restrictions the embedder intended.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Sandbox escape in Wasmtime on aarch64 lets a user-supplied WebAssembly module redirect an oversized br_table branch to a
Wasmtime versions before 36.0.19, and the 37.0.0 through 42.x line, can silently miscompile attacker-supplied WebAssembl
wasmtime is a fast and secure runtime for WebAssembly. Rated critical severity (CVSS 9.9), this vulnerability is remotel
Wasmtime is a standalone runtime for WebAssembly. Rated critical severity (CVSS 9.8), this vulnerability is remotely exp
Wasmtime is a standalone JIT-style runtime for WebAssembly, using Cranelift. Rated critical severity (CVSS 9.8), this vu
wasmtime is a runtime for WebAssembly. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity. Pu
Memory sandbox escape in Wasmtime's Winch compiler (versions 25.0.0 to before 36.0.7, 42.0.2, 43.0.1) enables authentica
Arbitrary memory read/write vulnerability in Bytecode Alliance Wasmtime versions 32.0.0 through 36.0.6, 42.0.0-42.0.1, a
Wasmtime is a standalone runtime for WebAssembly. Rated high severity (CVSS 8.8), this vulnerability is remotely exploit
Wasmtime is a standalone runtime for WebAssembly. Rated high severity (CVSS 8.8), this vulnerability is remotely exploit
Wasmtime is a standalone runtime for WebAssembly. Rated high severity (CVSS 8.6), this vulnerability is remotely exploit
Wasmtime's HTTP header handling in the wasmtime-wasi-http crate crashes when processing excessive header fields, allowin
EUVD-2026-115862
GHSA-j86m-34pm-p9mv
NVD
CVE.org
Vulnrichment
Exploit-DB