Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft malicious .rws dictionary with oversized length field
-
DeliveryInduce victim to load file via aspell
-
ExploitSigned int overflow skips buffer growth
-
ExecutionAttacker data written past heap allocation
-
ImpactHeap corruption causing DoS or code execution
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Heap buffer bounds checking
MITRE ATT&CK
1 technique across 1 tactic: Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the victim to load an attacker-supplied read-only dictionary (.rws) file whose header contains a valid endian marker (12345678) and an oversized 32-bit size field (e.g. lang_name_size = 0x7FFFFFFF) that drives the signed-int overflow in String::reserve(). The attacker must first get this crafted file to the victim and the victim must invoke Aspell on it - for example via 'aspell dump master <file>' - so there is no remote or network-service trigger. Limiting factors: local delivery of the file, required victim action to load the untrusted dictionary, and affected versions at or below 0.60.8.2 (fixed in 0.60.8.3); code execution is only 'potential' while denial of service is the reliable impact. |
| Impact | This is a moderate, not high, real-world priority. The input CVSS base score is 5.9 (CVSS:3.1/AV:L/AC:L/PR:N/UI:N) with low confidentiality, integrity, and availability impact, reflecting a local, file-borne heap-overflow rather than a remotely reachable flaw. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no public exploit identified at time of analysis and no evidence of active or widespread exploitation. The most important signal conflict is within the CVSS vector itself: it is marked AV:L with UI:N, yet the description explicitly states exploitation requires inducing a victim to load a malicious .rws dictionary (e.g. via 'aspell dump master <file>') - that is user interaction, so UI:N understates the limiting factor and likely inflates the perceived likelihood. The 'potentially code execution' language supports the RCE tag but is speculative; the confirmed, reliable outcome is heap corruption leading to denial of service. Net: a legitimate memory-safety bug worth patching promptly where Aspell processes untrusted dictionaries, but not an emergency given the local vector, required victim action, and absence of any exploitation evidence. |
| Exploit ScenarioDerived | An attacker crafts a malicious read-only dictionary (.rws) file with a valid endian marker (12345678) and an oversized 32-bit length field such as lang_name_size = 0x7FFFFFFF, then tricks a victim into loading it (for example via 'aspell dump master <file>'). Because String::reserve() computes its capacity check as a signed int, the value wraps negative, the backing buffer is never grown, and attacker-controlled data is written past an undersized heap allocation, corrupting memory. No public exploit code was identified at time of analysis; the reliable outcome is a crash/denial of service with potential for code execution. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 12, 2026
Loading an attacker-supplied read-only dictionary (.rws) file in GNU Aspell through 0.60.8.2 can corrupt heap memory, yielding reliable denial of service and potentially code execution. The root cause is a heap-based buffer overflow write (CWE-122) triggered by a signed-integer overflow in String::reserve(), which lets a crafted 32-bit length field in the .rws header (for example lang_name_size = 0x7FFFFFFF, paired with the valid endian marker 12345678) bypass the capacity check so attacker-controlled data is written past an undersized allocation. Exploitation is local in nature - there is no network-service trigger - and requires the victim to actively load the malicious dictionary, such as by running 'aspell dump master <file>'; no public exploit code was identified and there is no confirmed active exploitation at time of analysis, so this is assessed as a moderate-priority issue despite the RCE tag.
RemediationAI
Upgrade to GNU Aspell 0.60.8.3, the vendor-released fixed version (advisory: https://github.com/GNUAspell/aspell/security/advisories/GHSA-p35p-2mw5-fj5j); because distributions often ship Aspell as a library dependency of editors, mail clients, and CI tooling, inventory those consumers and update the shared libaspell package rather than only the CLI. Where immediate upgrade is not possible, apply these compensating controls: never run Aspell (or any embedding application's dictionary-loading path) against .rws files received from untrusted sources, since the attack requires the victim to supply the file and explicitly invoke loading such as 'aspell dump master <file>'; restrict dictionary installation to an administrative or package-managed directory and treat user-supplied dictionary directories as untrusted input, accepting that this breaks legitimate user-installed dictionaries; and run Aspell-based processing as an unprivileged, sandboxed user or in a confined container so a successful heap corruption is contained to a low-privilege process, with the trade-off of potential functional breakage for workflows needing system dictionary paths. Local delivery of the malicious file, required victim interaction, and dependence on heap layout all limit practical exploitability, so patching on a normal maintenance cadence is a proportionate response.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
GNU Aspell is the spell-checking library and command-line tool used both standalone and as a backend by many editors and applications. Its read-only dictionary loader in modules/speller/default/readonly_ws.cpp (ReadOnlyDict::load()) parses the header of compiled .rws dictionary files, reading 32-bit size fields such as lang_name_size directly from disk without validating them against available file length or sane bounds. These sizes are then passed into the backing-buffer growth routine String::reserve() in common/string.hpp, which performs its capacity comparison using a signed int ((int)s + 1). A requested size of 0x7FFFFFFF causes that arithmetic to wrap to a negative value, so the check concludes the buffer is already large enough and never reallocates; the subsequent write of header-controlled data then lands out of bounds past an undersized heap allocation. This is the classic CWE-122 heap-based buffer overflow write pattern: an integer truncation/sign error in a size computation used to gate memory allocation. Successful corruption is heap-layout dependent, which is why denial of service from the out-of-bounds write is the dependable outcome while code execution is only a potential consequence; the affected CPE scope is the entire GNU Aspell 0.60.8.2-and-earlier release line, fixed in 0.60.8.3.
Know when Aspell gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
File-borne local vector (AV:L) requiring the victim to load an attacker-supplied dictionary (UI:R), no privileges needed (PR:N); low C/I/A reflecting heap corruption with only potential code execution.
Primary rating from Vendor (Anthropic).
CVSS VectorVendor: Anthropic
Lifecycle Timeline
1DescriptionCVE.org
GNU Aspell through 0.60.8.2 contains a heap-based buffer overflow write (CWE-122) in its read-only dictionary loader. String::reserve() in common/string.hpp computes its capacity check with a signed int ((int)s + 1), so a requested size of 0x7FFFFFFF wraps negative and the backing buffer is never grown. ReadOnlyDict::load() in modules/speller/default/readonly_ws.cpp passes the unvalidated 32-bit size fields from a .rws dictionary header into this path, so a crafted .rws file with a valid endian marker (12345678) and an oversized length field (e.g. lang_name_size = 0x7FFFFFFF) causes attacker-controlled data to be written out of bounds past an undersized heap allocation. An attacker who induces a victim to load a malicious dictionary - for example via aspell dump master <file> - can corrupt heap memory, resulting in denial of service and potentially code execution. Fixed in 0.60.8.3.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
A heap overflow occurs when a program writes data beyond the bounds of a buffer allocated in the heap memory region.
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
libaspell.a in GNU Aspell before 0.60.8 has a stack-based buffer over-read in acommon::unescape in common/getdata.cpp vi
Heap corruption in GNU Aspell's personal-wordlist handling lets a local attacker crash a user's spell-checking session b
Heap out-of-bounds read in GNU Aspell's binary dictionary loader (ReadOnlyDict::load() in readonly_ws.cpp) lets a crafte
GNU Aspell's prezip-bin decompressor suffers a heap-based buffer overflow (CWE-122) that lets a crafted prezip-compresse
EUVD-2026-97965
NVD
CVE.org
EPSS
GitHub
Exploit-DB