CVE-2026-75820 in Aspell
Summary
by MITRE • 10/06/2026
GNU Aspell contains an integer truncation vulnerability in the WritableDict::add() function in modules/speller/default/writable.cpp. When loading a personal wordlist, the word length is stored as a single byte, causing truncation for words whose length is a multiple of 256. This leads to heap corruption. An attacker can exploit this by convincing a user to run aspell with a crafted personal wordlist containing such a word, resulting in denial of service.
This issue was fixed in commit 782ce94e4dc71eaec4ee1bd945eb3b9c47c5387d which will be released in version 0.60.8.3.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified within GNU Aspell represents a critical memory safety flaw located specifically in the WritableDict::add() function found in the modules/speller/default/writable.cpp source file. This integer truncation issue arises from an improper handling of data types during the processing of personal wordlists loaded by the application. When the software ingests user-defined dictionaries, it calculates and stores the length of each individual word to manage memory allocation and string operations correctly. However, in this specific implementation, the variable designated to hold the word length is defined as a single byte integer type rather than a larger data type such as an unsigned short or integer capable of accommodating longer strings. This architectural decision creates a hard limit on the maximum representable value for any stored metric related to string size within that context.
The operational consequence of this design flaw becomes apparent when processing words whose character count is exactly equal to 256 or any subsequent multiple thereof, such as 512, 768, and so forth. Because a single byte can only represent values from zero to two hundred fifty-five using unsigned arithmetic, any length value exceeding two hundred fifty-five undergoes integer truncation upon storage. For instance, if the actual word length is two hundred fifty-six characters, the system stores it as zero due to modulo arithmetic inherent in fixed-width integer types. This discrepancy between the true memory requirements and the recorded size leads directly to heap corruption during subsequent operations that rely on this incorrect length metadata. The application may allocate insufficient buffer space or perform out-of-bounds writes based on the truncated value, destabilizing the internal data structures of the spell checker engine.
From a security impact perspective, while the primary observed outcome is denial of service through application crash caused by heap corruption, such memory safety violations are frequently precursors to more severe exploitation vectors in other contexts or future code paths. Heap corruption can potentially lead to arbitrary code execution if an attacker can carefully craft input to control the state of freed chunks or overwrite function pointers within adjacent memory regions. Although current analysis indicates that exploiting this specific truncation for remote code execution requires precise conditions not always present, it remains a significant risk factor classified under CWE-190 Integer Overflow or Wraparound and CWE-787 Out-of-bounds Write depending on the exact manifestation of the corruption in different runtime environments. The vulnerability aligns with MITRE ATT&CK technique T1496 Resource Hijacking if utilized for denial of service, though it fundamentally stems from a software quality weakness rather than an explicit attack pattern at this stage.
Mitigation strategies primarily involve upgrading to version 0.60.8.3 or later where the issue has been resolved via commit hash seven eight two c e nine four e d c seven one e a e c e e one b d nine four five e b three b ninety c forty seven c fifty three eight seven d. This fix ensures that word lengths are stored using appropriate data types capable of handling larger values without truncation, thereby preventing the heap corruption scenario entirely. For organizations unable to immediately upgrade, defensive measures include implementing strict input validation at entry points where personal dictionaries are loaded, ensuring that no single token exceeds a reasonable maximum length threshold before processing by Aspell. Additionally, deploying application whitelisting or sandboxing mechanisms can limit the impact of potential crashes on broader system stability and prevent unauthorized execution contexts from leveraging similar vulnerabilities in other components of the spell-checking infrastructure.