CVE-2026-53428

Unbounded memory allocation in highlight_lines range expansion in mdex

MEDIUM
6.9
CVSS Score
Published: June 29, 2026 at 06:52 PM UTC
Updated: July 2, 2026 at 01:52 AM UTC
1 product affected across 1 vendorMDEx

Using mdex by leandrocp?

Get instant alerts when new vulnerabilities affect mdex - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM6.9
Exploit prediction
EPSS 0.2%
SSVC
No known exploit

Description

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

0.1.0 ≤ v < 0.2.30.11.0 ≤ v < 0.12.30.1.00.11.0956528c5e31746253347029e810a969ab916fd27a8407611715d1ead35fbcba79c72cef1b7df387b
Vendor states this is fixed in 6ed94d905f97af188323f042698ae841c02293b4 (fixed)
Vendor states this is fixed in 798a363b4339f6f7162ec8437c4c9f9b5ae6fbf3 (fixed)
Affected range stops below 0.12.3, so it looks safe — our inference, not a vendor statement
Affected range stops below 0.2.3, so it looks safe — our inference, not a vendor statement

Remediation

No guide yet

No remediation guidance has been written for this CVE yet. What the record does show:

SSVC — Action Prioritization

SSVCNo known exploitNot automatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

6.9MEDIUMEEF
Vector?

Quick Info

StatusDEFERRED
CWE
CWE-789

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card