SRE-951: bump apps/hash-api nanoid pin to 3.3.18 [SECURITY]

[claude]

Requested by Tim Diekmann · Slack thread

🌟 What is the purpose of this PR?

Finishes clearing GHSA-2v37-7h3g-55p8 (high) in apps/hash-api.

Before: apps/hash-api pinned nanoid to the exact version 3.3.17. npm's advisory range for GHSA-2v37-7h3g-55p8 is <3.3.18, so 3.3.17 is still affected — customAlphabet/customRandom loop forever when handed a size of 0. Because the pin is exact, yarn.lock carried a separate nanoid@npm:3.3.17 entry that no range resolution could move, even though the rest of the tree had already gone to 3.3.18.

After: the pin is 3.3.18. The standalone nanoid@npm:3.3.17 lockfile entry is gone, and the exact spec now shares the existing 3.3.18 resolution. Every nanoid version still resolved in the tree (3.3.18 and 5.1.16) is outside the affected range.

The earlier bump (#9182, 3.3.11 → 3.3.17) landed short of the fixed release: it stopped the old version matching the scanner without actually clearing the advisory.

Advisory closed

Advisory	Severity	Affected range	Was	Now
GHSA-2v37-7h3g-55p8	High	<3.3.18	3.3.17	3.3.18

Verified against npm's bulk advisory endpoint (registry.npmjs.org/-/npm/v1/security/advisories/bulk) per resolved version, not just by the old version disappearing:

• before — nanoid 3.3.17 → GHSA-2v37-7h3g-55p8, range <3.3.18, high
• after — nanoid 3.3.18 → no advisories; nanoid 5.1.16 → no advisories

nanoid 3.3.18 was published 2026-08-07 and is ~9 days old, so it clears the repo's npmMinimalAgeGate: 7d with no age-gate override needed.

🔗 Related links

• SRE-951 (internal)
• Supersedes Update npm package nanoid to v3.3.18 [SECURITY] #9221, which changed only apps/hash-api/package.json; Renovate could not regenerate yarn.lock (its runner has Yarn 1.22.22 against this repo's packageManager: yarn@4.16.0), so the bump never reached the resolved tree.

🚫 Blocked by

• nothing

🔍 What does this change?

• Bumps the exact nanoid pin in apps/hash-api/package.json from 3.3.17 to 3.3.18.
• Regenerates yarn.lock with Yarn 4 (--mode=update-lockfile), removing the nanoid@npm:3.3.17 entry.

Two files, three insertions, twelve deletions — the lockfile change is a removal, not just an addition.

Pre-Merge Checklist 🚀

🚢 Has this modified a publishable library?

This PR:

• does not modify any publishable blocks or libraries, or modifications do not need publishing

📜 Does this require a change to the docs?

The changes in this PR:

• are internal and do not require a docs change

🕸️ Does this require a change to the Turbo Graph?

The changes in this PR:

• do not affect the execution graph

⚠️ Known issues

None. nanoid 3.3.18 is a single patch release on the same line; its only change is the infinite-loop fix.

🐾 Next steps

Two other hash findings from the 2026-08-17 scan are not addressed here:

• esbuild 0.27.7 (GHSA-g7r4-m6w7-qqqr, low, Windows dev-server only). A fix now exists — 0.28.1 and 0.28.2 are published, correcting an earlier report that there was none. It is still not reachable by a parent bump alone: tsup is the blocker, with 8.5.1 the latest release and still capped at esbuild: ^0.27.0. Details in the scan thread.
• extract-zip 2.0.1 (GHSA-jmr9-qjv8-65gv, high). Needs puppeteer-core 22.15.0 → 25.x in apps/hash-ai-worker-ts; worth its own scoped ticket.

🛡 What tests cover this?

No new tests — a dependency version bump with no API change. Existing CI covers apps/hash-api build and tests.

❓ How to test this?

1. Check out the branch.
2. grep -A2 'nanoid@npm' yarn.lock and confirm no 3.3.17 resolution remains.
3. Confirm apps/hash-api/package.json pins 3.3.18.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
hash	Ready	Preview	Aug 17, 2026 9:04am

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
hashdotdesign-tokens	Ignored		Aug 17, 2026 9:04am
petrinaut	Skipped		Aug 17, 2026 9:04am

[cursor]

PR Summary

^{Cursor Bugbot is generating a summary for commit aaea4e3. Configure here.}