CVE-2026-54150: Infoleak
Impact
The HTTP route handler exported by next-video/request-handler — which the README instructs consumers to mount at /api/video — allows an unauthenticated remote attacker to read arbitrary .json files from the production filesystem of any application following the documented setup.
The handler's GET endpoint accepts a url query parameter and uses it to locate and serve a JSON asset descriptor from disk. The only guard between "remote URL" and "local file path" is a regex check for ^https?://. Any value that does not match that prefix is treated as a local path, .json is appended, and the file is read with fs.readFile and returned in the HTTP response — with no authentication, no path canonicalization, and no traversal guard.
On a typical Next.js deployment this exposes, at minimum: - The Next.js Server Actions AES encryption key (.next/server/server-reference-manifest.json) - The Next.js Preview/Draft Mode keys (previewModeId, previewModeSigningKey, previewModeEncryptionKey) - Internal build manifests, route registries, and absolute runtime paths - Application-specific asset metadata (e.g. Mux uploadId, assetId, playbackId values stored in videos/.json)
Any application that mounted /api/video following the documented one-liner is affected.
Patches
2.8.1
Workarounds
Until a patched version is available, wrap the exported handler in your own route file and validate the url parameter before passing it through:
- Reject any url value that does not begin with https://, or that does not match a known allowlist of trusted remote hosts. - Alternatively, remove the /api/video route entirely if your application only uses build-time import of local video files and does not use <Video src="https://..."> with string URLs at runtime.
References
- src/request-handler.ts — the vulnerable GET handler - src/assets.ts — getAssetPath(), where the local-vs-remote branching occurs - src/utils/utils.ts — isRemote(), the sole guard between the two branches - src/config.ts — loadAsset(), which performs the unconstrained fs.readFile
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/next-videoto a version that resolves this vulnerability.Fixed in 2.8.1 - Remove
Remove
/api/video route (exported handler from next-video/request-handler)from your environment.If the application only uses build-time `import` of local video files and does not use `<Video src="https://...">` with string URLs at runtime, remove the `/api/video` route entirely.
- Configuration
Until a patched version is available, do not pass the request through unvalidated. Instead, wrap the exported handler and, before calling it, validate the GET query parameter `url`: (1) it must begin with `https://` (not `http://`), and (2) it must match a known allowlist of trusted remote hosts. Reject any other `url` values.
Application route wrapper around next-video/request-handler (mounted at /api/video) url query parameter validation = Reject any url that does not begin with https:// and reject values that do not match a known allowlist of trusted remote hosts
Event History
Frequently Asked Questions
Which applications are exposed?
Applications using npm/next-video that mount the next-video/request-handler route as documented at /api/video are exposed. The issue affects production deployments where the handler can access the application filesystem.
Does exploitation require authentication or a privileged account?
No. An unauthenticated remote attacker can use the handler's GET endpoint and supply a url parameter that does not begin with http:// or https://, causing it to be handled as a local path.
What information could be disclosed?
The handler can return arbitrary .json files readable by the production process. Listed examples include the Next.js Server Actions AES encryption key, Preview/Draft Mode keys, build manifests, route registries, absolute runtime paths, and application asset metadata.
How can I determine whether my deployment is affected?
Check whether your application exposes next-video/request-handler, particularly at the documented /api/video route, and whether its GET endpoint is reachable without authentication. Also determine whether the application process can read sensitive JSON files such as .next/server/server-reference-manifest.json.