fix: update Hono security patches

[yoominho91]

Summary

• update the Hono catalog entry from 4.12.21 to 4.12.34
• override transitive Hono copies so the MCP SDK cannot retain 4.12.21
• pin @hono/node-server to the patched 1.19.15 release

Security impact

The server currently uses cors() with default options in:

• apps/server/src/routes/public/index.ts
• apps/server/src/routes/v1/index.ts

Hono 4.12.21 reaches the vulnerable default allowHeaders path described in GHSA-8j4g-w8fx-2239, where an unauthenticated preflight request can trigger quadratic header parsing and consume disproportionate CPU.

The lockfile also retained vulnerable Hono and Node adapter copies through @modelcontextprotocol/sdk. The overrides keep all workspace and transitive copies on patched releases.

Verification

• pnpm audit --prod: Hono / @hono/node-server advisories 15 → 0 (2 high, 12 moderate, 1 low removed)
• pnpm install --frozen-lockfile --lockfile-only
• pnpm verify with the repository-pinned Node 24.12.0 and Deno 2.9.4: 39/39 packages passed

The lockfile change is intentional and contains only the Hono resolution and peer snapshot updates required by these overrides.

[vercel]

@irontaek is attempting to deploy a commit to the OpenStatus Team on Vercel.

A member of the Team first needs to authorize it.

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[yoominho91]

CI note: the first run passed the API job, while the server job failed during test cleanup with SQLITE_BUSY: database is locked. I refreshed the branch because external contributors cannot use GitHub's rerun action. On the second run the server job passed, while the API job hit the same SQLITE_BUSY error in unrelated database tests.

All other GitHub checks passed, and the failure moved between unrelated suites without a code change. Could a maintainer rerun the failed Tests workflow? The three Vercel statuses also report Authorization required to deploy, which requires team approval.

[cubic-dev-ai]

All reported issues were addressed across 2 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[yoominho91]

Addressed in 1feeecd: the Hono override now uses hono: "catalog:", so the catalog is the single version source while transitive Hono copies remain pinned. I also tested the suggested $hono form with pnpm 11.2.1, but it fails here because the workspace root has no direct hono dependency. Frozen lockfile install, the targeted Hono audit (0 advisories), and pnpm verify (39/39) all pass with the catalog override.

[thibaultleouay]

@claude review this

[claude]

Claude finished @thibaultleouay's task in 55s —— View job

---

Review

• Gather context (PR description, comments, review history)
• Inspect pnpm-workspace.yaml changes
• Inspect pnpm-lock.yaml changes
• Verify the CORS/GHSA-8j4g-w8fx-2239 claim against actual usage
• Post review feedback

Summary: This is a clean, well-scoped security patch bump. I verified the specific claims made in the PR description rather than taking them at face value:

• ✅ CORS claim checked — cors() is called with default options (no allowHeaders override) in apps/server/src/routes/public/index.ts:9 and apps/server/src/routes/v1/index.ts:30, so the GHSA-8j4g-w8fx-2239 exposure described is accurate.
• ✅ Single source of truth fixed — pnpm-workspace.yaml now sets hono: "catalog:" in the overrides block (per the 1feeecd follow-up), resolving cubic's P3 comment about the catalog/override divergence risk. The lockfile confirms overrides.hono resolves to 4.12.34, matching catalog.hono.
• ✅ Transitive copies verified fixed — walked the pnpm-lock.yaml diff for the @modelcontextprotocol/sdk → @hono/node-server → hono chain; both zod@3.25.76 and zod@4.1.13 peer variants of the SDK now resolve to @hono/node-server@1.19.15(hono@4.12.34), so no stale 4.12.21/1.19.9 copies remain anywhere in the lockfile.
• ✅ No other direct hono deps drift — apps/screenshot-service, apps/server, and apps/workflows all declare "hono": "catalog:" in package.json, so all workspace consumers stay pinned through the catalog + override combo.
• ✅ CI is green — all 5 checks (Tests, Check, DX Check, autofix.ci) currently pass, so the earlier SQLITE_BUSY flakes mentioned in the thread are resolved on the latest commit.
• ℹ️ Note on pnpm-lock.yaml importer entries: the diff shows hono: { specifier: 'catalog:' → specifier: 4.12.34 } for apps/server/apps/workflows/apps/screenshot-service importers even though package.json still says "catalog:". This is expected pnpm behavior — the lockfile snapshot reflects the override-resolved version, not a package.json edit — but worth knowing so it isn't mistaken for drift in a future diff review.

No correctness or security issues found. The changes are minimal and scoped exactly to what the description claims (catalog bump, node-server pin, override for transitive copies).