GeezerVison

Updates next from 13.5.6 to 15.5.28.

Fixes GHSA-2464-fhr4-w9xw — a critical unauthenticated remote code execution in the Next.js Image Optimization API when SVG files are used on glibc-based Linux (CVSS 4.0 9.5): next 13.5.6 sits inside the advisory's affected range, but the image has no decoder for the flaw: the published tag installs no sharp and no libvips binding at any depth, a Node 18 install of this lock resolves no sharp because 0.35.5 requires Node >= 20.9, and the shipped optimizer throws a 500 before decoding, so no decoder-specific exploit exists in that image to fix; the patched sharp 0.35.5 applies only on Node >= 20.9, where the same lock resolves sharp 0.35.5 and @img/sharp-libvips 1.3.4 (rsvg 2.63.2).

What this changes:

• package.json — next ^13.2.4 (line 44) -> ^15.5.28 and next-auth ^4.22.1 (line 45) -> ^4.24.15; next-auth 4.24.15 is the Next 15 peer-compatible release - 4.24.7 declares next ^12.2.5 || ^13 || ^14 and 4.24.15 declares next ^12.2.5 || ^13 || ^14 || ^15 || ^16 - so the old peer range stops below Next 15; every other dependency and every script is unchanged
• pnpm-lock.yaml — next 13.5.6 re-resolved to 15.5.28 and next-auth 4.24.7 to 4.24.15; next-auth 4.24.15 also adds uuid 11.1.1 while the application's declared uuid ^9.0.0 still resolves separately at 9.0.1; the lock also resolves next 15's optional sharp 0.35.5 and @img/sharp-libvips 1.3.4, with no next 13 entry left. sharp 0.35.5 requires Node >= 20.9 and is skipped as an optional dependency on the node:18-alpine image these Dockerfiles build, so this PR does not install a decoder in that image and does not fix a decoder exploit there; on Node >= 20.9 the same lock resolves sharp 0.35.5 and @img/sharp-libvips 1.3.4 (rsvg 2.63.2)
• src/pages/api/chat.ts — the base file's req.ip, removed in Next 15, becomes getClientIp(req): x-forwarded-for's first entry, then x-real-ip, else "unknown", for the OpenAI user hint only; the prompt, model and streaming code is untouched
• pnpm-workspace.yaml — new file: the version-pinned Prisma allowBuilds policy that the repository's pnpm 12 frozen CI install requires. CI and both Dockerfile deps stages run pnpm i --frozen-lockfile with build scripts enabled, and pnpm 12 exits 1 with ERR_PNPM_IGNORED_BUILDS unless every package whose lifecycle script it would run is declared; this map approves exactly @prisma/[email protected] (its postinstall runs prisma generate) and @prisma/[email protected] (its postinstall fetches the query and migration engines) and lists [email protected] and [email protected] as false. The name@version keys pin each approval to the reviewed lockfile's exact version, so no future release of those packages is approved by name. Every other package's build script stays unapproved, and pnpm 11+'s default strictDepBuilds: true still fails the install rather than run a script nobody reviewed
• Dockerfile — the shared base stage now runs RUN apk add --no-cache openssl immediately after FROM node:18-alpine AS base, so the deps postinstall, the builder's prisma generate and the runner all detect OpenSSL and select Prisma's openssl-3.0.x musl engine instead of the openssl-1.1.x build the image cannot load; the deps-stage COPY additionally includes pnpm-workspace.yaml beside package.json and pnpm-lock.yaml*, so the image's pnpm i --frozen-lockfile sees the same build-script policy; every other line is unchanged
• Dockerfile.sqlchat-ai — the same shared-base RUN apk add --no-cache openssl line and the same deps-stage COPY change as Dockerfile, in the www.sqlchat.ai variant, whose deps stage previously installed only libc6-compat and therefore selected Prisma's openssl-1.1.x musl engine; every other line is unchanged

How to verify:

pnpm install --frozen-lockfile # exits 0 with this pnpm-workspace.yaml: only @prisma/[email protected] and @prisma/[email protected] may run scripts and both do; the Prisma client is generated and, with openssl installed, its engine loads. Measured on node 18.20.8 and node 22 with pnpm 12.15.0 and pnpm 10.30.3
# controls: without the policy the same install exits 1 with ERR_PNPM_IGNORED_BUILDS naming @prisma/[email protected], @prisma/[email protected] and [email protected]; removing the '@prisma/[email protected]' entry exits 1 naming exactly that entry
# Prisma engine-selection control (stock node:18-alpine, no image involved): on stock node:18-alpine with openssl, @prisma/client's postinstall generates libquery_engine-linux-musl-openssl-3.0.x.so.node and new PrismaClient().$disconnect() exits 0; on the bare image it generates libquery_engine-linux-musl.so.node and $disconnect() exits 1 with "Error loading shared library libssl.so.1.1", so openssl must be present in every stage that detects or loads the engine - this patch puts it in the shared base stage that deps, builder and runner all inherit
# without the openssl binary the same generated client exits 1 with "Query engine library for current platform could not be found"; nft 0.27.10 (the tracer Next 15.5.28 bundles) traces node_modules/.pnpm/@[email protected][email protected]/node_modules/.prisma/client/libquery_engine-*.so.node into the standalone file list, so no outputFileTracingIncludes is needed
node -p "require('next/package.json').version"
pnpm lint
pnpm exec tsc --noEmit # only pre-existing diagnostics: the patched tree's log is byte-identical to 85af0b4 without this patch
docker build --network host -f Dockerfile -t sqlchat-176:dockerfile . # this prepared Dockerfile was built once in a Linux amd64 build environment (Docker 29.6.1), exit 0: @prisma/client and @prisma/engines are the only packages whose build scripts run, prisma generate selects libquery_engine-linux-musl-openssl-3.0.x.so.node with no libssl-detection fallback warning, and next 15.5.28 compiles
docker build --network host -f Dockerfile.sqlchat-ai -t sqlchat-176:sqlchat-ai . # this prepared Dockerfile was built once in the same Linux amd64 build environment, exit 0, reusing the same shared-base openssl layer (base 2/2 CACHED)
docker run -d --name sqlchat-176-run-df --network host -e PORT=3811 -e HOSTNAME=127.0.0.1 sqlchat-176:dockerfile && curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:3811/ # 200, 2272 bytes: the standalone runner starts (Next.js 15.5.28, Ready in 140 ms) and serves the statically rendered home page, which has no getServerSideProps; the Dockerfile.sqlchat-ai runner returned the same 200
docker exec -u nextjs -w /app sqlchat-176-run-df node -e 'const {PrismaClient}=require("@prisma/client"); const p=new PrismaClient(); p.$disconnect().then(()=>console.log("ENGINE_LOADED_AND_DISCONNECTED")).catch(e=>{console.log("ENGINE_LOAD_ERR",e.message);process.exit(3)})' # ENGINE_LOADED_AND_DISCONNECTED, exit 0 in both runners: Prisma 4.13.0 locates and loads the musl openssl-3.0.x engine as nextjs without opening a database connection
# limits: no database connection or query ($disconnect() only); linux/amd64 only, no arm64 or multi-arch build; the published docker.io/sqlchat/sqlchat image was not re-checked, because this is a locally built image from the prepared artifact

Automated security patch from Superbot.