chore(deps): bump the npm_and_yarn group across 1 directory with 2 updates#1894
chore(deps): bump the npm_and_yarn group across 1 directory with 2 updates#1894dependabot[bot] wants to merge 1 commit intomainfrom
Conversation
…dates Bumps the npm_and_yarn group with 2 updates in the / directory: [@hono/node-server](https://github.com/honojs/node-server) and [hono](https://github.com/honojs/hono). Updates `@hono/node-server` from 1.19.11 to 1.19.13 - [Release notes](https://github.com/honojs/node-server/releases) - [Commits](honojs/node-server@v1.19.11...v1.19.13) Updates `hono` from 4.12.9 to 4.12.12 - [Release notes](https://github.com/honojs/hono/releases) - [Commits](honojs/hono@v4.12.9...v4.12.12) --- updated-dependencies: - dependency-name: "@hono/node-server" dependency-version: 1.19.13 dependency-type: direct:production dependency-group: npm_and_yarn - dependency-name: hono dependency-version: 4.12.12 dependency-type: direct:production dependency-group: npm_and_yarn ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
bot
added
dependencies
dependabot
bot
added
dependencies
|
@modelcontextprotocol/client
@modelcontextprotocol/server
@modelcontextprotocol/express
@modelcontextprotocol/fastify
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
@modelcontextprotocol/client
@modelcontextprotocol/server
@modelcontextprotocol/express
@modelcontextprotocol/fastify
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — routine Dependabot security bump; the two inline notes are informational nits (peer-range tightening on alpha packages, and a dev-only transitive copy remaining), neither blocks merge.
Extended reasoning...
Overview
Dependabot security update touching only pnpm-workspace.yaml (two catalog version specifiers) and the regenerated pnpm-lock.yaml. It bumps hono 4.12.9 → 4.12.12 and @hono/node-server 1.19.11 → 1.19.13 to pick up six GHSAs (serve-static slash bypass, SSG path traversal, ip-restriction IPv4-mapped bypass, cookie name validation, etc.). No source, test, or workflow files are touched.
Security risks
The change is itself a security remediation. The SDK does not use hono's serve-static, SSG, cookie helpers, or ip-restriction middleware in its own runtime code, so direct exposure was already minimal, but pulling the patched versions is strictly an improvement. No new attack surface is introduced — this is lockfile + catalog only.
Level of scrutiny
Low. This is a mechanical, semver-patch-level dependency bump generated by Dependabot. The lockfile diff is consistent with the catalog change (new entries added, workspace importers re-pointed). CI building/testing against the new versions is the real gate.
Other factors
The bug-hunter raised two nits, both already posted inline: (1) because the runtimeServerOnly catalog feeds peerDependencies.hono in @modelcontextprotocol/hono / @modelcontextprotocol/node, the next publish will tighten the peer floor from ^4.11.4 to ^4.12.12 — but those packages are 2.0.0-alpha.2 with no stability guarantee, and forcing consumers onto the security-patched hono is arguably the desired outcome; a maintainer can add a changeset if they want it changelogged. (2) A vulnerable copy remains transitively via the dev-only @modelcontextprotocol/conformance test harness, which has no exploitability and can be cleaned up separately with a pnpm.overrides if the security alert doesn't auto-clear. Neither warrants blocking this PR.
| express: ^5.2.1 | ||
| fastify: ^5.2.0 | ||
| hono: ^4.11.4 | ||
| hono: ^4.12.12 |
There was a problem hiding this comment.
🟡 Heads-up: this catalog entry is consumed as peerDependencies.hono in packages/middleware/hono/package.json:47 and packages/middleware/node/package.json:50, so at pnpm publish the next release of @modelcontextprotocol/hono / @modelcontextprotocol/node will ship peerDependencies.hono = "^4.12.12" instead of ^4.11.4 (and @hono/node-server tightens to ^1.19.13). Forcing the security-patched hono is probably desirable, but narrowing a published peer range is a public-contract change — worth a deliberate ack and a changeset rather than a silent Dependabot side-effect.
Extended reasoning...
What this changes beyond the lockfile
The runtimeServerOnly catalog is not only used for this repo's own dev/direct resolution — it is also referenced verbatim in published peerDependencies:
packages/middleware/hono/package.json:47→"hono": "catalog:runtimeServerOnly"underpeerDependenciespackages/middleware/node/package.json:50→"hono": "catalog:runtimeServerOnly"underpeerDependenciespackages/middleware/node/package.json:46→"@hono/node-server": "catalog:runtimeServerOnly"underdependencies
pnpm's documented behavior is that the catalog: protocol (like workspace:) is replaced with the literal specifier from pnpm-workspace.yaml at pnpm pack / pnpm publish time, for all dependency fields including peerDependencies. So this PR doesn't just bump what the monorepo resolves locally — it changes what gets written into the tarballs published to npm.
Step-by-step proof
- Before this PR,
pnpm-workspace.yamlhashono: ^4.11.4inruntimeServerOnly. Runningpnpm packinpackages/middleware/honoproduces apackage.jsonwith"peerDependencies": { "hono": "^4.11.4", ... }. - After this PR, the catalog entry is
hono: ^4.12.12. The samepnpm packnow emits"peerDependencies": { "hono": "^4.12.12", ... }. - A downstream consumer who has
hono@4.11.6(or anything in4.11.4–4.12.11) installed alongside the next published@modelcontextprotocol/honowill now fail the peer check: npm prints an unmet-peer warning, and pnpm withstrict-peer-dependencies/ Yarn PnP hard-fails the install. - The same substitution tightens
@modelcontextprotocol/node's direct dep on@hono/node-serverfrom^1.19.9to^1.19.13— less impactful (it's a direct dep so the package manager can just resolve higher), but still a published-range change.
Why nothing currently catches this
Dependabot bumped the catalog to satisfy the security advisory against the workspace's resolved versions; it has no awareness that this catalog key doubles as a public peer-range contract. The changeset-bot already noted "No Changeset found", so as-is the tightened peer range would land in the next release with no changelog entry.
Impact / severity
Low — both packages are 2.0.0-alpha.2, so semver guarantees are weak, and pushing consumers onto the security-patched hono (4.12.12 fixes GHSA-wmmm-f939-6g9c et al.) is arguably the right outcome anyway. This is flagged as a nit so it's a conscious maintainer decision rather than an accidental side-effect.
Suggested fix
Either (a) accept the narrowing intentionally and add a changeset for @modelcontextprotocol/hono and @modelcontextprotocol/node noting the tightened hono peer range, or (b) keep the catalog floor wide (e.g. leave hono: ^4.11.4) and rely on the lockfile to pin the workspace to 4.12.12, decoupling the published peer contract from the locally resolved version.
| hono@4.12.12: {} | ||
|
|
||
| hono@4.12.9: {} |
There was a problem hiding this comment.
🟡 Heads-up: this bumps the workspace catalog to the patched versions, but hono@4.12.9 and @hono/node-server@1.19.11 remain in the lockfile via the transitive dev path @modelcontextprotocol/conformance@0.1.15 → @modelcontextprotocol/sdk@1.28.0 (see pnpm-lock.yaml ~L5765-5780, L7558). Practical risk is nil (dev-only test harness, doesn't expose serve-static/SSG/cookie/ip-restriction to untrusted input), but the GitHub security advisory may not clear after merge — fully resolving it would need a pnpm.overrides entry or a conformance package bump.
Extended reasoning...
What the issue is. The PR updates the runtimeServerOnly catalog so that all workspace importers now resolve hono@4.12.12 and @hono/node-server@1.19.13. However, the diff only adds the new lockfile entries; it does not remove the old ones. hono@4.12.9 (lockfile lines 3636-3638, 7558) and @hono/node-server@1.19.11(hono@4.12.9) (lines 1657-1660, 5593-5595) are still present and will still be installed into node_modules.
Why they remain. They are pulled in transitively through a published dev dependency that the catalog bump cannot affect:
test/conformance (devDependency)
→ @modelcontextprotocol/conformance@0.1.15
→ @modelcontextprotocol/sdk@1.28.0
→ @hono/node-server@1.19.11(hono@4.12.9)
→ hono@4.12.9
This is visible at pnpm-lock.yaml lines ~5765-5782, where the @modelcontextprotocol/sdk@1.28.0 snapshot still lists '@hono/node-server': 1.19.11(hono@4.12.9) and hono: 4.12.9. Since @modelcontextprotocol/sdk@1.28.0 is a published npm package with its own pinned dependency ranges, bumping the local workspace catalog has no effect on what it resolves.
Step-by-step proof.
- After this PR,
pnpm-workspace.yamlcatalogruntimeServerOnly.hono=^4.12.12→ workspace packages (examples/*,packages/*) resolve to 4.12.12 ✅. test/conformance/package.jsondeclares@modelcontextprotocol/conformanceas a devDependency (not via catalog).- Lockfile snapshot for
@modelcontextprotocol/conformance@0.1.15(line ~5750) depends on@modelcontextprotocol/sdk@1.28.0. - Lockfile snapshot for
@modelcontextprotocol/sdk@1.28.0(lines ~5765-5780) depends onhono: 4.12.9and'@hono/node-server': 1.19.11(hono@4.12.9). - Therefore
pnpm installstill materializesnode_modules/.pnpm/hono@4.12.9andnode_modules/.pnpm/@hono+node-server@1.19.11_hono@4.12.9. - Dependabot/GitHub security scanning reads the lockfile, sees
hono@4.12.9at line 7558, and may keep the GHSA alerts open.
Impact. Effectively none from an exploitability standpoint. The only consumer of the vulnerable copy is the conformance test harness, which runs locally/CI against fixture servers and does not expose hono's serve-static, SSG, cookie helpers, or ip-restriction middleware to untrusted input. The relevant concern is purely hygiene: this PR's stated purpose is to remediate GHSA-92pp-h63x-v22m / GHSA-wmmm-f939-6g9c / GHSA-xf4j-xp2r-rqqx / GHSA-xpcf-pg52-r92g / GHSA-26pp-8wgv-hjvm / GHSA-r5rp-j6wh-rvv4, and the flagged versions will still be present in the lockfile after merge.
How to fully clear it (optional). Either (a) add to package.json:
"pnpm": { "overrides": { "hono": "^4.12.12", "@hono/node-server": "^1.19.13" } }and re-run pnpm install, or (b) publish/bump @modelcontextprotocol/conformance to depend on an SDK version that itself uses the patched hono, or (c) run pnpm update -r hono @hono/node-server to see if pnpm can dedupe the transitive copy within the published range. Any of these can be done in a follow-up — not blocking for this PR.
Bumps the npm_and_yarn group with 2 updates in the / directory: @hono/node-server and hono.
Updates
@hono/node-serverfrom 1.19.11 to 1.19.13Release notes
Sourced from
@hono/node-server's releases.Commits
fd64e651.19.13025c30fMerge commit from fork6cdb5a71.19.1270250f7fix: request draining for early 413 responses (#329)cfc08b3chore: ignore claude setting (#314)Updates
honofrom 4.12.9 to 4.12.12Release notes
Sourced from hono's releases.
... (truncated)
Commits
c37ba264.12.12cc067c8Merge commit from forka586cd7Merge commit from fork48fa223Merge commit from forkb470278Merge commit from fork9aff14bMerge commit from fork2c403c64.12.11f82aba8feat(css): add classNameSlug option to createCssContext (#4834)9f374a54.12.10a8c56a6docs(ip-restriction): add clear JSDoc examples and param types (#4851)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditionsYou can disable automated security fix PRs for this repo from the Security Alerts page.