Commit graph

1 commit

Author SHA1 Message Date
4e16ea0e72 fix(llm-security): HIGH — one unparseable JetBrains plugin crashed ide-scan
The two manifest parsers disagree on how they signal failure:
parseVSCodeExtension returns a bare null, parseIntelliJPlugin returns a
TRUTHY { manifest: null, warnings }. scanOneExtension guarded only the
bare-null form, so every JetBrains failure path — lib/ missing, lib/ not
a directory, lib/ unreadable, no jars in lib/, no jar extractable — fell
through the guard and dereferenced `manifest.hasSignature`.

The resulting TypeError propagated out of scanOneExtension into
mapConcurrent, which awaited fn() with no per-item try/catch, so
Promise.all rejected and the ENTIRE ide-scan aborted. One malformed
plugin directory on disk was enough to take down the scan of every
other installed extension — including, in an audit context, a plugin
that is malformed precisely because it is hostile.

- scanOneExtension: guard is now `!parsed || !parsed.manifest`, and the
  parser's own warnings are carried into the result so the reason for
  the skip survives instead of being replaced by a generic message.
- unscannableExtension(): the result envelope is extracted so the early
  return and the isolation belt below produce the same shape.
- Belt (defense-in-depth): the scanOneExtension call site catches per
  extension and yields an unscannable result. mapConcurrent stays
  generic — the isolation lives at the call site, not in the helper.

Regression test drives scanOneExtension across all four JetBrains parse
failure paths plus a no-invented-findings assertion.

npm test: 1884/1884 green (1879 + 5 new).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TcQyMTQfyrsAapaCMPxTtQ
2026-07-18 09:14:12 +02:00