dsh-malware-audit

A DeepSeek Harness (dsh) plugin that scans installed plugins' real syntax trees for patterns shaped like malicious intent — the one thing every other dsh audit tool explicitly declines to do — with an optional periodic schedule and opt-in auto-quarantine on critical findings.

Why

dsh plugins run with real filesystem and process access, and installing one is a one-line command. Existing audit tools (dsh-security-audit, dsh-plugin-audit) do this well for capability — they report that a plugin can touch the filesystem, network, or credentials, then explicitly stop short of judging intent: "an audit aid, not an antivirus."

dsh-malware-audit fills that specific gap: it looks for the handful of techniques that separate "this plugin can do a lot" from "this looks like it's hiding what it does" — dynamic code execution from strings, fetch-and-execute, cross-plugin file writes (the exact technique a real hot-reload plugin in the wild uses to inject code into other installed plugins), and exfiltration-shaped network calls.

Still not an antivirus. There is no signature database of known-bad packages here — this can't tell you a specific npm package was reported compromised. It's a heuristic scanner over a small, fixed rule set. What changed from an earlier version: detection now walks the real TypeScript-compiler AST instead of matching raw text, so a comment, a string literal, or a JSDoc example can no longer trigger a finding — only real syntax can. See Known false positives for what still can.

Install

dsh plugin --profile <name> add dsh-malware-audit

Add the package name to that profile's dsh.profile.bundles list (being a
listed dependency alone doesn't activate a plugin's dsh.bundle patch —
see dsh-minimal-anchor's README
for why):

{
  "dsh": {
    "profile": {
      "bundles": [
        "@deepseek-ai/dsh-base",
        "@deepseek-ai/dsh-web-app",
        "dsh-malware-audit"
      ]
    }
  }
}

Confirm it composed with dsh --profile <name> --dump-config — look for a
malware-audit entry.

Usage

Type /scan-plugins in any session. It scans every other installed
package that declares dsh.bundle in its own package.json — the same
marker the plugin ecosystem's own registries use to mean "this is a dsh
plugin" — across every local profile, prints a findings summary, and saves
the full report to .dsh-malware-audit/scan-<timestamp>.txt under the
current working directory.

By default this is entirely read-only and manual. Two things make it more
active, both opt-in and off unless you configure them:

• scheduleMinutes — runs the same scan automatically on an interval,
  no command needed.
• autoQuarantine — on a scan (scheduled or manual) that finds a
  critical-severity pattern, automatically quarantines that plugin.

Configuration

# profiles/<name>/cordis.patch.yml
- insert:
    - id: malware-audit
      name: 'dsh-malware-audit'
      config:
        maxFiles: 400
        maxFileBytes: 262144
        ignoreRuleIds: []
        ignorePlugins: []
        scheduleMinutes: 0
        autoQuarantine: false

What it checks

Deliberately scoped to .js/.ts source files only (no .md/.json), and
only within each plugin's own directory (skipping its node_modules,
.git, lib, dist, build) — a resource budget caps files scanned
(400) and file size (256 KiB) per plugin. A file that fails to parse is
skipped, not treated as an error — the TypeScript parser is deliberately
error-tolerant and essentially never throws, but a genuinely unparseable
file just contributes no findings rather than crashing the scan.

Quarantine

When autoQuarantine: true and a scan finds a critical-severity pattern,
quarantinePlugin():

1. Moves the plugin's node_modules entry into
   .dsh-malware-audit/quarantine/<name>-<timestamp>/. For a dev-linked
   install (dsh plugin add /local/checkout, a symlink in node_modules),
   this moves the symlink itself — never the real checkout it points to.
   Verified by test: the real target directory and its contents are
   confirmed still present and untouched afterward.
2. Removes the plugin's name from every profile's dsh.profile.bundles
   list that names it, across every local profile. This step is not
   optional — leaving a bundle entry pointing at a now-missing
   node_modules package produces a hard boot failure next time
   (cannot resolve profile bundle), the exact crash this project hit by
   accident earlier in its own development. Quarantining without fixing
   the bundles list would trade "plugin might be malicious" for "profile
   cannot boot at all," which is strictly worse.

What quarantine does not do: stop an already-running instance of the
plugin in the current process. There is no same-process API to dispose
another plugin's live Cordis fiber from here — quarantine takes effect on
the next boot of each affected profile, not immediately. If a scheduled
scan quarantines something mid-session, that plugin keeps running until
the next restart.

To restore a quarantined plugin, move its directory back from
.dsh-malware-audit/quarantine/ into the profile's node_modules under
its original name, and add it back to that profile's dsh.profile.bundles
list. There is no automated restore command yet — this is a manual,
deliberate step.

Given the real disruption a wrong quarantine causes (a plugin stops
loading, possibly one you use every day, on a heuristic finding that is
explicitly not proof of malice), autoQuarantine defaults to false.
Turn it on only once you've run /scan-plugins manually a few times and
trust the signal-to-noise for your actual installed plugins.

Periodic scanning

Set scheduleMinutes above 0 to run the same scan automatically, on the
same interval, for as long as the harness process stays up — via
ctx.interval() from @deepseek-ai/cordis-plugin-timer, which dsh-base
already mounts in every profile. This is a live, in-process timer, not an
OS-level cron job: it resets on every restart and only fires while the
dsh process is running, which is sufficient for dsh web's
long-running server but means nothing runs while the harness itself isn't.

Known false positives

Documented from the test suite, not hidden — the AST rewrite fixed the
worst false positives (comments, strings, JSDoc examples, and a plain
require() no longer trigger anything — all confirmed by test), but a few
real ones remain, all inherent to the rule shapes rather than parsing:

• raw-ip-network fires on well-known infra IPs like AWS's
  169.254.169.254 metadata endpoint or the 169.254.170.2 ECS
  credentials endpoint, which are completely standard in any AWS SDK
  dependency's own source — expected, not a plugin doing anything wrong,
  but still reported since the rule can't tell "well-known infra address"
  from "attacker-controlled address" from a string literal alone.
• env-exfil-shape is a same-call-expression heuristic, not real data
  flow — it only catches process.env referenced directly in a network
  call's own argument list, not const e = process.env; ...; fetch(url, { body: e }) a few lines later. Real dataflow analysis is out of scope
  for this tool; this catches the direct, careless case, not an evasive
  one.
• cross-plugin-write only recognizes a fixed list of write-call
  names (writeFile, writeFileSync, fs.writeFile,
  fs.writeFileSync, fs.promises.writeFile, createWriteStream,
  fs.createWriteStream) — a write performed through a renamed import, a
  wrapper function, or a lower-level fs.open/fs.write file-descriptor
  pair won't match.
• decode-then-execute's variable tracing is a flat, whole-file,
  unscoped map, not real scope analysis — found live, not by review: an
  earlier version only caught eval(Buffer.from(x, 'base64').toString())
  inline and missed the more common const payload = Buffer.from(x, 'base64').toString(); eval(payload) two-statement form entirely, which
  is exactly what a synthetic test plugin used during verification. Fixed
  by building a name -> initializer map across the whole file and
  checking it too, but that means a variable name reused in two unrelated
  functions can collide, and a reassignment after the initial declaration
  isn't tracked.

How it works

Discovery. There is no inventory service usable from inside a plugin
(@deepseek-ai/dsh-host-plugin-inventory is Remote-only, client-side), and
deriving a plugin's own location from import.meta.url doesn't work for a
locally-linked install — a dsh plugin add /local/checkout (pnpm link:)
install makes the profile's node_modules entry a symlink, and Node's
module resolution follows that symlink to its real location before
computing any node_modules-relative path, so there is no vanilla API that
reports the apparent (profile-relative) path the loader used. Confirmed by
direct test against a real dev-linked install before settling on the real
approach: @deepseek-ai/dsh-home-paths' dshHomePath() resolves
$DSH_HOME from explicit config / the $DSH_HOME env var / ~/.dsh —
never from a filesystem walk — so it's unaffected by how this plugin
itself is installed. From there, every profile's node_modules gets
scanned directly (deduped by real path across profiles), filtered to
packages that declare dsh.bundle.

That filter matters as much as the discovery mechanism: a hoisted
node_modules also contains every transitive dependency of every real
plugin. An earlier version of this scanner, verified against a real
multi-plugin profile, reported 30 "findings" across 316 packages — almost
all of them JSDoc comments in zod's and Node's own type declarations
mentioning eval(), not anything an installed plugin actually does. Only
packages declaring dsh.bundle — the same convention the plugin
ecosystem's own registries use — count as a plugin to scan.

Detection. scanText parses each file with ts.createSourceFile and
walks the real AST (ts.forEachChild), matching specific node shapes —
CallExpressions to eval, a NewExpression naming Function, a
CallExpression to a known write function whose first argument is a
string literal containing a sibling node_modules path — rather than
scanning raw text. Comments and unrelated string content are trivia the
parser strips before any node exists, so they structurally cannot trigger
a finding; this is what fixed the JSDoc/comment/string false positives an
earlier regex-based version had, and what let cross-plugin-write
distinguish an actual write call from a plain require() for the first
time.

scanText/scanPluginDir are pure/IO-separated functions covered by unit
tests, including fixtures proving each documented false-positive fix (a
comment containing eval(x), a JSDoc block quoting eval(), a bare
require() of a sibling plugin); findInstalledPluginDirs is tested
against a real temp-directory $DSH_HOME layout; quarantinePlugin is
tested against a real symlinked directory, confirming the real target is
never touched and only the link moves.

Verified against a real local dsh web boot, not just types: installed
alongside another real plugin and a synthetic dsh.bundle-declaring
plugin planted with eval(), a base64-decode-then-execute pattern, and a
child_process.exec call, ran /scan-plugins through a real browser
session with ignoreRuleIds configured, and confirmed via the session log
that exactly the non-ignored findings fired on the synthetic plugin and
zero on the real one.

Development

npm install
npm run typecheck
npm test

scanPluginDir needs no dsh runtime — examples/scan-standalone.ts
scans any directory on disk directly, useful for checking a plugin
checkout before you even install it, or in a CI step for your own plugin:

npx tsx examples/scan-standalone.ts /path/to/some/plugin/checkout

License

MIT