The dependency you forgot you installed
Vulnerable and Outdated Components

The attacker runs a scanner against your deployed app and reads the response headers.

1. 1
   Fingerprint the stack

   The X-Powered-By header, a JS bundle path, and a favicon hash are enough to guess Next.js 13.2 and a specific image library.
2. 2
   Cross-reference CVEs

   They paste the versions into the public CVE database. Two hits. One is critical with a working proof-of-concept on GitHub.
3. 3
   Run the PoC

   They clone the exploit repo, change the URL to yours, and run the script. It works on the first try because the PoC was written against the exact version you shipped.
4. 4
   Land and pivot

   The exploit gives them a shell in your Node process. From there, environment variables, database URL, and session secrets are all one env read away.

The attacker compromised your server using a public exploit against a library you never knowingly installed. The fix had existed for months.

// package.json
{
  "dependencies": {
    "next": "13.2.0",
    "sharp": "^0.30.0",
    "lodash": "4.17.11",
    "marked": "^2.0.0"
  }
}
// No lockfile committed. No audit step.
// No Renovate, no Dependabot, no CI check.

// package.json
{
  "dependencies": {
    "next": "14.2.15",
    "sharp": "0.33.5",
    "lodash": "4.17.21",
    "marked": "14.1.3"
  },
  "scripts": {
    "preinstall": "npx only-allow yarn",
    "audit": "yarn npm audit --severity high"
  }
}
// Lockfile committed. Renovate runs weekly.
// CI fails the build on high-severity advisories.

The fix is not a code change — it's a process change. Pin versions, commit the lockfile, and let a bot open PRs when something ships a CVE. The hard part is deciding to care before a scanner tells you to.