I got hacked: My Hetzner server started mining Monero

Docker / Containers as a Security Boundary

• Many comments stress that Docker should not be treated as a strong security boundary; it offers process isolation but still shares the host kernel.
• Running containers as root without user namespaces is described as “insecure”; user namespaces and rootless runtimes (Podman, rootless Docker) are recommended.
• Others argue Docker can be a reasonable boundary if kept unprivileged, with no --privileged, no broad mounts, and no docker.sock exposure—but still weaker than VMs or microVMs (Firecracker, gVisor).

Common Misconfigurations and Escape Vectors

• Frequent footguns mentioned:
  • Mounting docker.sock into containers (equivalent to host root).
  • Overly broad bind-mounts (e.g. /, /run, or writable .git), allowing malware to drop or modify host scripts/binaries.
  • --privileged, extra capabilities like CAP_SYS_PTRACE, and bridged networking used carelessly.
• Example attack paths: container root writing 0777 or setuid files into host paths, overwriting existing scripts, or harvesting credentials from home/config directories.
• Advice: use distroless/“empty” images, run as non-root inside, read-only filesystems with narrow writable mounts, CPU/memory limits, and no outbound network unless needed.

Next.js / Umami / React CVE Context

• Multiple readers report their own Umami/Next.js instances compromised by the same recent RCE, often quickly after disclosure.
• Some see dropping Umami/Next.js entirely as overreaction; nothing is immune, and any analytics or web stack can have CVEs.
• There’s concern that many operators didn’t realize their containers used vulnerable React/Next.js components.

Firewalls, Exposure, and Network Design

• Critique that the server had no proper firewall and exposed services like PostgreSQL and RabbitMQ directly to the internet.
• Recommendations:
  • Use host and provider firewalls (Hetzner’s included), ideally with egress filtering and possibly HTTP proxies for outbound traffic.
  • Avoid binding containers on 0.0.0.0; bind to localhost or private IPs and front them with reverse proxies or WAFs (Cloudflare, etc.).
  • For admin access, use VPNs (WireGuard, Tailscale) or bastion hosts instead of open SSH.

LLM-Generated Article and Accuracy Concerns

• Several comments object to the “LLM voice” and undisclosed AI assistance, saying they prefer imperfect human prose.
• Technical inaccuracies (e.g., Puppeteer being involved, overconfident “it never escaped”) are attributed to LLM hallucinations and insufficient fact-checking.
• The author acknowledges this, apologizes, and plans a human-written rewrite; some still see publishing partially checked LLM output as problematic.

Monero Mining on Compromised Hosts

• Monero is seen as a natural target: RandomX is ASIC-resistant and CPU-minable; when compute and power are stolen, even tiny per-host returns are profitable at scale.
• Some treat mining malware as a “visible” and relatively benign failure mode compared to stealthy data theft, though others resent crypto’s role in incentivizing botnets.

Incident Response and Rebuild vs. Patch

• Several commenters argue the only truly safe response is to rebuild the host from scratch, treating it as fully compromised and using the incident to test backups and declarative configs.
• Others consider containment at the container level acceptable for low-value hobby systems, especially when backups exist and the attacker’s goal is clearly commodity mining.

Self-Hosting Practices and Alternatives

• Best-practice sketches:
  • Rootless containers, minimal privileges, tight mounts, read-only images, resource and network limits, vulnerability scanning.
  • Layered defenses: external firewalls, WAFs, VPN-only admin services, avoiding direct database/message-broker exposure.
• Some suggest that for personal blogs or small projects, using managed hosting (e.g., WordPress.com, managed servers) may be safer than running one’s own VPS stack.