EUVD-2026-116196
GHSA-g94x-jrvx-m3cv
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft chat export with '+' date separator
-
DeliveryDeliver file to victim parsing service
-
ExploitAuto-header detection builds unescaped backtracking regex
-
ExecutionRegex engine exhausts CPU on a few-hundred-byte input
-
ImpactParsing process hangs, denial of service
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V2 - Validation and Business Logic Regex complexity limits
MITRE ATT&CK
1 technique across 1 tactic: Impact 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 parse an attacker-supplied WhatsApp chat export using whatstk versions 0.2.0 up to (not including) 0.9.0 with header auto-detection active, which is the default - no explicit hformat, authentication, or non-default configuration is needed because the malicious date separator is taken from the file itself. The concrete prerequisite is a header whose date separator is a regex metacharacter (e.g. '+' for the catastrophic-backtracking hang, or *, |, ?, ^, $, (, ), \ for an uncaught exception). Limiting factors: the attacker cannot act without a victim process actually ingesting the file (UI:A), and impact is confined to availability (CPU exhaustion or process crash) with no code execution or data exposure. Updating to v0.9.0 is the fix. |
| Impact | This is a medium-severity availability-only flaw (CWE-1333 ReDoS), not a critical priority. The supplied CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:A, VA:H, VC:N/VI:N) scores 6.7 and correctly reflects a denial-of-service with no confidentiality or integrity impact: an attacker needs no privileges but relies on a victim actively feeding the malicious chat export to the parser (UI:A). The vuln.today decision label is 'this_month', consistent with a real-but-non-urgent issue rather than act_now/emergency. No EPSS score and no KEV entry are provided, and exploitation status is 'no public exploit identified at time of analysis' (the references are a vendor/advisory and fix commit, not confirmed working exploit code). The one notable amplifier is that header auto-detection is enabled by default and the dangerous separator is read from the attacker's file, so no special caller configuration is required - any application that parses untrusted WhatsApp exports with whatstk <0.9.0 is exposed. Net: a genuine DoS worth patching for anyone parsing untrusted exports, but bounded to CPU exhaustion / process crash, not a widespread or remotely-wormable threat. |
| Exploit ScenarioDerived | An attacker crafts a WhatsApp chat export of only a few hundred bytes whose date-field separator is a regex metacharacter such as '+'. When a victim application parses it with whatstk's default auto-header detection, generate_regex() leaves the separator unescaped, producing a catastrophic-backtracking pattern that pins the CPU indefinitely (or, with separators like *, |, ?, ^, $, (, ), \, throws an uncaught exception that crashes the caller). No published PoC is referenced, though the NVD description supplies a complete reproduction recipe. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Nov 03, 2026
Inefficient regular expression complexity (ReDoS) in whatstk 0.2.0 through 0.8.x lets anyone who supplies a WhatsApp chat export burn CPU indefinitely in the process that parses it. The library's generate_regex() builds the header pattern by substituting named capture groups into the header format but leaves all other characters unescaped, so an export whose date separator is a regex metacharacter - for example '+' - turns the pattern into a nested-quantifier form such as (?P<day>\d{1,2})+(?P<month>\d{1,2})+(?P<year>\d{2,4}) that backtracks catastrophically on a digit run that cannot complete the header. Header auto-detection is on by default and derives the format from the file's own text, so no caller-supplied hformat is needed; separators of (, ) or \ instead raise re.PatternError, *, | or ? raise TypeError, and ^ or $ raise KeyError, none of which the library catches. The result is a hang or uncaught exception from a file of a few hundred bytes. There is no confirmed active exploitation or CISA KEV listing, and no public working exploit code is documented in the available sources; a public PoC reference appears only as a CNA write-up. whatstk v0.9.0 contains the fix.
RemediationAI
Upgrade whatstk to v0.9.0, the vendor-released fix (https://github.com/lucasrodes/whatstk/releases/tag/v0.9.0; commit 01d66d8, PR #181), which stops unescaped header-format characters from being interpreted as regex syntax. If upgrading is not immediately possible, the exploitable path is the default auto-detection: passing an explicit, trusted hformat to df_from_whatsapp rather than letting extract_header_from_text derive the format from the file removes the attacker's control over the separator, at the cost of requiring a correct format per export and failing on layout changes; likewise, running production parses with auto-detection enabled only on files from trusted sources, and parsing untrusted exports in a separate low-privilege worker with a hard CPU timeout and exception handling around the parse call, limits the damage of both the backtracking hang and the uncaught PatternError/TypeError/KeyError raised by separators of (, ), \, *, |, ?, ^ and $ (this is a containment measure, not a fix, and a timeout only aborts the parse after the CPU has already been spent). Because exploitation requires a victim process to ingest the crafted export, restricting who can submit chat exports for parsing is itself a meaningful control. The upstream advisory URL above should be tracked for any further patch revisions.
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
whatstk parses exported WhatsApp chat text into pandas DataFrames. Its pipeline is _str_from_file -> _clean_text (NFKD normalisation plus stripping of invisible characters such as U+202F, LRM/RLM and ZWJ) -> extract_header_from_text in whatsapp/auto_header.py -> generate_regex in whatsapp/parser.py -> _parse_chat -> _remove_alerts_from_df. generate_regex() converts a header format string such as '%d/%m/%y, %H:%M - %name:' into a compiled regex by replacing each %x code with a named capture group while copying every other character verbatim into the pattern. Because those literal characters are never run through re.escape(), a header whose date separator is a regex metacharacter does not match itself but instead changes the pattern's meaning: '+' quantifies the preceding capture group, producing nested quantifiers over adjacent digit groups, the classic CWE-1333 shape that makes the regex engine explore every partition of a long digit run before failing. The parser relies on re.search/finditer over the whole file, so the backtracking cost is paid per candidate position. Other metacharacters fail earlier and noisily: '(' , ')' and '\' produce unbalanced or invalid patterns and raise re.PatternError; '*' , '|' and '?' raise TypeError during compilation; '^' and '$' produce a KeyError, presumably in the capture-group name lookups used by _parse_line. None of these exceptions are caught by the library, so they propagate into the calling application. The root cause class is CWE-1333 (inefficient regular expression complexity), and the correct fix is to escape literal format characters (and/or validate the detected separator) before composing the pattern; the upstream commit 01d66d8 and PR #181 accompany release v0.9.0. Note that the auto_header layer also contains unrelated known weaknesses (day/month swap on chats that never reach day 28, issue #175) which are not part of this CVE.
Know when the next one hits your stack
- 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
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Attacker-supplied file parsed by victim process gives AV:L and UI:R, no privileges needed (PR:N); impact is CPU-exhaustion/crash only, so A:H with C:N/I:N.
Primary rating from Vendor (4daa8cea-433a-44bd-9456-53b127fc289a).
CVSS VectorVendor: 4daa8cea-433a-44bd-9456-53b127fc289a
Lifecycle Timeline
1DescriptionCVE.org
Inefficient Regular Expression Complexity (CWE-1333) in generate_regex() (whatstk/whatsapp/parser.py) in whatstk from 0.2.0 before 0.9.0 allows a party that supplies a chat export to consume the CPU of the process that parses it for an unbounded time, because the function builds the header regular expression by replacing each %x code with its named capture group and leaves every other character of the header format in the pattern unescaped. A header whose date separator is a regular expression metacharacter therefore alters the pattern instead of matching itself: a separator of + quantifies the preceding capture group, giving (?P<day>\d{1,2})+(?P<month>\d{1,2})+(?P<year>\d{2,4}), and a run of digits that cannot complete the header then makes the engine try every way of partitioning that run. Header auto detection is enabled by default and derives the format from the text of the file, so the separator is taken from the export itself and no header format has to be passed by the caller. Separators of (, ) and \ instead raise re.PatternError, separators of *, | and ? raise TypeError, and separators of ^ and $ raise KeyError, none of which the library catches. This results in the parse of a file of a few hundred bytes consuming CPU without completing, or in an uncaught exception in the calling program.
Threat Intelligence Overview
NVD
CVE.org
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
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Exploit-DB