GNU Aspell
Don't miss out!
Thousands of developers use stack.watch to stay informed.Get an email whenever new security vulnerabilities are reported in GNU Aspell.
By the Year
In 2026 there have been 3 vulnerabilities in GNU Aspell with an average score of 1.8 out of ten. Aspell did not have any published security vulnerabilities last year. That is, 3 more vulnerabilities have already been reported in 2026 as compared to last year.
| Year | Vulnerabilities | Average Score |
|---|---|---|
| 2026 | 3 | 1.80 |
| 2025 | 0 | 0.00 |
| 2024 | 0 | 0.00 |
| 2023 | 0 | 0.00 |
| 2022 | 0 | 0.00 |
| 2021 | 1 | 0.00 |
| 2020 | 1 | 0.00 |
| 2019 | 1 | 0.00 |
It may take a day or so for new Aspell vulnerabilities to show up in the stats or in the list of recent security vulnerabilities. Additionally vulnerabilities may be tagged under a different product or component name.
Recent GNU Aspell Security Vulnerabilities
GNU Aspell 0.60.8.3 Integer Truncation in WritableDict::add()
CVE-2026-75820
1.8 - Low
- October 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.
Integer Overflow or Wraparound
GNU Aspell OOB read in ReadOnlyDict::load() < v0.60.8.3
CVE-2026-75819
1.8 - Low
- October 06, 2026
GNU Aspell contains an out-of-bounds read vulnerability in ReadOnlyDict::load() in readonly_ws.cpp. When loading a binary .rws dictionary file, it uses offset fields from the file header as byte indices into a heap buffer without validating their bounds. An attacker can trigger this by convincing a user to run aspell with a crafted dictionary file supplied through --master, --dict-dir, or configuration options, leading to heap memory disclosure or a denial of service via application crash. This issue was fixed in commit 941953b25031bc9104e83f58e138a664b8dedc3f which will be released in version 0.60.8.3.
Out-of-bounds Read
CVE-2026-75818: Heap Buffer Overflow in GNU Aspell prezip-bin (before 0.60.8.3)
CVE-2026-75818
1.8 - Low
- October 06, 2026
GNU Aspell prezip-bin contains a heap-based buffer overflow vulnerability in the decompressor in prog/prezip.c. The decompressor does not properly check buffer space, so a crafted compressed file can cause out-of-bounds read and write operations on the heap. An attacker who convinces a user to process a malicious compressed file with prezip-bin can trigger memory corruption, leading to a processs crash. This issue was fixed in commit 15b188437f9e0192d4ac4472ad66a4e2f62a782f which will be released in version 0.60.8.3.
Heap-based Buffer Overflow
objstack in GNU Aspell 0.60.8 has a heap-based buffer overflow in acommon::ObjStack::dup_top (called
CVE-2019-25051
- July 20, 2021
objstack in GNU Aspell 0.60.8 has a heap-based buffer overflow in acommon::ObjStack::dup_top (called from acommon::StringMap::add and acommon::Config::lookup_list).
libaspell.a in GNU Aspell before 0.60.8 has a buffer over-read for a string ending with a single '\0' byte
CVE-2019-20433
- January 27, 2020
libaspell.a in GNU Aspell before 0.60.8 has a buffer over-read for a string ending with a single '\0' byte, if the encoding is set to ucs-2 or ucs-4 outside of the application, as demonstrated by the ASPELL_CONF environment variable.
libaspell.a in GNU Aspell before 0.60.8 has a stack-based buffer over-read in acommon::unescape in common/getdata.cpp
CVE-2019-17544
- October 14, 2019
libaspell.a in GNU Aspell before 0.60.8 has a stack-based buffer over-read in acommon::unescape in common/getdata.cpp via an isolated \ character.
Stay on top of Security Vulnerabilities
Want an email whenever new vulnerabilities are published for GNU Aspell or by GNU? Click the Watch button to subscribe.
