I run hobby services on a small VM. One morning my Minecraft server was lagging and the CPU was pinned at 100%. A quick look showed several unfamiliar processes hammering all cores. The root cause was remote code execution in an exposed Next.js app, exploited within days of a public disclosure. Attackers dropped a script, ran a crypto miner and left a few persistence hooks. I removed the files, patched Next.js and hardened the host. The cleanup showed me what should have been automated.
Remote code execution in web frameworks gets scanned and exploited almost immediately. For self-hosted applications that means public-facing ports are an open invitation. With RCE the attacker can write files, spawn processes and install a miner that quietly eats CPU. That hurts performance and shortens hardware life. It also leaves backdoors in cron jobs, systemd timers and forgotten services. On my box the obvious signs were high CPU, unknown processes and lag in unrelated services. After containment I checked crontab -l, systemctl list-timers, and the usual places in /etc and /var for dropped scripts. If you see that sort of pattern, treat it as a breach until you have proved otherwise.
Practical hardening cut my exposure. I started with automated updates. On the OS I run unattended-upgrades on Debian/Ubuntu and use package pinning where needed. For Node dependencies I use automated dependency updates from Renovate configured to open small, fast PRs for next and other critical packages. Make sure your CI runs npm audit or equivalent and blocks merges for high-severity alerts. For Next.js security, update the next package to the latest patch as soon as an advisory appears. If your site can be static, serve the static build from a CDN or static host and remove the server side altogether. That takes away a lot of attack surface.
I tightened file uploads and execution paths. Any route that accepts files must validate MIME type, check magic bytes, and write uploads outside the web root with safe permissions. Do not let uploaded files keep executable bits. Avoid spawning child_process from user input. If an app needs to run user code, sandbox it in a container with strict seccomp and cgroups limits. Run periodic malware scans with tools like ClamAV and rootkit hunters, and add simple process checks. A small cron job that logs ps aux --sort=-%cpu and reports spikes to monitoring will catch miners quickly.
Monitoring and limits have kept the setup from repeating the same mess. Set up alerting for sustained high CPU, unusual outbound connections and rapid file changes. Use basic firewall rules and reverse proxies so only intended ports are public. SSH on a non-standard port is fine if you want it, but key-only SSH, fail2ban and a restrictive UFW policy do more work. Containerise risky hobby apps and run them under resource limits so one compromised app cannot choke the host. For vulnerability management, subscribe to Next.js release notes, use automated dependency PRs, and check critical services at least weekly. If a patch is tagged as RCE or critical, push it through in stages and do not leave it sitting.
The takeaways from the incident were plain enough: make OS and package updates automatic, automate dependency updates for Next.js and Node modules, lock down file uploads and execution, monitor CPU and processes, and audit cron and systemd after any anomaly. Reduce public exposure by serving static content where possible or by putting apps behind a proxy and firewall. That cuts the chance of a quick compromise and makes recovery less painful.
