fix: update fast-uri to 3.1.5 via lockfile (CVE-2026-13676, CVE-2026-18446)

[anupamme]

Summary

Updates fast-uri from 3.0.6 to 3.1.5 by regenerating the lockfile — no npm overrides block.

Dependency path

serve@14.2.6
└── ajv@8.18.0 (declares "fast-uri": "^3.0.1")
    └── fast-uri@3.1.5  ← was 3.0.6

ajv@8.x has always declared "fast-uri": "^3.0.1". fast-uri@3.1.5 is the latest patched 3.x release and satisfies that range naturally, so the fix requires only a lockfile update — the overrides block from the previous commit has been removed.

Vulnerabilities addressed

CVE	Severity	Description
CVE-2026-13676	HIGH	Security policy bypass via improper Unicode hostname canonicalization
CVE-2026-18446 (GHSA-7p8r-x3mc-p8w7)	HIGH	Additional fast-uri security issue patched in 3.1.5 / 4.1.2 / 2.4.4

Verification

$ npm ls fast-uri
hacktoberfest-2022@0.1.0
└─┬ serve@14.2.6
  └─┬ ajv@8.18.0
    └── fast-uri@3.1.5

No (overridden) annotation — resolved naturally within ajv's declared range.

$ npm run test:unit
ℹ tests 193
ℹ pass  193
ℹ fail  0

Changes

• package.json — removed overrides block
• package-lock.json — fast-uri now resolves to 3.1.5

[MattIPv4]

🤨 An automated AI fix, which is setting an override, creating a maintenance headache, instead of properly bumping dependencies to remove the vulnerable versions

[anupamme]

Thanks for catching this — you're right. The override wasn't the correct approach.

I've traced the dependency path: serve → ajv@8.x → fast-uri. Since ajv@8.x declares "fast-uri": "^3.0.1" (a range it has kept across all v8 releases), fast-uri@3.1.5 satisfies it naturally. I've removed the overrides block and updated the lockfile so fast-uri resolves to 3.1.5 within ajv's existing declared range — no override needed.

I've also updated the target to 3.1.5 rather than the earlier 4.1.2, which patches both CVE-2026-13676 and the subsequently-disclosed CVE-2026-18446 (GHSA-7p8r-x3mc-p8w7). All 193 unit tests pass.