LibreDWG: unbounded allocation in pre-R13 DWG entity decoding
Affects LibreDWG-based tools that call dwg_read_file() on untrusted pre-R13 DWG files. Fixed in 0.14.8413.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 0.14.8413
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
LibreDWG, a free C library for reading and writing DWG (AutoCAD drawing) files, and tools built on it such as dwg2dxf, dwgread, and dwg2svg are affected. A specially crafted pre-R13 DWG file can cause unbounded memory allocation during decoding, which can exhaust memory and crash the program, resulting in denial of service when untrusted files are opened.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
LibreDWG is a free C library to read and write DWG files. Prior to 0.14.8413, a crafted pre-R13 DWG can make `decode_preR13_entities()` in `src/decode.c` enter a nonterminating loop that allocates a new object each iteration. `decode_preR13` in `src/decode_r11.c` computes `size` from the raw file-controlled `entities_start` and `entities_end` header bounds; the callee clamps `end` to `dat->size` but never recalculates `size`. At `end` of input, `bit_read_RC` and `bit_read_RS` stop advancing `dat->byte`, the overflow guard fails because `end` equals `dat->size`, and the no-advance check compares against `oldpos` saved before the loop instead of the previous iteration. This leaves repeated allocation of `dwg->object` entries until allocation fails or the process is OOM-killed, not merely a constant-memory CPU hang. The defect remains after the clamping and no-progress changes associated with the earlier issue 1131. Applications and tools calling `dwg_read_file()` on untrusted files, including `dwg2dxf`, `dwgread` and `dwg2svg`, can suffer denial of service when a user or automated pipeline opens a malformed file; no attacker credentials are required. This issue is fixed in repository nightly version 0.14.8413.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- LibreDWG libredwg
fixed in 0.14.8413
References 4
GitHub · LibreDWG/libredwg
Questions about CVE-2026-62250
What does this mean?
A crafted pre-R13 DWG file can make the decoder loop without end while it allocates memory. The process keeps consuming memory until the OOM killer stops it or allocation fails, which is a denial of service requiring no authentication.Source: github.com
Am I affected, and how do I check?
Affected are LibreDWG-based tools and applications that call dwg_read_file() on untrusted pre-R13 DWG input. Versions of libredwg before 0.14.8413 are in the affected range, so the libredwg version a tool uses is the thing to check.Source: github.com
What should I do about it?
Upgrade libredwg to 0.14.8413 or later.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data