0.0.2-alpha.71

Before, Next.js answered 404 for it until the server restarted, because next start serves only the files public/ held when it started. A route at src/app/uploads/[...path]/route.ts, built on the new nextly/api/uploads export, serves the rest: it streams files, answers Range requests for video and audio, sends ETag and caching headers, sets nosniff and a script-blocking policy on SVGs, and answers 404 for any path outside the storage folder and whenever cloud storage holds media. The local adapter's check that a path stays inside its folder no longer accepts a sibling folder whose name starts with the folder's own, such as public/uploads-private beside public/uploads.

Before you upgrade: projects don't ship the uploads route yet, so an app keeps the old behaviour until it has one. Add src/app/uploads/[...path]/route.ts (or app/uploads/[...path]/route.ts without a src/ folder) exporting GET and HEAD from createUploadsHandlers({ config }) in nextly/api/uploads, as shown in Media & Storage. Until then, a production server logs a warning naming the file the first time an upload would be unreachable.

Every package that validates input with zod gets the fixed version. - DOMPurify before 3.4.17 had sanitizer bypasses in its SAFE_FOR_TEMPLATES, DOM-output and IN_PLACE modes (GHSA-cg2g-xh64-v4q7, GHSA-mrv2-3pqr-j5jr). Nextly's SVG upload sanitizer uses none of those modes, so it was not affected; the floor still rises, so no install can resolve an affected version.