HarfBuzz EUVD-2026-105095

Exploitation requires HarfBuzz to be built with the EXPERIMENTAL WebAssembly shaper enabled (compiled with Wasm/WAMR support, HAVE_WASM) - this feature is disabled in default builds, which is the primary limiting factor. The attacker must supply a crafted font that embeds a WebAssembly module, and that module must arrange its linear memory so the output buffer sits near the end of linear memory, so that font_glyph_to_string's glyph-name write (mis-declared via the wrong WAMR signature) overflows into host memory. A user or application must actually load and shape the malicious font (UI:P / passive interaction). No authentication is required to supply the font (PR:N), but the combination of a non-default experimental shaper plus the precise memory-layout requirement (AT:P) substantially narrows realistic exploitation.

This is a memory-corruption flaw (CWE-787, out-of-bounds write) that looks serious on paper but carries significant real-world limiting factors that lower its practical priority. The CVSS 4.0 vector (7.3) shows AV:L (local), AT:P (a specific attack requirement must be present), PR:N (no privileges), UI:P (passive user interaction), with high confidentiality/integrity/availability impact but no scope change (SC/SI/SA:N) - consistent with corrupting the host process that renders a font rather than breaking out to other systems. The decisive mitigating signal is in the description itself: the bug lives ONLY in the EXPERIMENTAL WebAssembly shaper, which is disabled in default HarfBuzz builds and requires the library to be compiled against a Wasm runtime (WAMR) with the WASM shaper explicitly enabled - so the vast majority of HarfBuzz deployments are NOT affected. No EPSS score, no KEV listing, and no public exploit were provided; exploitation status is therefore 'no public exploit identified at time of analysis.' There is no conflict between signals here, but note that the headline 'HarfBuzz is everywhere' intuition is misleading: the ubiquity of HarfBuzz does NOT translate to ubiquity of the vulnerable configuration. A vendor patch (PR 6414) is confirmed available. Net assessment: a legitimate bug worth patching, but low immediate exploitation urgency given the off-by-default experimental feature and absence of exploitation signals.

An attacker crafts a font file embedding a malicious WebAssembly module and lures a user of an application built with HarfBuzz's experimental Wasm shaper into rendering it. The wasm module arranges its output buffer near the end of linear memory so that when font_glyph_to_string writes glyph-name bytes (using the wrong WAMR signature), the write spills past the buffer into adjacent host memory, crashing or corrupting the application. No public exploit code was identified at time of analysis, and the required memory-layout condition plus the experimental, non-default shaper make reliable exploitation non-trivial.