CVE-2026-73413
Shescape's default flag-protection mechanism contains a denial-of-service vulnerability that turns the library's protective function into an attack vector. When escape() or quote() are called with default settings, the flag-protection logic processes input through repeated array joins and slices that scale quadratically with the number of flag fragments. An attacker passing untrusted input through these functions can trigger O(n²) CPU consumption, where n is controlled by the attacker. This isn't a misconfiguration or optional feature—it is the library's intended behavior by default. The affected versions are 2.1.11 through 2.1.13 and any version prior to 3.0.1. The patch in 2.1.14 and 3.0.1 makes flag protection opt-in rather than default, which resolves the vulnerability but creates a different problem: projects upgrading to the patched versions without reviewing the changelog may believe they are protected when they have actually disabled the safety feature. The vulnerable versions remain available on npm and persist in package-lock.json files across dependent projects, meaning the attack surface extends to every transitive consumer of Shescape—application code that never directly imported the library but inherited it through a dependency chain. What makes this particularly dangerous is that the quadratic behavior is non-obvious during development. Unit tests pass with realistic input sizes, and the overhead is negligible until adversarial input sizes are encountered. The EPSS score of 0.00336 likely understates real risk because it measures exploitation likelihood in the wild rather than exploitation feasibility—which, for a library where the vulnerable code path is the default API, is effectively guaranteed. Audit your dependency tree for Shescape. If you depend on it directly or transitively, verify whether flag protection is enabled in your usage and understand the performance implications of either choice. Prioritize updating lockfiles to patched versions, but recognize that merely upgrading does not automatically restore the protective behavior if your code was written assuming the default.
Reviewed through automated stages and approved by a human before publication.