I disrecommend UFW.

firewalld is a much better pick in current year and will not grow unmaintainable the way UFW rules can.

    firewall-cmd --persistent --set-default-zone=block
    firewall-cmd --persistent --zone=block --add-service=ssh
    firewall-cmd --persistent --zone=block --add-service=https
    firewall-cmd --persistent --zone=block --add-port=80/tcp
    firewall-cmd --reload

Specifically for docker it is a very common gotcha that the container runtime can and will bypass firewall rules and open ports anyway. Depending on your configuration, those firewall rules in OP may not actually do anything to prevent docker from opening incoming ports.

Newer versions of firewalld gives an easy way to configure this via StrictForwardPorts=yes in /etc/firewalld/firewalld.conf.

I'm not even sure what to say, or think, or even how to feel about the frontend ecosystem at this point. I've been debating on leaving the whole "web app" ecosystem as my main employment ventures and applying to some places requiring C++. C++ seems much easier to understand than what ever the latest frontend fad is. /rant

Is that the case, though? My understanding was, that even if I run a docker container as root and the container is 100% compromised, there still would need to be a vulnerability in docker for it to “attack” the host, or am I missing something?

"CVE-2025-66478 - Next.js/Puppeteer RCE)"

Now, JS sites everywhere are getting hacked.

JS has turned into the very thing it strived to replace.

It's good to see developers haven't changed. ;)

From the root container, depending on volume mounts and capabilities granted to the container, they would enumerate the host directories and find the names of common scripts and then overwrite one such script. Or to be even sneakier, they can append their malicious code to an existing script in the host filesystem. Now each time you run your script, their code piggybacks.

OTOH if I had written such a script for linux I'd be looking to grab the contents of $(hist) $(env) $(cat /etc/{group,passwd})... then enumerate /usr/bin/ /usr/local/bin/ and the XDG_{CACHE,CONFIG} dirs - some plaintext credentials are usually here. The $HOME/.{aws,docker,claude,ssh} Basically the attacker just needs to know their way around your OS. The script enumerating these directories is the 0777 script they were able to write from inside the root access container.

That said, do you have an image of the box or a container image? I'm curious about it.

And maybe updating container images with a mechanism similar to renovate with "minimumReleaseTime=7days" or something similar!?

Meanwhile companies think the clouds are looking at it.... anyhow. it is a real problem.

Luckily for me, the software I had installed[1] was in an LXC container running under Incus, so the intrusion never escaped the application environment, and the container itself was configured with low CPU priority so I didn't even notice it until I tried to visit the page and it didn't load.

I looked around a bit and it seemed like an SSH key had been added under the root user, and there were some kind of remote management agents installed. This container was running Alpine so it was pretty easy to identify what processes didn't belong from a simple ps output of the remaining processes after shutting down the actual web application.

In the end, I just scrapped the container, but I did save it in case I ever feel like digging around (probably not). In the end I did learn some useful things:

- It's a good idea to assume your system will get taken over, so ensure it's isolated and suitably resource constrained (looking at you, pay-as-you-go cloud users).

- Make sure you have snapshots and backups, in my case I do daily ZFS snapshots in Incus which makes rolling back to before the intrusion a breeze.

- While ideally anything compromised should be scrapped, rolling back, locking it down and upgrading might be OK depending on the threat.

Regarding the miner itself:

- from what I could see in its configuration it hadn't actually been correctly configured, so it's possible they do some kind of benchmark and just leave the system silently compromised if it's not "worth it", they still have a way in to use it for other purposes.

- no attempt had been made at file system obfuscation, which is probably the only reason I really discovered it. There were literally folders in /root lying around with the word "monero" in them, this could have been easily hidden.

- if they hadn't installed a miner and just silently compromised the system, leaving whatever running on it alone (or even doing a better job at CPU priority), I probably never would have noticed this.

[1]: https://github.com/umami-software/umami

  $ sudo ufw default deny incoming
  $ sudo ufw default allow outgoing
  $ sudo ufw allow ssh
  $ sudo ufw allow 80/tcp
  $ sudo ufw allow 443/tcp
  $ sudo ufw enable

Examples like this, are why I don’t run a VPS.

I could definitely do it (I have, in the past), but I’m a mediocre admin, at best.

I prefer paying folks that know their shit to run my hosting.

- Hetzner firewall (because ufw doesn't work well with docker) to only allow public access to 443.

- Self-hosted OpenVPN to access all private ports. I also self-host an additional Wireguard instance as a backup VPN.

- Cloudflare Access to protect `*.coolifydomain.com` by default. This would have helped protect the OP's Umami setup since only the OP can access the Umami dashboard. Bypass rules can be created in Cloudflare Access to allow access to other systems that need access using IP or domain.

- Cloudflare Access rules to only allow access to internal admin path such as /wp-admin/ through my VPN IP (or via email OTP to specified email ids).

- Traefik labels on docker-compose files in Coolify to add basic auth to internal services which can't be behind Cloudflare Access such as self-hosted Prefect. This would have also added a login screen before an attacker would see Umami's app.

- I host frontends only on Vercel or Cloudflare workers and host the backend API on the Coolify server. Both of these are confirmed to never have been affected, due to decoupling of application routing.

- Finally a bash cron script running on server every 5 minutes that monitors the resources and sends me an alert via Pushover when the usages are above the defined thresholds. We need monitoring and alert as well, security measures alone are not enough.

Even with all these steps, there will always be edge cases. That's the caveat of self-hosting but at the same time it's very liberating.

Yikes. I would still recommend a server rebuild. That is _not_ a safe configuration in 2025, whatsoever. You are very likely to have a much better engineered persistent infection on that system.

> Here’s the test. If /tmp/.XIN-unix/javae exists on my host, I’m fucked. If it doesn’t exist, then what I’m seeing is just Docker’s default behavior of showing container processes in the host’s ps output, but they’re actually isolated.

1. Files of running programs can be deleted while the program is running. If the program were trying to hide itself, it would have deleted /tmp/.XIN-unix/javae after it started. The nonexistence of the file is not a reliable source of information for confirming that the container was not escaped.

2. ps shows program-controlled command lines. Any program can change what gets displayed here, including the program name and arguments. If the program were trying to hide itself, it would change this to display `login -fp ubuntu` instead. This is not a reliable source of information for diagnosing problems.

It is good to verify the systemd units and crontab, and since this malware is so obvious, it probably isn't doing these two hiding methods, but information-stealing malware might not be detected by these methods alone.

Later, the article says "Write your own Dockerfiles" and gives one piece of useless advice (using USER root does not affect your container's security posture) and two pieces of good advice that don't have anything to do with writing your own Dockerfiles. "Write your own Dockerfiles" is not useful security advice.

I noticed this, because Hetzner forwarded me an email from the German government agency for IT security (BSI) that must have scanned all German based IP addresses for this Next.js vulnerability. It was a table of IP addresses and associated CVEs.

Great service from their side, and a lot of thanks to the German tax payers wo fund my free vulnerability scans ;)

Assume that the malware has replaced system commands, possibly used a kernel vulnerability to lie to you to hide its presence, so do not do anything in the infected system directly ?

  /tmp/.XIN-unix/javae &
  rm /tmp/.XIN-unix/javae

[*] https://aws.amazon.com/inspector/pricing/

It highlighted the domain: 'jakesaunders.dev' in the address bar in red text.

Also could prevent something to exfiltrate sensitive data.

Even if you are an owasp member who reads daily vulnerability reports, it's so easy to think you are unaffected.

At least that's what I think happened because I never found out exactly how it was compromised.

The miner was running as root and it's file was even hidden when I was running ls ! So I didn't understand what was happening, it was only after restarting my VPS from with a rescue image, and after mounting the root filesystem, that I found out the file I was seeing in the processes list did indeed exist.

It has since been fixed: Lesson learned.

And for basic web sites, it's much better if it requires no back-end.

Every service exposed increases risk and requires additional vigilance to maintain. Which means more effort.

I know we aren't supposed to rely on containers as a security boundary, but it sure is great hearing stories like this where the hack doesn't escape the container. The more obstacles the better I guess.

But I am interested in the monero aspect here.

Should I treat this as some datapoint on monero’s security having held up well so far?

You have to define a firewall policy and attach it to the VM.

Docker will overwrite your rules when you publish ports.

Do not publish ports with docker. Do not run internal services on the publicly accessible system.

And isn’t it a design flaw if you can see all processes from inside a container? This could provide useful information for escaping it.

b) if you want to limit your hosting environment to only the language/program you expect to run you should provision with unikernels which enforce it

Is there ever a reason someone should run a docker container as root ?

js scripts running on frameworks running inside containers

PS so I see the host ended up staying uncompromised

Unless ran as root this could return file not found because of missing permissions, and not just because the file doesn't actually exist, right?

> “I don’t use X” doesn’t mean your dependencies don’t use X

That is beyond obvious, and I don't understand how anyone would feel safe from reading about a CVE on a widely used technology when they run dozens of containers on their server. I have docker containers and as soon as I read the article I went and checked because I have no idea what technology most are built with.

> No more Umami. I’m salty. The CVE was disclosed, they patched it, but I’m not running Next.js-based analytics anymore.

Nonsensical reaction.