fix(svelte-netlify): resolve Fiber v2 to the patched release in the module graph

[ReneWerner87]

Follow-up to #5290, covering the Fiber v2 advisories specifically.

Where Fiber v2 actually is

I resolved the full module graph of all 91 Go modules (go list -m all, 899 unique versions) and checked every one against OSV. Fiber v2 appears in exactly three places:

Module	Version	Status
v2/aws-sam/app	v2.52.14 (direct)	latest release, no open advisories
openapi	v2.52.14 (indirect)	latest release, no open advisories
svelte-netlify	v2.52.1 (module graph only)	affected, addressed here

Everything else in the repository is on Fiber v3.4.0, which is also the latest and carries no advisories.

svelte-netlify

v2.52.1 reaches the graph through github.com/awslabs/aws-lambda-go-api-proxy v0.16.2, which pins github.com/gofiber/fiber/v2 v2.52.1 in its own go.mod. v0.16.2 is the latest release of that library, so there is no upstream bump to take.

v2.52.1 is affected by eleven advisories, two of them critical:

• GHSA-98j2-3j3p-fw2v, session middleware token injection (Critical)
• GHSA-68rr-p4fp-j59v, insecure utils.UUIDv4() fallback (Critical)
• GHSA-qx2q-88mx-vhg7 (High), plus 8 moderate

None of them apply to this recipe. It uses Fiber v3 throughout and imports only the proxy's /core package, which does not pull in Fiber v2. Concretely:

• github.com/gofiber/fiber/v2 is not listed in svelte-netlify/go.mod
• it has no entry in svelte-netlify/go.sum, so the toolchain never downloads or compiles it
• go mod why -m github.com/gofiber/fiber/v2 reports (main module does not need module github.com/gofiber/fiber/v2)

It is a module-graph artifact, not a dependency of the build.

The fix

It is still reported by anything that resolves the module graph rather than the build list, so this pins it to the patched v2.52.14.

A plain indirect require does not work here. I tried it first, and go mod tidy drops it again because no package in the main module needs it:

after go get:       github.com/gofiber/fiber/v2 v2.52.14
after go mod tidy:  github.com/gofiber/fiber/v2 v2.52.1

A replace survives tidy and selects v2.52.14 without changing what is compiled:

github.com/gofiber/fiber/v2 v2.52.1 => github.com/gofiber/fiber/v2 v2.52.14

All three Fiber v2 sites now resolve to v2.52.14.

Verification

• go build ./... passes in svelte-netlify
• go mod tidy leaves the replace in place and does not otherwise alter go.mod
• Re-resolved graph confirms v2.52.14 in all three modules

If you would rather not carry a replace for a dependency that is never compiled, the alternative is to dismiss the alert as "vulnerable code is not actually used". Happy to drop this PR in that case.

[Copilot]

Pull request overview

Pins the vulnerable github.com/gofiber/fiber/v2 version that appears only in svelte-netlify’s module graph (via aws-lambda-go-api-proxy) to a patched release, so module-graph-based scanners stop reporting Fiber v2 advisories even though the recipe builds against Fiber v3.

Changes:

• Adds a replace directive in svelte-netlify/go.mod to force Fiber v2 to resolve to v2.52.14.
• Documents why Fiber v2 shows up (module graph artifact) and why replace is used instead of an indirect require.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

svelte-netlify/go.mod:34

• The replace directive is currently unversioned on the left-hand side, which forces all github.com/gofiber/fiber/v2 versions in the module graph to v2.52.14. That can unintentionally block future upgrades (e.g., if a dependency later moves to a newer Fiber v2, this would still pin back to v2.52.14). Since the motivating case is specifically v2.52.1, consider making the replacement version-specific.

replace github.com/gofiber/fiber/v2 => github.com/gofiber/fiber/v2 v2.52.14

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

[ReneWerner87]

Closing without merging.

Investigating the reviewer's point about the unscoped replace led to the more useful finding: Fiber v2 is not a dependency of this recipe in any meaningful sense, so pinning it has no security value.

aws-lambda-go-api-proxy keeps adapters for gin, chi, fiber v2, gorilla/mux, iris, echo and negroni in a single module with one go.mod. Importing any part of it, here just /core for four symbols in a 109-line adapter, inherits the entire framework list into the module graph.

None of it is compiled. Verified for svelte-netlify:

• no entry in go.sum for gofiber/fiber/v2, go-chi/chi, gomarkdown/markdown, sirupsen/logrus, gin-gonic/gin, labstack/echo or kataras/iris
• go mod why -m reports main module does not need module for each

So this PR would have pinned one of four equally unreachable entries (fiber v2 with 11 advisories, gomarkdown 4, chi 3, logrus 2), carrying a replace in an example repository to change a number that never reaches a build.

The accurate resolution is to dismiss these alerts as "vulnerable code is not actually used". The durable fix belongs upstream: splitting aws-lambda-go-api-proxy into per-framework submodules, or trimming its go.mod, would clear this for every consumer of that library.

The other two Fiber v2 sites in this repository, v2/aws-sam/app and openapi, are on v2.52.14, the latest release with no open advisories. Nothing to do there.

---

Generated by Claude Code