[abound]

Yeah it would have been nice to end with "and here's a five-line shell script to check if your project is likely affected". But to their credit, they do have an open-source tool [1], I'm just not willing to install a big blob of JavaScript to look for vulns in my other big blobs of JavaScript

[1] https://github.com/AikidoSec/safe-chain

[nine_k]

Something like this should work, assuming your encoding is Unicode (normally UTF-8), which grep would interpret:

  grep -P '[\x{200B}\x{200C}\x{200D}\x{FEFF}]' code.ts

See https://stackoverflow.com/q/78129129/223424

[pwoyke]

The grep approach catches zero-width joiners and BOM characters but misses what GlassWorm uses - variation selectors (U+FE00-FE0F and U+E0100-E01EF). Those don't show up in most regex patterns people reach for, and they're valid Unicode so editors don't flag them either. ESLint won't catch it because variation selectors are legal characters - they're meant for glyph selection in CJK text and emoji. The issue is that GlassWorm uses thousands of them per line where legitimate use is 1-2. It's a density problem, not a character-class problem. We ran into this while analyzing the waves at work and ended up building a scanner around it - counts variation selector clusters per line, matches the decoder pattern (codePointAt + the specific arithmetic GlassWorm uses) in a narrow window to cut false positives from minified code. Open-sourced it last week: https://github.com/afine-com/glassworm-hunter