EUVD-2026-40175Severity by source
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Attack is delivered over the network via submitted Markdown; no auth or interaction needed; BEAM crash terminates all co-tenant sessions, constituting a scope change beyond the library component.
Primary rating from Vendor (EEF).
CVSS VectorVendor: EEF
Lifecycle Timeline
1DescriptionCVE.org
Memory Allocation with Excessive Size Value vulnerability in leandrocp mdex allows an unauthenticated attacker to cause a denial of service through unbounded memory allocation.
comrak_nif::lumis_adapter::LumisAdapter::parse_highlight_lines in native/comrak_nif/src/lumis_adapter.rs eagerly expands a user-controlled inclusive line range from a fenced code block's highlight_lines decorator into a Vec<usize>, pushing one element per integer in the range with no upper bound on the range size. An attacker who can supply Markdown that an application renders with MDEx.to_html/2 (for example a comment, chat message, or wiki page) can embed a code block whose info string is rust highlight_lines="1-100000000", forcing the native adapter to allocate roughly 8 bytes per line in the range.
A payload that differs by only a few bytes can therefore allocate hundreds of megabytes, and a sufficiently large range (for example 1-2000000000) exhausts host memory and aborts the BEAM, denying service to every user of the rendering process. The per-line write loop additionally tests membership with a linear scan over the same vector, degrading rendering to a quadratic cost even for ranges that do not immediately exhaust memory.
The vulnerable native code originally shipped inside mdex (in native/comrak_nif/src/lumis_adapter.rs) and was later extracted into the separate mdex_native package (native/mdex_native_nif/src/lumis_adapter.rs), where it remains unpatched.
This issue affects mdex from 0.11.0 before 0.12.3, and mdex_native from 0.1.0 before 0.2.3.
AnalysisAI
Unbounded memory allocation in the MDEx Elixir Markdown rendering library allows a remote unauthenticated attacker to exhaust host memory and crash the BEAM virtual machine by submitting a single crafted fenced code block with an oversized highlight_lines range. Any application that renders user-supplied Markdown through MDEx.to_html/2 - such as a comment box, chat message, or wiki page - is exposed; a payload differing by only a few bytes can force hundreds of megabytes to gigabytes of allocation. No public exploit has been identified at time of analysis, though the attack payload is trivially constructable directly from the public advisory, and patched versions 0.12.3 (mdex) and 0.2.3 (mdex_native) are available.
Technical ContextAI
MDEx is an Elixir library that wraps Rust-based Markdown parsing via a Native Implemented Function (NIF), binding to the comrak Markdown parser. The vulnerable function comrak_nif::lumis_adapter::LumisAdapter::parse_highlight_lines in native/comrak_nif/src/lumis_adapter.rs processes the highlight_lines info string on fenced code blocks - a CommonMark extension allowing specific lines to be highlighted. The function materializes the entire user-specified inclusive integer range (e.g., 1-2000000000) into a Vec<usize>, pushing one 8-byte element per integer with no upper-bound cap. This constitutes CWE-789 (Memory Allocation with Excessive Size Value): the allocation size is derived directly from attacker-controlled input without validation. A secondary O(n²) degradation exists because membership tests against the populated vector use a linear scan rather than a set structure, meaning even non-memory-exhausting ranges cause quadratic CPU cost. The same vulnerable code was later extracted into the separate mdex_native package at native/mdex_native_nif/src/lumis_adapter.rs, where it remained unpatched until version 0.2.3. Both CPEs cpe:2.3:a:leandrocp:mdex and cpe:2.3:a:leandrocp:mdex_native are confirmed affected.
RemediationAI
Upgrade mdex to version 0.12.3 or later and mdex_native to version 0.2.3 or later; the upstream fix is available in commit 798a363b4339f6f7162ec8437c4c9f9b5ae6fbf3 at https://github.com/leandrocp/mdex_native/commit/798a363b4339f6f7162ec8437c4c9f9b5ae6fbf3. If immediate patching is not feasible, the most targeted compensating control is to sanitize the fenced code block info string at the application layer before passing Markdown to MDEx - specifically, strip or reject the highlight_lines parameter, or cap the range bounds to a safe maximum (e.g., no range endpoint exceeding 10,000) before calling MDEx.to_html/2; this adds application-layer parsing complexity but avoids the native allocation entirely. Alternatively, restricting the Markdown rendering feature to authenticated or trusted users eliminates anonymous exploitation but may not suit comment or community platforms. Running the BEAM in a containerized environment with strict memory limits (via Linux cgroups or Kubernetes resource limits) reduces blast radius from a full host outage to a single container restart, but does not prevent denial of service for affected users. Advisory details are at https://github.com/leandrocp/mdex_native/security/advisories/GHSA-j93q-9cvj-rxfm.
Unauthenticated denial-of-service in MDEx, an Elixir/Erlang CommonMark parsing library, lets an attacker crash the entir
Stack exhaustion in the mdex and mdex_native Elixir Markdown libraries causes entire-node denial of service when process
Native Rust heap exhaustion in leandrocp mdex and mdex_native allows any attacker who can supply document content to MDE
Cross-site scripting in MDEx (Elixir Markdown library by leandrocp), versions 0.8.3 through 0.13.1, allows any attacker
Stored and reflected cross-site scripting in MDEx's Lumis syntax highlighting adapter allows attackers who can submit Ma
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today