GNU Aspell: three CVEs in dictionaries and compressed word lists

On October 6, CERT Polska disclosed three GNU Aspell vulnerabilities: CVE-2026-75818, CVE-2026-75819 and CVE-2026-75820. They affect versions before 0.60.8.3. The notice identifies code fixes and says they will be released in 0.60.8.3; those changes alone do not establish that a corrected package is available in your environment.

Breachroad recommends checking whether Aspell appears in your applications or text-processing workflows, where their dictionaries come from and who owns dependency updates. Do not assume that every application with a spellchecker uses this component.

Three issues with different inputs

CVE-2026-75818 concerns the prezip-bin decompressor. Processing a crafted compressed file can corrupt heap memory and crash the process. The scenario requires persuading a user to process the file.

CVE-2026-75819 affects loading binary .rws dictionaries. Improper offset validation can cause heap memory disclosure or denial of service through an application crash when a crafted dictionary is loaded.

CVE-2026-75820 concerns personal word lists. Truncating a word length stored in a single byte can corrupt the heap and cause denial of service after a crafted list is loaded.

These descriptions come from the CVE records. We do not extend them into a claim of confirmed arbitrary code execution. The shared practical concern is the trust boundary around files supplied to the dictionary component.

Find where the component actually runs

Our proposal for administrators and developers is to inventory application dependencies, container images and tools used for text processing. For each instance, record the owner, package origin, version and update mechanism. A useful inventory connects a component to the team that can change its deployment.

Next, determine whether the process accepts dictionaries, word lists or compressed files from external sources. Material supplied by a user, a contractor or a download site needs a separate assessment from files maintained in your own repository. In our view, that distinction helps determine the order of remediation work.

If a particular application does not use the component, document the finding. If it does, connect it to a specific process and account. A library’s presence on disk does not by itself show whether an application loads it or which inputs can reach it. The assessment should follow the actual processing path rather than stop at a filename.

A fix needs deployment evidence

CERT Polska identifies changes addressing all three issues and the planned release. Before closing the task, obtain confirmation from the application maintainer or package vendor that your build contains the relevant fixes. A vendor may backport them to its own package; retain that vendor’s notice alongside the release identifier in that case.

We also recommend checking the running application or the image actually deployed. An updated dependency directory does not prove that every active process is using the new library. If you are waiting for a package, assign an exception owner, a date for another check and restrictions on incoming files.

Limiting untrusted inputs, isolating processing and minimising permissions are our suggestions for reducing exposure. They do not substitute for a fix or establish that the vulnerability has been removed. Record temporary controls separately from confirmed remediation so that the remaining work stays visible.

A scenario for editorial and IT teams

Imagine an editorial team receiving an “industry dictionary” from an external contributor. In this illustrative scenario, an employee forwards the file to the designated reviewer instead of connecting it to a tool independently. IT determines whether the application uses Aspell, confirms its patch status and then considers the material within an agreed workflow.

This is an organisational example from Breachroad, rather than an incident described by CERT Polska. It illustrates why a filename and a sender’s description cannot replace checking provenance and the receiving application. Our cybersecurity training for organisations can help teams practise these decisions while connecting employee procedures with IT’s responsibility for dependencies and updates.