[dependencies] Resolve remaining pnpm audit advisories and document ignored high GHSAs

[serge-ivo]

Problem

A fresh pnpm audit --json on 2026-08-07 still fails, but the current unignored advisory set is not the same as the older VCQA/audit summary.

Current advisories output contains:

• low esbuild >=0.27.3 <0.28.1 via vitest > vite, packages__browser-runner > tsx, and agents__job-application-assistant > wrangler
• low body-parser >=2.0.0 <2.3.0 via packages__browser-runner > @modelcontextprotocol/sdk > express
• moderate @hono/node-server <2.0.5 via packages__browser-runner > @modelcontextprotocol/sdk
• moderate hono <4.12.34 via agents__job-application-assistant > hono

metadata.vulnerabilities still reports two high vulnerabilities, but those are currently ignored by package.json pnpm.auditConfig.ignoreGhsas:

• GHSA-f88m-g3jw-g9cj (sharp)
• GHSA-qwww-vcr4-c8h2 (react-router)

So this is not simply "fix all high advisories". Dev needs to resolve the remaining unignored advisories and separately make the ignored high-advisory posture explicit.

Acceptance

• pnpm audit --json has no unignored moderate advisories and preferably no unignored low advisories.
• The ignored high GHSAs have a short repo-local rationale covering dependency path, runtime exposure, owner, and recheck/removal condition.
• Any ignored advisory that is actually exploitable in PAGS is removed from ignoreGhsas and fixed/upgraded instead.
• Lockfile changes are intentional and relevant tests/typecheck pass.

[serge-ivo]

Critical reassessment: valid PAGS issue, not VCQA. This is reproduced by direct {
"actions": [],
"advisories": {
"1120680": {
"findings": [
{
"version": "0.27.7",
"paths": [
".>vitest>vite>esbuild"
]
},
{
"version": "0.28.0",
"paths": [
"packages__browser-runner>tsx>esbuild"
]
},
{
"version": "0.27.3",
"paths": [
"agents__job-application-assistant>wrangler>esbuild"
]
}
],
"found_by": null,
"deleted": null,
"references": "- https://github.com/evanw/esbuild/security/advisories/GHSA-g7r4-m6w7-qqqr\n- https://github.com/evanw/esbuild/releases/tag/v0.28.1\n- GHSA-g7r4-m6w7-qqqr",
"created": "2026-06-12T20:08:53.000Z",
"id": 1120680,
"npm_advisory_id": null,
"overview": "### Summary\n\nThe development server contains a path traversal vulnerability on Windows when serving files from servedir.\n\nDue to the use of path.Clean() (which only normalizes forward-slash / separators) instead of a Windows-aware path normalization function, it is possible to craft requests using backslashes (\\) that bypass the intended directory containment logic. An attacker can escape the configured servedir root and access arbitrary files on the filesystem.\nThis issue affects Windows environments only.\n\n### Details\n\nThe request path is sanitized using:\ngo\n// https://github.com/evanw/esbuild/blob/v0.27.3/pkg/api/serve_other.go#L165\nqueryPath := path.Clean(req.URL.Path)[1:]\n\n\n\nHowever:\n- path.Clean() is POSIX-style and only understands / (docs: https://pkg.go.dev/path#Clean)\n- On Windows, \\ is a valid path separator\n- path.Clean() does not treat \\ as a separator\n\nLater, the server constructs the absolute path:\ngo\n// https://github.com/evanw/esbuild/blob/v0.27.3/pkg/api/serve_other.go#L221\nabsPath := h.fs.Join(h.servedir, queryPath)\n\n\nIf queryPath contains sequences such as:\n\n..\\..\\..\\..\\..\\..\\..\\Windows\\system.ini\n\n\npath.Clean() will not normalize them, but the Windows filesystem will interpret \\ as directory separators when resolving absPath.\nBecause the implementation does not verify that the final resolved path remains within servedir, it allows directory traversal outside the intended root directory.\n### Vulnerable Code\n\ngo\n// https://github.com/evanw/esbuild/blob/v0.27.3/pkg/api/serve_other.go#L165\n\tqueryPath := path.Clean(req.URL.Path)[1:]\n\t....\n\t// Check for a file in the \"servedir\" directory\n\tif h.servedir != \"\" && kind != fs.FileEntry {\n\t\tabsPath := h.fs.Join(h.servedir, queryPath)\n\t\tif absDir := h.fs.Dir(absPath); absDir != absPath {\n\t\t\tif entries, err, _ := h.fs.ReadDirectory(absDir); err == nil {\n\t\t\t\tif entry, _ := entries.Get(h.fs.Base(absPath)); entry != nil && entry.Kind(h.fs) == fs.FileEntry {\n\t....\t\t\t\t\n\n\n\n### Steps to reproduce\n\n\nnpm install --save-exact --save-dev esbuild\n\necho \"console.log(1)\" > app.js\n\n.\\node_modules\\.bin\\esbuild --version\n0.27.3\n\n.\\node_modules\\.bin\\esbuild app.js --bundle --outdir=www --servedir=www --watch\n\ncurl -i --path-as-is \"http://localhost:8000/..\\..\\..\\..\\..\\..\\..\\Windows\\system.ini\"\n<content of Windows\\system.ini>\n\n\n\n### Impact\n\n- Arbitrary file read on Windows\n- Exposure of sensitive files",
"reported_by": null,
"title": "esbuild allows arbitrary file read when running the development server on Windows",
"metadata": null,
"cves": [],
"access": "public",
"severity": "low",
"module_name": "esbuild",
"vulnerable_versions": ">=0.27.3 <0.28.1",
"github_advisory_id": "GHSA-g7r4-m6w7-qqqr",
"recommendation": "Upgrade to version 0.28.1 or later",
"patched_versions": ">=0.28.1",
"updated": "2026-06-12T20:08:54.000Z",
"cvss": {
"score": 2.5,
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N"
},
"cwe": [
"CWE-22"
],
"url": "GHSA-g7r4-m6w7-qqqr"
},
"1123976": {
"findings": [
{
"version": "2.2.2",
"paths": [
"packages__browser-runner>@modelcontextprotocol/sdk>express>body-parser"
]
}
],
"found_by": null,
"deleted": null,
"references": "- https://github.com/expressjs/body-parser/security/advisories/GHSA-v422-hmwv-36x6\n- https://nvd.nist.gov/vuln/detail/CVE-2026-12590\n- https://github.com/expressjs/body-parser/pull/698\n- https://github.com/expressjs/body-parser/pull/741\n- expressjs/body-parser@2322e111cc321413ec2b7b76d01be533d3de9d7d\n- expressjs/body-parser@3492672eee593d5c158f239b6e9115498a5dbeac\n- https://cna.openjsf.org/security-advisories.html\n- https://github.com/expressjs/body-parser/releases/tag/1.20.6\n- https://github.com/expressjs/body-parser/releases/tag/v2.3.0\n- GHSA-v422-hmwv-36x6",
"created": "2026-07-20T23:23:26.000Z",
"id": 1123976,
"npm_advisory_id": null,
"overview": "### Impact\n\nWhen body-parser is configured with an invalid limit option value, such as an unparseable string or NaN, bytes.parse() returns null and the request body size check is silently skipped. Applications that rely on limit as their primary safeguard against oversized request bodies will accept arbitrarily large payloads, leading to excessive memory and CPU usage and denial of service.\n\nThis issue affects applications that pass a programmatically computed or user-configurable value to the limit option without validating it first.\n\n### Patches\n\nThis issue is fixed in body-parser@2.3.0 and body-parser@1.20.6 via #698. After the fix, invalid limit values throw a clear error at parser construction time instead of silently disabling enforcement. null and undefined continue to fall back to the default limit (100kb).\n\n### Workarounds\n\nValidate limit before passing it to body-parser. For example, parse the value with bytes.parse() at startup and reject any configuration where it returns null or a non-finite number.\n\n### References\n\n- #698: fix PR\n- bytes.js: limit parser",
"reported_by": null,
"title": "body-parser vulnerable to denial of service when invalid limit value silently disables size enforcement",
"metadata": null,
"cves": [
"CVE-2026-12590"
],
"access": "public",
"severity": "low",
"module_name": "body-parser",
"vulnerable_versions": ">=2.0.0 <2.3.0",
"github_advisory_id": "GHSA-v422-hmwv-36x6",
"recommendation": "Upgrade to version 2.3.0 or later",
"patched_versions": ">=2.3.0",
"updated": "2026-07-20T23:23:28.000Z",
"cvss": {
"score": 3.7,
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L"
},
"cwe": [
"CWE-770"
],
"url": "GHSA-v422-hmwv-36x6"
},
"1124006": {
"findings": [
{
"version": "1.19.14",
"paths": [
"packages__browser-runner>@modelcontextprotocol/sdk>@hono/node-server"
]
}
],
"found_by": null,
"deleted": null,
"references": "- https://github.com/honojs/node-server/security/advisories/GHSA-frvp-7c67-39w9\n- honojs/node-server@cd076e117cfe4cb8d31f9eb11d2e8f38a6cb8faf\n- https://github.com/honojs/node-server/releases/tag/v2.0.5\n- GHSA-frvp-7c67-39w9",
"created": "2026-07-21T18:17:25.000Z",
"id": 1124006,
"npm_advisory_id": null,
"overview": "The same as the hono core Path traversal in serve-static on Windows via encoded backslash (%5C).\n\n### Summary\n\nOn Windows hosts, an encoded backslash (%5C) in the request path decodes to \\, which the Windows path resolver treats as a separator. serve-static then resolves a single URL segment such as admin\\secret.txt into a nested file under the root and serves it, letting an attacker read static files meant to be protected behind prefix-mounted middleware. Directory escape (..) remains blocked.\n\n### Details\n\nThe router splits paths only on /, so /admin%5Csecret.txt is one segment and middleware on /admin/* does not run. The serve-static guard rejects ./.. and consecutive separators but lets a lone \\ through; on Windows the file resolver re-splits it into the protected subtree.\n\nThis affects Windows hosts serving static files via the Node, Bun, or Deno adapters that guard a static subtree with prefix-mounted middleware.\n\n### Impact\n\nAn unauthenticated attacker can read static files under a middleware-guarded prefix on Windows hosts. The read stays within the configured root; escape outside the root is not possible.",
"reported_by": null,
"title": "Node.js Adapter for Hono: Path traversal in serve-static on Windows via encoded backslash (%5C)",
"metadata": null,
"cves": [],
"access": "public",
"severity": "moderate",
"module_name": "@hono/node-server",
"vulnerable_versions": "<2.0.5",
"github_advisory_id": "GHSA-frvp-7c67-39w9",
"recommendation": "Upgrade to version 2.0.5 or later",
"patched_versions": ">=2.0.5",
"updated": "2026-07-21T18:17:25.000Z",
"cvss": {
"score": 5.9,
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N"
},
"cwe": [
"CWE-22"
],
"url": "GHSA-frvp-7c67-39w9"
},
"1130733": {
"findings": [
{
"version": "4.12.33",
"paths": [
"agents__job-application-assistant>hono"
]
}
],
"found_by": null,
"deleted": null,
"references": "- https://github.com/honojs/hono/security/advisories/GHSA-8j4g-w8fx-2239\n- honojs/hono@93fc250d8b4df58ea542cb945171de8013d5e6d5\n- https://github.com/honojs/hono/releases/tag/v4.12.34\n- GHSA-8j4g-w8fx-2239",
"created": "2026-08-03T20:23:30.000Z",
"id": 1130733,
"npm_advisory_id": null,
"overview": "### Summary\n\nThe built-in CORS middleware (hono/cors) parses the attacker-controlled Access-Control-Request-Headers request header during a preflight (OPTIONS) request using a regular expression whose running time is quadratic in the input length. A single request carrying a long run of whitespace can consume seconds of CPU, and repeated requests can render the service unresponsive. This parsing runs under the default configuration.\n\n### Details\n\nOn a CORS preflight, when allowHeaders is not configured - the default - the middleware reflects and parses the Access-Control-Request-Headers value. The parser used a whitespace-tolerant regular expression whose backtracking makes the work grow quadratically (O(n²)) with the length of the value when it contains a long whitespace sequence without a delimiter.\n\nBecause the header value is bounded only by the deployment's maximum HTTP header size, a single preflight can block request processing for a noticeable amount of time; on runtimes that share one execution thread across requests, this stalls concurrent requests as well. No authentication, special origin, or user interaction is required.\n\nThis issue arises for any application using cors() with the default (or an empty) allowHeaders. Applications that set a non-empty allowHeaders do not reach the affected path.\n\n### Impact\n\nAn unauthenticated attacker can send preflight requests that each consume disproportionate CPU relative to their size, degrading or denying service. This is a denial-of-service issue only; it does not expose or modify data.",
"reported_by": null,
"title": "Hono: ReDoS in CORS middleware via Access-Control-Request-Headers",
"metadata": null,
"cves": [
"CVE-2026-69207"
],
"access": "public",
"severity": "moderate",
"module_name": "hono",
"vulnerable_versions": "<4.12.34",
"github_advisory_id": "GHSA-8j4g-w8fx-2239",
"recommendation": "Upgrade to version 4.12.34 or later",
"patched_versions": ">=4.12.34",
"updated": "2026-08-03T20:23:59.000Z",
"cvss": {
"score": 5.3,
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L"
},
"cwe": [
"CWE-1333"
],
"url": "GHSA-8j4g-w8fx-2239"
}
},
"muted": [],
"metadata": {
"vulnerabilities": {
"info": 0,
"low": 4,
"moderate": 2,
"high": 2,
"critical": 0
},
"dependencies": 529,
"devDependencies": 0,
"optionalDependencies": 0,
"totalDependencies": 529
}
}, independent of VCQA heuristics. The issue should stay in PAGS because it requires dependency/lockfile changes or explicit runtime exposure decisions.

[serge-ivo]

Shipped in 790b28f. pnpm audit now reports no unignored advisory at any severity (was: 2 moderate + 2 low unignored).

before:  low 4  moderate 2  high 2 (2 ignored)   → 4 unignored advisories
after:   low 3 (1 ignored)  moderate 0  high 2 (2 ignored)  → 0 unignored, exit 0

Fixed — pnpm install swapped 3 packages

advisory	override	resolved	why it was free
GHSA-8j4g-w8fx-2239	hono → ^4.12.34	4.13.0	ReDoS in hono/cors, reached only when allowHeaders is unset. workers/api/src/index.ts sets allowHeaders: ["Content-Type", "Authorization"] — the advisory names that as the configuration that never reaches the quadratic parser. So PAGS was already outside it; taken anyway because it is a patch bump and the next cors() call site added without allowHeaders would be exposed.
GHSA-frvp-7c67-39w9	@hono/node-server → ^2.0.5	2.1.0	serve-static path traversal on Windows via %5C. Reached only through @modelcontextprotocol/sdk's Node HTTP transports. packages/browser-runner/src/mcp-runtime.ts imports the SDK's client + InMemoryTransport only; workers/mcp runs on Cloudflare Workers, where a Node HTTP adapter cannot execute. Neither serves static files.
GHSA-v422-hmwv-36x6	body-parser → ^2.3.0	2.3.0	Size limit silently disabled by an unparseable limit. Same unreachable path (…sdk > express); nothing here constructs an express app.

Accepted, with the reason recorded

GHSA-g7r4-m6w7-qqqr (esbuild, low) → added to ignoreGhsas. The flaw is in esbuild's dev server (--servedir) and is Windows-only — path.Clean does not treat \ as a separator. Nothing here starts it: vite's dev server is vite's own, and tsx/wrangler use esbuild purely as a bundler API. The deciding factor is the one that already applies to sharp: wrangler pins esbuild at an exact 0.27.3, so a global override would force an untested bundler into the tool that produces every deployed Worker, to fix a server that is never started. A vite>esbuild / tsx>esbuild selective override would leave wrangler's copy behind and change nothing about the reported advisory. Unblocker: wrangler shipping with esbuild >= 0.28.1.

The two pre-existing highs were re-checked and stand: sharp (build-time only, miniflare pins it exactly) and react-router (advisory is RSC-only; both consoles are client-rendered SPAs).

Documentation — SECURITY.md's table now carries severity, dependency path, the reachability argument and the unblocker for all three ignored GHSAs, plus a second table for the five taken as overrides. An ignore list whose entries nobody can re-derive is indistinguishable from one that is wrong. pnpm.auditConfig gained a // note pointing at it, since that is the file someone edits when tempted to add a line.

Lockfile — pnpm-lock.yaml moved in the same commit as package.json; CI installs with --frozen-lockfile, so splitting them breaks every deploy. pnpm install --frozen-lockfile is clean, 4211 tests pass, every workspace typechecks.

Note: no CI run verified this. GitHub Actions is in a declared major outage and dispatched nothing for the push; verified locally instead.