CVE-2026-53428: MDEx Memory Allocation DoS Vulnerability

CVE-2026-53428 Overview

CVE-2026-53428 is a memory allocation flaw [CWE-789] in the leandrocp mdex Markdown rendering library and its extracted native package mdex_native. The vulnerability resides in comrak_nif::lumis_adapter::LumisAdapter::parse_highlight_lines, where user-controlled inclusive line ranges from a fenced code block's highlight_lines decorator expand into a Vec<usize> without an upper bound. An unauthenticated attacker who supplies Markdown rendered by MDEx.to_html/2 can trigger unbounded memory allocation, exhaust host memory, and abort the BEAM virtual machine. The issue affects mdex from 0.11.0 before 0.12.3, and mdex_native from 0.1.0 before 0.2.3.

Critical Impact
A single Markdown payload containing a large highlight_lines range can allocate hundreds of megabytes to gigabytes of memory, crashing the BEAM and denying service to all users of the rendering process.

Affected Products

mdex versions 0.11.0 through 0.12.2
mdex_native versions 0.1.0 through 0.2.2
Elixir and Erlang applications using MDEx.to_html/2 to render untrusted Markdown

Discovery Timeline

2026-06-29 - CVE-2026-53428 published to NVD
2026-06-29 - Last updated in NVD database

Technical Details for CVE-2026-53428

Vulnerability Analysis

The vulnerable code lives in native/comrak_nif/src/lumis_adapter.rs (and later native/mdex_native_nif/src/lumis_adapter.rs). When a fenced code block declares a highlight_lines decorator such as rust highlight_lines="1-100000000", parse_highlight_lines eagerly iterates the inclusive range and pushes one usize element into a Vec<usize> for every integer in the range. No validation constrains the range size against document length, memory limits, or any configuration cap.

Because each usize on a 64-bit host consumes 8 bytes, a range of 1-100000000 allocates roughly 800 MB, and a range of 1-2000000000 exhausts typical host memory. The BEAM aborts when the native allocation fails, terminating every process using the rendering worker. A secondary defect compounds the impact: the per-line highlight loop tests membership against the vector using a linear scan, producing quadratic runtime cost even for ranges that stop short of exhausting memory.

Root Cause

The root cause is trust in an attacker-controlled numeric range parsed from Markdown metadata. parse_highlight_lines treats the range as a bounded literal instead of a potentially adversarial input, materializing it into memory before any semantic use. The Rust native implementation performs the allocation outside BEAM's soft memory accounting, so the Erlang scheduler cannot preempt or throttle the request.

Attack Vector

Any surface that accepts Markdown and renders it through MDEx.to_html/2 is reachable. Realistic vectors include user comments, chat messages, forum posts, wiki pages, pull request descriptions, and issue trackers. The attacker submits a fenced code block whose info string contains an oversized highlight_lines range. Rendering the payload triggers the allocation in the native NIF, and the resulting out-of-memory condition crashes the BEAM process handling the render.

No authentication, privileges, or user interaction on the victim side are required beyond normal content submission. See the GitHub Security Advisory GHSA-j93q-9cvj-rxfm and the CNA advisory for CVE-2026-53428 for additional technical detail.

Detection Methods for CVE-2026-53428

Indicators of Compromise

Markdown submissions containing fenced code blocks with highlight_lines="N-M" where M - N exceeds a small document-relevant bound (for example, ranges spanning thousands or millions of lines).
BEAM VM crashes or erl_crash.dump files generated shortly after rendering user-supplied Markdown.
Sudden spikes in resident set size (RSS) of the Elixir/Erlang node correlated with Markdown rendering requests.

Detection Strategies

Inspect application logs and web server access logs for POST bodies containing highlight_lines= with large numeric ranges before they reach the renderer.
Add pre-render validation that parses highlight_lines metadata and rejects ranges above a configured maximum.
Correlate NIF-related memory allocation failures with the identity of the submitting user or API caller.

Monitoring Recommendations

Track memory consumption of the BEAM process and alert on rapid growth during Markdown rendering paths.
Monitor for repeated crashes of worker processes handling MDEx.to_html/2 calls.
Capture and retain the raw Markdown input associated with rendering timeouts or OOM events for forensic review.

How to Mitigate CVE-2026-53428

Immediate Actions Required

Upgrade mdex to 0.12.3 or later.
Upgrade mdex_native to 0.2.3 or later once a fixed release is available. Review the upstream commit for current patch status.
Audit all code paths that pass untrusted Markdown to MDEx.to_html/2 and enumerate exposed submission surfaces.

Patch Information

The fix bounds the expansion of highlight_lines ranges and eliminates the unbounded Vec<usize> growth in parse_highlight_lines. Consult the OSV entry EEF-CVE-2026-53428 and the GitHub Security Advisory GHSA-j93q-9cvj-rxfm for authoritative version guidance.

Workarounds

Strip or reject highlight_lines attributes from fenced code block info strings before rendering.
Enforce a maximum size limit on submitted Markdown documents and cap the numeric span of any N-M range.
Run Markdown rendering in an isolated worker with a strict memory limit (for example, container cgroup limits) so an OOM condition does not affect the primary application node.
Rate-limit anonymous Markdown submissions and require authentication on high-value rendering endpoints.

bash

# Configuration example: pin fixed versions in mix.exs
# {:mdex, "~> 0.12.3"}
mix deps.update mdex
mix deps.get
mix compile