By Stack
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.
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.
# see the versions actually resolved
npm ls next react react-dom
# inside a running container
docker exec <container> npm ls nextCaret 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.yamlOn 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.
Run as a non-privileged user
USER as root. A breach reaches only "that privilege."Bind DB/Redis to the internal network only
Separate per service
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.
Read next
- Incident: A neglected public RCE billed for fraud
- Glossary: CVE · CVSS · RCE
- History: Log4Shell — RCE through a dependency
FAQ
QWhat matters most for Next.js security?
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?
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?
Enable Dependabot (GitHub) or osv-scanner so machines watch your dependencies for CVEs. Manual patrols always miss. A system that continues beats more knowledge.