Skip to content
>_ITDITDWeb Security Platform

By Stack

#Next.js#CVE#dependencies#Docker

Running Next.js safely: not falling behind on published CVEs

With Next.js, the scariest thing is leaving a published CVE unpatched — a months-old CVSS 10.0 RCE has caused real breaches. Four pillars: judge by the running version, machine-monitor dependencies, update fast, and least privilege — through ITD's operational lens.

Published 2026-06-07 Updated 2026-06-07 4 min read

For: anyone shipping apps with Next.js (or similar JS frameworks), especially "built it with AI's help, operating by feel." Distilled from a real incident (→ the neglected CVSS 10.0).

ITD's view: the battle isn't won on 'speed'

Indie developers usually lose at security not from lack of knowledge but from lack of operational continuity. Reading CVE news faster than anyone has no value (leave speed to vendors and news). What works is a system that won't miss the CVEs relevant to you. So this article leans on "systematize," not "know more."

1. Judge by the running version

Measure "am I on a dangerous version" by what's actually running, not the manifest floor — because the manifest number and the running version often disagree.

✗ Count by the package.json floor

"next": "^16.0.0" → "16.0.0 is vulnerable, so we are" — over-counted as "8 vulnerable".

✓ Count by the running version

npm ls next shows the resolved version → auto-bumped ones are safe, only pinned ones lag. Really 2.

The package.json floor lies. Judge by the running version and the risk changes (8 'vulnerable' became 2).
# see the versions actually resolved
npm ls next react react-dom
# inside a running container
docker exec <container> npm ls next

Caret ranges (^16.0.0) auto-bump on rebuild; pinned deps lag. The numbers here are the truth.

2. Machine-monitor your dependencies

Tracking CVEs by hand is impossible, and the miss becomes the incident. Let machines watch.

Free dependency monitoring

osv-scanner --lockfile=pnpm-lock.yaml

On GitHub, enable Dependabot (Settings → Security). You'll get PRs only for CVEs that match your deps.

What matters is prioritization. ITD's stance: rank by "is it being exploited (KEV)" times "how high is the CVSS." A high CVSS you don't use is small impact; a mid-score under active exploitation is top priority — that prioritization is the actual work.

3. Update discipline: fix the root, not the symptom

When a vulnerability appears, upgrade the framework to the patched version to close the hole itself.

Symptom-hiding (insufficient)

  • Block only "suspicious-looking" requests at a reverse proxy
  • Stop the charges/symptom and call it "handled"
  • Leave the RCE itself alive

Root fix (correct)

  • Upgrade the framework to the patched version
  • After upgrading, confirm the signature is gone in your logs
  • Treat first aid and the root fix as two separate jobs, do both

The common failure

"Stopped the charges/symptom" ≠ "handled." First aid and closing the vulnerability are different jobs. Do both.

4. Least privilege to shrink the blast radius

Contain damage if you are hit.

1

Run as a non-privileged user

Don't run the container USER as root. A breach reaches only "that privilege."
2

Bind DB/Redis to the internal network only

Never public. Reduce the directly reachable surface.
3

Separate per service

Split networks and data per service so one breach can't cascade to everything.

These decide whether a breach stops at "env theft inside a container" or reaches "host takeover."

We do this ourselves

ITD monitors its own dependencies for CVEs, exactly as written here — so the incident that started it all (a neglected public CVSS 10.0) never gets missed by a human again. We say "rank by priority (KEV + CVSS)" because that's how we actually operate.

FAQ

QWhat matters most for Next.js security?
A

Before not writing bugs, it's not leaving published CVEs in the framework or its dependencies unpatched. Most severe breaches come from neglected known holes, not novel attacks.

QCan I tell if I'm vulnerable from package.json?
A

No. The `^` (floor) in package.json doesn't reflect reality — caret ranges auto-bump on rebuild, pinned deps lag. Always judge by the version actually running.

QWhat's the one thing to do first, solo?
A

Enable Dependabot (GitHub) or osv-scanner so machines watch your dependencies for CVEs. Manual patrols always miss. A system that continues beats more knowledge.