EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
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.10 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for katex. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-64fm-8hw2-v72w is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-64fm-8hw2-v72w. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-64fm-8hw2-v72w in your dependencies?
O3 detects GHSA-64fm-8hw2-v72w across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.