[finding] dependabot 报默认分支 7 个依赖漏洞(2 high / 4 moderate / 1 low)—— 请分诊定级与归属

[os-zhuang]

推送时 remote 提示(2026-08-06/07 夜间):

GitHub found 7 vulnerabilities on objectstack-ai/objectstack's default branch (2 high, 4 moderate, 1 low)

详情:https://github.com/objectstack-ai/objectstack/security/dependabot

按事实记录,unassigned,交分诊:① 读 dependabot 清单定级(哪 2 个 high、涉及哪些包、是否触达生产面);② 按落点包分车道;③ 若是纯 devDep/传递依赖的低危形态,按仓例批量升级单处理。本单只登记信号来源,不代判严重度。

[os-zhuang]

Triage: duplicate of #6088 — closing. Same 7 advisories, seen through a different reporting channel.

This issue registers the Dependabot banner (7 vulnerabilities: 2 high, 4 moderate, 1 low). #6088, filed 17 minutes earlier at 00:15:59Z from the osv-scanner side (Validate Package Dependencies, run 31132523916), enumerates the full advisory table. The two counts reconcile exactly:

GHSA	CVSS	GitHub severity	package	current	patched
GHSA-5p4m-2wfm-xmqj	7.5	high	js-yaml	3.15.0	3.15.1
GHSA-5p4m-2wfm-xmqj	7.5	high	js-yaml	4.3.0	4.3.1
GHSA-3rrr-jr9j-h3q3	6.5	moderate	mermaid	11.16.0	11.16.1
GHSA-2v8p-3f2j-5mp7	5.3	moderate	mermaid	11.16.0	11.16.1
GHSA-6x64-9x62-f2gx	5.3	moderate	mermaid	11.16.0	11.16.1
GHSA-rhh3-jpg6-66xh	5.3	moderate	mermaid	11.16.0	11.16.1
GHSA-c4c3-pg64-4m4v	2.4	low	mermaid	11.16.0	11.16.1

⇒ 2 high + 4 moderate + 1 low = 7, matching this issue's banner exactly. The severity split is not a coincidence of totals: it is the CVSS→GitHub-severity mapping of #6088's seven rows, row for row.

Independently verified against origin/main (1eb13a0), not taken from #6088's text. The vulnerable versions are all present in the lockfile — js-yaml@3.15.0, js-yaml@4.3.0, mermaid@11.16.0 (js-yaml@4.0.9 / @5.2.2 are also resolved but fall outside the advisory's ranges). Last lockfile commit is 9c90ea0 (feat(sms), #6042) — no OSV remediation has landed, so both reports describe the same live state.

Note the triage seat could not read GET /repos/.../dependabot/alerts directly (403, Resource not accessible by integration), so the reconciliation above is by severity arithmetic + lockfile evidence rather than by pulling the alert list. If someone with Security-tab access finds an eighth alert outside this table, reopen — the arithmetic is exact but it is arithmetic.

Why close rather than cross-link: #6088 is already claimed and in flight (pm:dispatched, session session_01Wbxm29qPKnLf44AbSxizqW, branch claude/issue-6088-osv-jsyaml-mermaid, 00:30:52Z), and its declared file surface is pnpm-lock.yaml. A lockfile fix is the canonical never-parallelize surface — two re-resolutions produce mutually unmergeable diffs (the #5032 precedent). Leaving an unassigned second entry for the same lockfile bump is precisely the shape that invites a second claim, and this issue's own body asks only for grading and routing — work #6088 has already absorbed. One thing, one dispatch entry.

Nothing carried over is lost. This issue's three asks are all answered on #6088: ① the ranked list is its scan table above; ② routing — the lockfile is a shared-infrastructure surface, and the maintainer directed the domain:cli lane to take it (per the claim comment; the triage seat notes the fix touches no domain package, so no domain:* label is warranted on a pure lockfile bump — recorded here rather than relabelling someone else's in-flight issue); ③ the "batch upgrade" shape is what #6088 is dispatched as — all seven have patch-level fixes.

Maintainer may veto this closure by reopening; no restart condition is needed because the surviving issue carries the work.

本评论来自分诊座位 Routine(#5474 试点),不构成认领。 (This comment is from the triage-seat Routine; it is not a claim. Written in English per the language policy that took effect with #6029, merged 23:55:44Z.)

---

Generated by Claude Code