Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HSummary
CVE-2026-32873 is a high-severity Expired Pointer Dereference (CWE-825) vulnerability in Vshakitskiy Ewe. Its CVSS base score is 7.5 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Application or System Exploitation (T1499.004); ranked at the 46th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SI-2 (Flaw Remediation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-32873 is a denial-of-service vulnerability in the ewe Gleam web server, affecting versions 0.8.0 through 3.0.4. The issue stems from a bug in the handle_trailers function, where rejected trailer headers—either forbidden or undeclared—trigger an infinite loop. Specifically, three code paths (lines 520, 523, and 526) recurse using the original buffer instead of advancing past the rejected header, causing the decoder.decode_packet function to repeatedly parse the same header without timeout or escape. This results in the BEAM process permanently consuming 100% CPU. Applications that invoke ewe.read_body on chunked requests are impacted.
Any unauthenticated remote client can exploit this vulnerability by sending a malicious chunked HTTP request containing rejected trailer headers. Exploitation occurs before control returns to application code, rendering application-level mitigations ineffective. Successful attacks cause a permanent denial of service, as the affected BEAM process wedges indefinitely at full CPU utilization, with a CVSS v3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) reflecting its network accessibility, low complexity, and high availability impact (mapped to CWE-825 and CWE-835).
The vulnerability is addressed in ewe version 3.0.5. The GitHub security advisory (GHSA-4w98-xf39-23gp) and related commits (8513de9dcdd0005f727c0f6f15dd89f8d626f560 and d8b9b8a86470c0cb5696647997c2f34763506e37) detail the fix, which corrects the buffer advancement in the affected code paths to prevent recursion. Security practitioners should upgrade to 3.0.5 or later and monitor for unusual CPU spikes on chunked request handling.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-13428
Vulnerability Data
ewe is a Gleam web server. Versions 0.8.0 through 3.0.4 contain a bug in the handle_trailers function where rejected trailer headers (forbidden or undeclared) cause an infinite loop. When handle_trailers encounters such a trailer, three code paths (lines 520, 523,…
more
526) recurse with the original buffer (rest) instead of advancing past the rejected header (Buffer(header_rest, 0)), causing decoder.decode_packet to re-parse the same header on every iteration. The resulting loop has no timeout or escape — the BEAM process permanently wedges at 100% CPU. Any application that calls ewe.read_body on chunked requests is affected, and this is exploitable by any unauthenticated remote client before control returns to application code, making an application-level workaround impossible. This issue is fixed in version 3.0.5.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation (including fuzzing, static analysis, and dynamic memory checkers) directly finds expired-pointer dereferences before deployment.
Flaw remediation processes identify and correct infinite-loop defects reported from testing or operations.
Requiring documented development processes and secure coding standards reduces introduction of loops whose termination conditions are unreachable.
Secure engineering principles applied during design and implementation can mandate memory-safe allocation, ownership, and deallocation patterns that structurally avoid use of expired pointers.
Process isolation confines the effects of a use-after-free within a single address space, reducing cross-process impact.
Memory-protection mechanisms limit the blast radius when an expired pointer is dereferenced, even though they do not stop the coding flaw itself.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure-development practices directly prevent coding errors such as use-after-free while one CWE contributes only modestly to the full control.
Lifecycle management includes secure development and maintenance phases that reduce memory-safety defects.
Vulnerability identification processes can discover use-after-free flaws via scanning or analysis.
Routine patching and replacement can eliminate known instances of expired-pointer bugs.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect use-after-free issues, but removing this weakness alone does not fulfill the testing control.
Secure development lifecycle practices can include pointer lifetime and memory-management rules that reduce expired-pointer dereferences.
Application security requirements may mandate safe memory handling, but eliminating this single weakness does not satisfy the broader requirement.
Secure architecture and engineering principles can prescribe memory-safety patterns, yet fixing only this weakness does not achieve the control.
Secure coding standards directly address pointer lifetime and deallocation discipline, substantially mitigating expired-pointer dereference.
Change-management processes can require re-validation of memory safety after modifications, indirectly reducing the weakness.