libass: Out-of-bounds read and write in wrap_lines_measure
Affects libass before 0.17.5 when wrap modes other than two are used and an event's last line ends in a literal \n sequence, with the text size exactly matching the glyph array allocation. Fixed in 0.17.5.
- 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.17.5
- 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: total
Summary
libass, a portable subtitle renderer for ASS/SSA subtitle files, can be made to read and write past the end of an internal glyph array when it processes specially crafted subtitle content. This could crash the application, and it is not known to have been used for anything more serious.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
libass is a portable subtitle renderer for the `ASS`/SSA (Advanced Substation Alpha/Substation Alpha) subtitle format. Prior to 0.17.5, libass can overread and overwrite the glyph array in `wrap_lines_measure` while rendering malicious `ASS` content. In `wrap modes other than two`, a final line ending with a literal backslash-n sequence and otherwise consisting only of such sequences or spaces can remain after early trimming and make the line-measurement loops overshoot by one glyph. When the total text size exactly matches the allocated glyph-array capacity, the first loop reads an uninitialized 32-bit fixed-point `pos.x` value, although that value is not subsequently used. The second loop writes `pos.x` and `pos.y` beyond the array, zeroing the first and adding an attacker-controllable offset to the second. No actual exploitation beyond possible denial of service is known; broader exploitation is theoretical and constrained by the addresses, limited writes, and ASLR. This issue is fixed in version 0.17.5.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- libass libass
fixed in 0.17.5
References 3
GitHub · libass/libass
Questions about CVE-2026-61627
What does this mean?
A bug in libass's wrap_lines_measure function reads and writes memory outside the bounds of its buffer. The advisory says the possible effect is a denial of service.Source: github.com
Am I affected, and how do I check?
Versions of libass before 0.17.5 are in scope. The bug needs wrap modes other than two, an event whose last line ends in a literal \n sequence (with only such sequences or spaces otherwise), and a total text size exactly matching the allocated glyph array size. To check a version, run pkg-config --modversion libass or look at the version your application bundles.Source: github.com
What should I do about it?
Upgrade libass to 0.17.5 or later, which contains the fix.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