GHSA-64fm-8hw2-v72w is a medium-severity (CVSS 6.5) CWE-674 vulnerability in katex. A fix is available for katex — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-64fm-8hw2-v72w.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
katexnpmDescription
Impact
KaTeX users who render untrusted mathematical expressions could encounter malicious input using \edef that causes a near-infinite loop, despite setting maxExpand to avoid such loops. This can be used as an availability attack, where e.g. a client rendering another user's KaTeX input will be unable to use the site due to memory overflow, tying up the main thread, or stack overflow.
Patches
Upgrade to KaTeX v0.16.10 to remove this vulnerability.
Workarounds
Forbid inputs containing the substring "\\edef" before passing them to KaTeX.
(There is no easy workaround for the auto-render extension.)
Details
KaTeX supports an option named maxExpand which prevents infinitely recursive macros from consuming all available memory and/or triggering a stack overflow error. However, what counted as an "expansion" is a single macro expanding to any number of tokens. The expand-and-define TeX command \edef can be used to build up an exponential number of tokens using only a linear number of expansions according to this definition, e.g. by repeatedly doubling the previous definition. This has been corrected in KaTeX v0.16.10, where every expanded token in an \edef counts as an expansion.
For more information
If you have any questions or comments about this advisory:
- Open an issue or security advisory in the KaTeX repository
- Email us at [email protected]
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | katex | ≥ 0.12.0&&< 0.16.10 | 0.16.10npm install katex@0.16.10 |
Affected Products
katexkatexDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for katex, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update katex to 0.16.10 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-64fm-8hw2-v72w is resolved across your whole dependency graph.
Workarounds
Constrain what reaches the vulnerable code: limit the size and shape of untrusted input, isolate the affected component in a sandboxed or least-privileged process, and enable the platform's memory-safety mitigations (ASLR, stack protector, hardened allocator) so an out-of-bounds access is more likely to fail closed than to be exploitable.
Frequently Asked Questions
Is GHSA-64fm-8hw2-v72w in your dependencies?
Find it across npm, including transitive dependencies.