This CVE exposes a category error rather than a simple missing escape sequence. Shescape's core promise is preventing shell injection, but the library validates inputs against POSIX shell semantics while Zsh—particularly with EXTENDED_GLOB and MAGIC_EQUAL_SUBST enabled—applies transformations AFTER escaping occurs. The ~ character expands to home directories, and extended glob patterns execute regardless of what Shescape's escape functions produce. This isn't a bug in the escaping logic; it's a failure of the threat model to account for context-dependent shell behavior.
If you use Shescape with Zsh as your configured shell, you have likely been operating under a false security assumption. The library returned successfully, the output looked escaped, and yet injection-ready characters reached the shell unchallenged. Update to version 2.1.14 or 3.0.1 immediately. More importantly, audit where Shescape-protected input flows into shell execution paths in your deployment—those boundaries may have been thinner than you assumed.
The deeper problem is architectural. Shescape encodes shell configuration as an ergonomic API choice, but that choice carries security-critical implications that the library never surfaces to developers. Configuring shell: 'zsh' looks like specifying an environment; in reality, it opts you into behavior that invalidates the library's safety guarantee. This pattern—context-dependent escaping that works under tested configurations and fails under others—has appeared in multiple escaping libraries across multiple years. The fix adds Zsh-specific handling, but Bash, Fish, and other shells have their own extension sets. The whack-a-mole dynamic is structural, not incidental.
For security architects: treat shell configuration as an attacker-controlled variable, not a static environmental fact. Any escaping library that promises context-independent safety is making an untenable claim. Validate your runtime shell configuration explicitly, and treat the escape function's output as potentially unsafe unless you've verified it against the exact shell and options in your deployment.