CVE-2025-67647 is a critical flaw (CVSS 9.1) in SvelteKit. Versions up to 2.49.4 can suffer server side request forgery and denial of service when an app has prerendered routes. Upgrade to SvelteKit 2.49.5, and set the ORIGIN variable if you use adapter-node.
What's affected
- @sveltejs/kit 2.44.0 through 2.49.4: denial of service when the app has at least one prerendered route (export const prerender = true).
- @sveltejs/kit 2.19.0 through 2.49.4: denial of service when the app has a prerendered route, uses adapter-node without a configured ORIGIN variable, and has no reverse proxy validating the Host header.
- Fixed version: 2.49.5.
- The record also lists the adapter-node package as a product, without a separate fixed version. Check the advisory.
How to check if you're exposed
Check the installed SvelteKit version:
npm ls @sveltejs/kit
Use pnpm why @sveltejs/kit or yarn why @sveltejs/kit with those tools. Then check two things in your app: does any route set export const prerender = true, and do you deploy with adapter-node? If both, check whether the ORIGIN environment variable is set in production, and whether a reverse proxy in front of the server validates the Host header.
You can also paste a manifest or lockfile into the free in-browser dependency scan at gold.safeguard.sh/scan. It lists known CVEs for the versions it finds and runs in your browser.
What to do now
- Upgrade @sveltejs/kit to 2.49.5 or later and commit the updated lockfile.
- Set the ORIGIN environment variable on adapter-node deployments so the server does not trust the Host header from requests.
- Make sure your reverse proxy or load balancer rejects Host headers that do not match your domains.
- Search the codebase for prerender settings so you know whether the conditions apply.
- Rebuild and redeploy, then confirm the running version in the deployed container.
- Re-run a dependency scan to confirm the old version is gone from every workspace in a monorepo.
Why it matters
The record lists CWE-918, server side request forgery, and CWE-248, an uncaught exception. When a framework builds a URL from the Host header the client sent, an attacker who controls that header can steer the server toward a destination of their choosing. An unhandled error on the same path can then crash the process.
The conditions in the advisory are specific, and they are mostly about deployment: a missing ORIGIN, no proxy checking the Host header, and prerendered routes. That makes this a good example of why a version number alone does not say how exposed you are. It also means a configuration fix, setting ORIGIN, reduces risk even before the upgrade lands.
The record does not list this CVE as exploited in the wild. Upgrade anyway, since the fix is a patch release.
The ORIGIN setting tells adapter-node which public address the app is served from, so that it does not need to trust whatever Host header arrives. It is documented as a normal production setting, and many guides include it, but it is easy to skip in a container where a proxy handles the domain.
If you have a reverse proxy, check that it rejects unknown Host values instead of passing them through. Many default configurations answer for any host name, which is the situation this advisory describes.
Prerendering is a good feature, and nothing here says to turn it off. The point is to know which conditions apply to you. A short checklist covers it: framework version, whether any route is prerendered, whether adapter-node is used, whether ORIGIN is set, and what your proxy does with the Host header.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does setting ORIGIN replace the upgrade for CVE-2025-67647?
No. The advisory fixes it in 2.49.5. Setting ORIGIN removes one of the stated conditions for the adapter-node case, so do both.
Sources
Last reviewed: 19 October 2026.
