Every CVESearch/Get API key

CVE-2026-121691

Unbounded decompression in the whatstk ZIP loader exhausts memory and disk

6.7 Medium

Improper Handling of Highly Compressed Data (CWE-409) in the ZIP loader of whatstk from 0.7.0 before 0.9.0 allows a party that supplies a chat export to exhaust the memory and the disk of the process that parses it, because _str_from_file() (whatstk/whatsapp/parser.py) calls zip_ref.extractall() with no bound on the size of the members and no check of the compression ratio, then reads the extracted file in full with f.read(). The only guard on the archive counts the extracted files and raises when there is not exactly one, but it runs after extractall() has already written them, so it does not prevent the cost. _clean_text() then passes the whole text through unicodedata.normalize("NFKD", text), which holds a second copy, and the parse builds a list of regular expression matches and a DataFrame over it, so peak memory is a multiple of the decompressed text rather than of the archive. A ZIP is a documented input of WhatsAppChat.from_source() and df_from_whatsapp(), and is the form in which WhatsApp exports a chat on iOS, so the attacker supplies the whole file. This results in a small upload costing hundreds of megabytes of memory and of disk, and in the process being killed where that exceeds what is available.

Attack profile

How easy it is to exploit

Attack vector
Local
Complexity
Low
Privileges needed
None
User interaction
Active

What an attacker can affect

Confidentiality
None
Integrity
None
Availability
High

Exploit likelihood

0.14%Unchanged since Nov 11, 2026
90%50%10%1%

What each source reports

CVE List Score used6.7

Unbounded decompression in the whatstk ZIP loader exhausts memory and disk

Improper Handling of Highly Compressed Data (CWE-409) in the ZIP loader of whatstk from 0.7.0 before 0.9.0 allows a party that supplies a chat export to exhaust the memory and the disk of the process that parses it, because _str_from_file() (whatstk/whatsapp/parser.py) calls zip_ref.extractall() with no bound on the size of the members and no check of the compression ratio, then reads the extracted file in full with f.read(). The only guard on the archive counts the extracted files and raises when there is not exactly one, but it runs after extractall() has already written them, so it does not prevent the cost. _clean_text() then passes the whole text through unicodedata.normalize("NFKD", text), which holds a second copy, and the parse builds a list of regular expression matches and a DataFrame over it, so peak memory is a multiple of the decompressed text rather than of the archive. A ZIP is a documented input of WhatsAppChat.from_source() and df_from_whatsapp(), and is the form in which WhatsApp exports a chat on iOS, so the attacker supplies the whole file. This results in a small upload costing hundreds of megabytes of memory and of disk, and in the process being killed where that exceeds what is available.

Record
CVE-2026-121691
CVSS 4.0
6.7 MediumCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Weakness
CWE-409
Updated
2026-11-10
EUVDEUVD-2026-1213946.7

Improper Handling of Highly Compressed Data (CWE-409) in the ZIP loader of whatstk from 0.7.0 before 0.9.0 allows a party that supplies a chat export to exhaust the memory and the disk of the process that parses it, because _str_from_file() (whatstk/whatsapp/parser.py) calls zip_ref.extractall() with no bound on the size of the members and no check of the compression ratio, then reads the extracted file in full with f.read(). The only guard on the archive counts the extracted files and raises when there is not exactly one, but it runs after extractall() has already written them, so it does not prevent the cost. _clean_text() then passes the whole text through unicodedata.normalize("NFKD", text), which holds a second copy, and the parse builds a list of regular expression matches and a DataFrame over it, so peak memory is a multiple of the decompressed text rather than of the archive. A ZIP is a documented input of WhatsAppChat.from_source() and df_from_whatsapp(), and is the form in which WhatsApp exports a chat on iOS, so the attacker supplies the whole file. This results in a small upload costing hundreds of megabytes of memory and of disk, and in the process being killed where that exceeds what is available.

Record
EUVD-2026-121394
CVSS 4.0
6.7 MediumCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Updated
2026-11-10
GitHub AdvisoriesGHSA-q683-6fhr-jvg26.7

Improper Handling of Highly Compressed Data (CWE-409) in the ZIP loader of whatstk from 0.7.0...

Improper Handling of Highly Compressed Data (CWE-409) in the ZIP loader of whatstk from 0.7.0 before 0.9.0 allows a party that supplies a chat export to exhaust the memory and the disk of the process that parses it, because _str_from_file() (whatstk/whatsapp/parser.py) calls zip_ref.extractall() with no bound on the size of the members and no check of the compression ratio, then reads the extracted file in full with f.read(). The only guard on the archive counts the extracted files and raises when there is not exactly one, but it runs after extractall() has already written them, so it does not prevent the cost. _clean_text() then passes the whole text through unicodedata.normalize("NFKD", text), which holds a second copy, and the parse builds a list of regular expression matches and a DataFrame over it, so peak memory is a multiple of the decompressed text rather than of the archive. A ZIP is a documented input of WhatsAppChat.from_source() and df_from_whatsapp(), and is the form in which WhatsApp exports a chat on iOS, so the attacker supplies the whole file. This results in a small upload costing hundreds of megabytes of memory and of disk, and in the process being killed where that exceeds what is available.

Record
GHSA-q683-6fhr-jvg2
CVSS 4.0
6.7 MediumCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Weakness
CWE-409
Updated
2026-11-10
NVD6.7

Improper Handling of Highly Compressed Data (CWE-409) in the ZIP loader of whatstk from 0.7.0 before 0.9.0 allows a party that supplies a chat export to exhaust the memory and the disk of the process that parses it, because _str_from_file() (whatstk/whatsapp/parser.py) calls zip_ref.extractall() with no bound on the size of the members and no check of the compression ratio, then reads the extracted file in full with f.read(). The only guard on the archive counts the extracted files and raises when there is not exactly one, but it runs after extractall() has already written them, so it does not prevent the cost. _clean_text() then passes the whole text through unicodedata.normalize("NFKD", text), which holds a second copy, and the parse builds a list of regular expression matches and a DataFrame over it, so peak memory is a multiple of the decompressed text rather than of the archive. A ZIP is a documented input of WhatsAppChat.from_source() and df_from_whatsapp(), and is the form in which WhatsApp exports a chat on iOS, so the attacker supplies the whole file. This results in a small upload costing hundreds of megabytes of memory and of disk, and in the process being killed where that exceeds what is available.

Record
CVE-2026-121691
CVSS 4.0
6.7 MediumCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Weakness
CWE-409
Updated
2026-11-10
OSV6.7

Unbounded decompression in the whatstk ZIP loader exhausts memory and disk

Improper Handling of Highly Compressed Data (CWE-409) in the ZIP loader of whatstk from 0.7.0 before 0.9.0 allows a party that supplies a chat export to exhaust the memory and the disk of the process that parses it, because _str_from_file() (whatstk/whatsapp/parser.py) calls zip_ref.extractall() with no bound on the size of the members and no check of the compression ratio, then reads the extracted file in full with f.read(). The only guard on the archive counts the extracted files and raises when there is not exactly one, but it runs after extractall() has already written them, so it does not prevent the cost. _clean_text() then passes the whole text through unicodedata.normalize("NFKD", text), which holds a second copy, and the parse builds a list of regular expression matches and a DataFrame over it, so peak memory is a multiple of the decompressed text rather than of the archive. A ZIP is a documented input of WhatsAppChat.from_source() and df_from_whatsapp(), and is the form in which WhatsApp exports a chat on iOS, so the attacker supplies the whole file. This results in a small upload costing hundreds of megabytes of memory and of disk, and in the process being killed where that exceeds what is available.

Record
CVE-2026-121691
CVSS 4.0
6.7 MediumCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Weakness
CWE-409
Updated
2026-11-12

Affected products

History

History
RecordedChangedSources
referencesOSV
referencesOSV
publishedEUVD, NVD
publishedEUVD
aliases, referencesGitHub Advisories
cwes, references, severity, titleCVE List
first indexedEUVD

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2026-121691 is a medium vulnerability (CVSS 6.7) in Lucasrodes Whatstk, published November 10, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.14%, the 3rd percentile. No source names a fixed version.

References

MoveEnter Open