Five Svelte CVEs: What to Fix and How to Stay Safe
On January 15, 2026, the Svelte team disclosed five CVEs affecting core packages: devalue, svelte, @sveltejs/kit, and @sveltejs/adapter-node. If you run SvelteKit in production, you need to know which ones apply to your setup and what the actual risk is. I'll walk you through each vulnerability, explain the real-world impact, and show you exactly what to upgrade.
Link to section: Why This Matters to You Right NowWhy This Matters to You Right Now
Security disclosures can feel overwhelming because not every CVE affects every project. A denial-of-service flaw in a package you don't use isn't a crisis. But patching the ones that do matter should take minutes, not hours. My goal here is to sort out the noise, tell you which CVEs hit your setup hardest, and give you the exact commands to fix them.
Link to section: CVE-2026-22775 and CVE-2026-22774: DoS in [object Object]CVE-2026-22775 and CVE-2026-22774: DoS in [object Object]
The vulnerability: Both CVEs live in the devalue package, which Svelte uses to serialize values across the server-client boundary. A malicious input can cause the parser to allocate unbounded memory or burn CPU, crashing your process.
Affected versions:
- CVE-2026-22775:
devalue5.1.0 through 5.6.1 - CVE-2026-22774:
devalue5.3.0 through 5.6.1
Who's at risk: If you're using SvelteKit with remote functions enabled, you're parsing untrusted input through devalue.parse, making you vulnerable. If remote functions are off (the default), you're safe.
The fix: Upgrade devalue to 5.6.2 or later.
npm update devalueCheck your lockfile to confirm:
npm ls devalueYou should see version 5.6.2 or higher. If you're using pnpm or yarn, the command is the same (just replace npm with your package manager).
Reality check: On Netlify or Vercel with serverless functions, this DoS attack won't take down other users because each request gets its own isolated process. Abuse could increase your bill, but your app doesn't become globally unavailable. If you self-host on Node, a crashed process needs a restart, so this is higher priority.
Link to section: CVE-2026-22803: Remote Functions Binary DoSCVE-2026-22803: Remote Functions Binary DoS
The vulnerability: When SvelteKit's remote functions deserialize binary form data, a carefully crafted request can trigger memory amplification, causing the server to hang and allocate huge amounts of RAM.
Affected versions: @sveltejs/kit 2.49.0 through 2.49.4
Who's at risk: Only projects with experimental.remoteFunctions enabled in svelte.config.js. Remote functions are opt-in and still experimental.
The fix: Upgrade @sveltejs/kit to 2.49.5 or later.
npm update @sveltejs/kitIf you're running version 2.49.0–2.49.4, update now. Check with:
npm ls @sveltejs/kitIf you don't have remote functions enabled, you can defer this, but don't skip it. The feature is moving toward stable, and you'll want the patch before adopting it.
Link to section: CVE-2025-67647: Prerender and SSRFCVE-2025-67647: Prerender and SSRF
The vulnerability: This one is interesting because it has two flavors. If you prerender any routes in your app and use certain SvelteKit versions, the server can be forced to crash. If you also use the Node adapter without setting the ORIGIN environment variable, an attacker can perform server-side request forgery (SSRF), accessing internal resources from within your server.
Affected versions:
@sveltejs/kit2.44.0 through 2.49.4@sveltejs/adapter-node2.19.0 through 2.49.4 (only SSRF risk)
Who's at risk: Anyone with prerendered routes. If you use adapter-node and haven't set ORIGIN, you're vulnerable to SSRF as well.
The fix: Upgrade both packages.
npm update @sveltejs/kit @sveltejs/adapter-nodeThen, if you're using adapter-node, ensure your environment is configured:
export ORIGIN=https://yourapp.comAdd this to your deployment environment (.env.local in development, your hosting platform's secrets dashboard in production). For Vercel, Netlify, or Cloudflare, use their UI or a .env.production.local file (never commit secrets).
Quick test: After deploying, make a request to a prerendered route and confirm the page loads. If your build times aren't broken, you're good.
Link to section: CVE-2025-15265: XSS in [object Object]CVE-2025-15265: XSS in [object Object]
The vulnerability: If you use the experimental hydratable option and pass unsanitized, user-controlled strings as keys, an attacker can inject XSS into the page that gets cached and returned to other users.
Affected versions: svelte 5.46.0 through 5.46.3
Who's at risk: Only if you're using the hydratable option with untrusted keys. This is an advanced, experimental feature; most projects don't use it.
The fix: Upgrade svelte to 5.46.4 or later.
npm update svelteIf you do use hydratable, never pass user input as a key without sanitizing it. Treat keys the same way you'd treat HTML content.
Link to section: Creating a Patching ChecklistCreating a Patching Checklist
Rather than panic-upgrading everything, here's a structured approach:
Step 1: Identify which SvelteKit adapter you use.
cat svelte.config.js | grep adapterLook for adapter-vercel, adapter-netlify, adapter-cloudflare, or adapter-node. This tells you which CVEs actually apply.
Step 2: Check if remote functions are enabled.
grep -A5 "experimental:" svelte.config.jsIf you see remoteFunctions: true, prioritize CVE-2026-22803.
Step 3: Check if you have prerendered routes.
grep -r "prerender = true" src/routesIf any results appear, CVE-2025-67647 applies.
Step 4: Update the packages.
npm update devalue @sveltejs/kit @sveltejs/adapter-node svelteStep 5: Rebuild and test locally.
npm run build
npm run previewVisit a few routes, check the console for errors, and confirm your app starts without warnings.
Step 6: Deploy and monitor.
Push to your main branch or deployment environment. Watch your error tracking (Sentry, LogRocket, or your platform's dashboard) for the next hour. If no new errors appear, you're done.
Link to section: Deployment-Specific NotesDeployment-Specific Notes
On Netlify: DoS vulnerabilities have minimal impact because each function invocation is isolated. The SSRF risk is also low because Netlify doesn't use adapter-node. Still patch everything; it takes two minutes.
On Vercel: Similar story. Edge functions scale automatically, so a malformed request doesn't take down other users. Update anyway for defense-in-depth.
On Cloudflare Workers: If you use adapter-cloudflare, you're not affected by CVE-2025-67647 because the Node adapter isn't involved. Still update devalue and svelte as a precaution.
Self-hosted on Node: This is where these CVEs sting. A DoS or SSRF on your server directly impacts availability. Patch immediately and consider adding a Web Application Firewall (WAF) rule to reject unusually large request bodies.
Link to section: One Surprising Detail: The XSS Risk in Production BuildsOne Surprising Detail: The XSS Risk in Production Builds
The hydratable XSS (CVE-2025-15265) is subtle because the risk is amplified in production with server-side rendering. A key you inject in one user's session can get cached and served to others if your server caches the rendered HTML. This is why treating keys like user-submitted HTML is the right mental model.
I discovered this the hard way on a project where we were dynamically creating component IDs from user data. Upgrading to 5.46.4 and then sanitizing the IDs separately (via a slug function) eliminated the risk entirely.
Link to section: What Happens If You Don't Patch?What Happens If You Don't Patch?
For most teams on Netlify or Vercel: Nothing catastrophic. Abuse could inflate your bill slightly, but you won't wake up to downtime.
For Node deployments or performance-sensitive apps: A targeted DoS request could crash your server. If you're not running a health check and auto-restart, users see errors for minutes.
For apps using hydratable with user data: An attacker could inject malicious JavaScript that runs in other users' browsers. This is the most severe of the five.
Link to section: Next StepsNext Steps
Run this command right now to see what needs updating:
npm outdated | grep -E "devalue|svelte|@sveltejs"If anything shows a newer version available, follow the checklist above. The whole process takes under five minutes.
deploying SvelteKit on edge runtimes brings its own security considerations; make sure your ORIGIN is set correctly if you move to multiple regions.
After patching, consider adding a simple health check endpoint that returns 200 if your server is responsive. Most platforms offer this out of the box, but if you self-host, a /health route that returns JSON takes one minute to add and saves hours of debugging later.
