The AI and Tech Weekly: June 26, 2026

A security incident special: how my VPS got crypto-jacked, and the container hardening that followed

---

The Big Picture

Hostinger sent a CPU limitation alert on my VPS. I SSHed in and ran top: the server was pegging 196% CPU. Nothing obvious in my own apps. Then I checked Docker:

docker exec myapp ls -lah /tmp

Three ELF binaries sitting in /tmp of my Next.js container, owned by the nextjs process user:

• HelloMrMeeseeks
• pls_pak_choi
• plazooza

These were Monero miners running silently for days before triggering the CPU limit. The entry point was a tool I installed myself: an "OpenClaw" alternative whose install script I ran on a production server without auditing it first.

I am sharing the full breakdown so you don't make the same mistakes.

---

The Attack, Step by Step

1. I opened the door myself

I ran a few tools on my production server as root without auditing their install scripts. A classic curl | bash supply-chain risk: whatever the script does, it does it with full privileges on your box.

2. Persistence via a fake systemd service

The installation script registered a systemd service called openfang that restart-looped, killing the CPU. Masquerading as a legitimate-sounding unit name is a common trick; it survives reboots and blends into systemctl output.

3. RCE into Docker

Write access to a mounted host volume allowed the execution of arbitrary code inside the container, dropping miners into /tmp. Server-side rendering of MDX documents served as the remote code execution entry point.

4. The cleanup and the fix

I removed the binaries, disabled the rogue systemd service, and hardened docker-compose.yml:

• read_only: true to lock down the container filesystem.
• tmpfs /tmp:noexec,nosuid,size=50m to prevent executing binaries from /tmp.
• cpus: 1.0 and mem_limit: 512m to cap resource usage so a future breach cannot starve the host.

---

Tips and Tricks from the Community

1. Mount /tmp as tmpfs with noexec — Add tmpfs: /tmp:noexec,nosuid,size=50m to your Docker Compose service. Attackers love /tmp because every process can write there; noexec blocks arbitrary binary execution even if a payload lands.

2. Set read_only: true on container services — A read-only root filesystem prevents attackers from writing payload files anywhere except explicitly mounted volumes. Most web apps only need write access to one or two paths.

3. Limit CPU and memory per container — Resource caps (cpus, mem_limit) contain the blast radius of a breach. A crypto-miner capped at one core is an annoyance; an uncapped one takes down your whole server.

4. Never run untrusted install scripts as root — Read the script before piping it to bash, or run it in a throwaway VM first. Supply-chain attacks increasingly target developer tools precisely because we install them carelessly.

---

Open Source This Week

• Bumblebee — A read-only dependency scanner from Perplexity AI that verifies third-party taps, packages, MCP servers, and VS Code extensions for suspicious code without running install scripts. github.com/perplexity-ai/bumblebee

---

One More Thing

The uncomfortable lesson from this incident is that the weakest link was not the container runtime or the firewall. It was me, trusting an install script because the tool was popular that week. Self-hosting developer tools is worth it, but treat every curl | bash as code review you skipped. Next week, back to the regular market news and startup ideas.