Hi,

The following vulnerabilities were published for aspell.

CVE-2026-75818[0]:
| 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.


CVE-2026-75819[1]:
| 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.


CVE-2026-75820[2]:
| 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.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2026-75818
https://www.cve.org/CVERecord?id=CVE-2026-75818
[1] https://security-tracker.debian.org/tracker/CVE-2026-75819
https://www.cve.org/CVERecord?id=CVE-2026-75819
[2] https://security-tracker.debian.org/tracker/CVE-2026-75820
https://www.cve.org/CVERecord?id=CVE-2026-75820

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

...
...
...

Hi, Salvatore,

Thanks for the info. Sorry for not replying before, I am waiting for a
new upstream release and seems it is taking longer that expected.

Since priority is not RC I prefer to wait for that upstream release. Do you
think an upload to stable-security is convenient?

Regards,

Hi Agustin,

Thanks for replying back! Those issues do not warrant a DSA, so we
marked them 'no-dsa' in the security-tracker already. But once the fix
is landing in unstable, if feasible fixes could be included in an
upcoming point release as well for trixie. But let's see first the
issue get fixed in unstable, and waiting for a new upstream version
seems fine (as long it is happens before forky get released).

Regards,
Salvatore