[Security] Exact-pinned vulnerable deps in 0.2.1-rc.2 / rc.3 / master: undici 8.11.2, zod 4.4.3, @modelcontextprotocol/client 2.2.0, fflate 0.8.2

[vejeta]

Fresh installs of @deepseek-ai/dsh currently resolve four dependencies with published GitHub advisories. They are exact pins inside @deepseek-ai/* packages, so downstream users cannot pick up the fixes through semver; only a new release can. This affects latest (0.2.1-rc.2), next (0.2.1-rc.3) and master (22ddee3).

Dependency	Pinned version	Pinned in	Advisories	Fixed in
undici	8.11.2	packages/util/http-proxy, packages/web/web-fetch-http	GHSA-xjj6-f33q-929c (High), GHSA-4qv8-2p9j-2685, GHSA-f72v-6w45-q472	8.12.2 (2026-10-15)
zod	4.4.3	~50 @deepseek-ai/dsh-* packages (e.g. packages/mcp/mcp-client, dsh-agent-loop, dsh-api-*-controller)	GHSA-mrhx-c7xc-m3w5 (High)	4.6.6 (2026-10-11)
@modelcontextprotocol/client	2.2.0	packages/mcp/mcp-client	GHSA-6prh-2h8m-c8cw (Moderate)	2.3.0 (2026-10-02)
fflate	0.8.2	@deepseek-ai/libreoffice-kit (still pinned in 0.2.3-rc.3)	GHSA-px8p-9vwx-vf98 (Moderate)	0.8.3 (2026-05-16)

npm audit on a fresh install reports 196 affected packages (189 high), almost all of them through the zod pin. Supply-chain gates such as Datadog's Supply-Chain Firewall block the install outright, which is how I ran into this.

Reproduce

mkdir dsh-audit && cd dsh-audit && npm init -y
npm install --package-lock-only --ignore-scripts @deepseek-ai/dsh@0.2.1-rc.2
npm audit

An OSV batch query over the full resolved tree (628 packages) returns only these four packages, and no MAL- advisories.

Requests

1. Bump the pins to undici@8.12.2, zod@^4.6.6, @modelcontextprotocol/client@2.3.0 and fflate@0.8.3 (in libreoffice-kit), then publish a new release.
2. The 30-day Dependabot cooldown in .github/dependabot.yml delays these bumps until mid-November. Please consider enabling Dependabot security updates, or exempting security fixes from the cooldown.
3. Please consider publishing with npm provenance (npm publish --provenance). Right now there is no attestation linking the @deepseek-ai packages to this repository, so users can't verify them against typosquats.

Until a fixed release ships, users can work around this with overrides in their own package.json. That is fragile, though: every update of dsh brings the pinned tree back.

[GreenLv]

补充一下 DSH 0.2.2-alpha.3 的情况。@vejeta 此前报告了多个 DSH 包精确锁定 zod@4.4.3 的问题。我查了 alpha.3 在 npm 上发布的包清单，下面六个官方包的 dependencies 里仍然是 "zod": "4.4.3"。

• @deepseek-ai/dsh-commands
• @deepseek-ai/dsh-llm
• @deepseek-ai/dsh-sandbox-policy
• @deepseek-ai/dsh-session-projection
• @deepseek-ai/dsh-session-title
• @deepseek-ai/dsh-tool-todo

这些精确锁定的依赖在常规安装时仍会解析到 4.4.3。请问后续版本能否把它们更新到 4.6.6 或更高版本？ 安全公告 GHSA-mrhx-c7xc-m3w5

[vejeta]

Thanks @GreenLv for checking alpha.3.

I resolved the full tree of @deepseek-ai/dsh@0.2.2-alpha.3. The problem is bigger than those six packages. 57 @deepseek-ai/dsh-* packages still pin "zod": "4.4.3" exactly, for example dsh-agent, dsh-agent-loop, dsh-api-session-controller and dsh-workspace. The other three pins from the original report are also unchanged in alpha.3:

Dependency	Still pinned in 0.2.2-alpha.3	Fixed in
zod 4.4.3	57 dsh-* packages	4.6.6
undici 8.11.2	dsh-http-proxy, dsh-web-fetch-http	8.12.2
@modelcontextprotocol/client 2.2.0	dsh-mcp-client	2.3.0
fflate 0.8.2	libreoffice-kit	0.8.3

To check:

npm install --package-lock-only --ignore-scripts @deepseek-ai/dsh@0.2.2-alpha.3
npm audit

So every published line (latest, next and alpha) is still affected. A bump in the workspace catalog/root, or a repo-wide replace of the exact pins with ^4.6.6, would fix all of them in one release. That way we don't have to chase them package by package.

---

中文摘要

感谢 @GreenLv 检查 alpha.3。我解析了 @deepseek-ai/dsh@0.2.2-alpha.3 的完整依赖树，问题比这六个包更大：

• 57 个 @deepseek-ai/dsh-* 包仍然精确锁定 "zod": "4.4.3"（例如 dsh-agent、dsh-agent-loop、dsh-api-session-controller、dsh-workspace），需要升级到 4.6.6 或更高版本。
• 原报告中的另外三个依赖在 alpha.3 中也没有变化：undici@8.11.2（应为 8.12.2）、@modelcontextprotocol/client@2.2.0（应为 2.3.0）、fflate@0.8.2（应为 0.8.3）。

也就是说，latest、next 和 alpha 三个发布线目前都受影响。建议在 workspace 的 catalog 或根配置中统一升级，或者在整个仓库中把精确版本改为 ^4.6.6，这样一次发布就能全部修复，不用逐个包处理。

[vejeta]

One more small request, related to point 3 of the original report.

The repository has no private vulnerability reporting (the GitHub setting is off) and no SECURITY.md, neither here nor at the deepseek-ai org level. This report was fine to post in public, because all four advisories were already public. But if someone finds a real vulnerability in DSH itself, they have no private way to tell you.

Could you consider one of these:

1. Turn on Private vulnerability reporting (Settings → Code security → Private vulnerability reporting). After that, reporters can open a private advisory from the Security tab.
2. Add a SECURITY.md with a contact address and the versions you support.

Both are small changes and need no code.

---

中文摘要

补充一个小请求：本仓库目前没有开启 GitHub 的私密漏洞报告功能，也没有 SECURITY.md（仓库和 deepseek-ai 组织层面都没有）。这次报告涉及的公告都已公开，所以公开讨论没有问题；但如果以后有人发现 DSH 本身的漏洞，就没有私密的报告渠道。建议：

1. 开启 Private vulnerability reporting（Settings → Code security → Private vulnerability reporting）；或
2. 添加 SECURITY.md，写明联系方式和受支持的版本。

两者都不需要改代码。