I got hacked: My Hetzner server started mining Monero

https://blog.jakesaunders.dev/my-server-started-mining-monero-this-morning/

606 410 7 months ago

blog.jakesaunders.dev

guerrilla• 7 months ago

Whew, load average of 0 here.

V__2• 7 months ago

The Reddit post I’d seen earlier? That guy got completely owned because his container was running as root. The malware could: [...]

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?

Onavo• 7 months ago

Either docker or a kernel level exploit. With non-VM containers, you are sharing a kernel.

ronsor• 7 months ago

There would be, but a lot of docker containers are misconfigured or unnecessarily privileged, allowing for escape.

Also, if you've been compromised, you may have a rootkit that hides itself from the filesystem, so you can't be sure of a file's existence through a simple `ls` or `stat`.

miladyincontrol2• 7 months ago

but a lot of docker containers are misconfigured or unnecessarily privileged, allowing for escape

Honestly, citation needed. Very rare unless you're literally giving the container access to write to /usr/bin or other binaries the host is running, to reconfigure your entire /etc, access to sockets like docker's, or some other insane level of over reach I doubt even the least educated docker user would do.

While of course they should be scoped properly, people act like some elusive 0-day container escape will get used on their minecraft server or personal blog that has otherwise sane mounts, non-admin capabilities, etc. You arent that special.

TheRealPomax• 7 months ago

Docker containers with root have rootish rights on the host machine too because the userid will just be 0 for both. So if you have, say, a bind mount that you play fast and loose with, the docker user can create 0777 files outside the docker container, and now we're almost done. Even worse if "just to make it work" someone runs the container with --privileged and then makes the terminal mistake of exposing that container to the internet.

V__2• 7 months ago

Can you explain this a bit further? Wouldn't that 0777 file outside docker be still executed inside the container and not on the host?

Havoc• 7 months ago

I think a root container can talk to docker daemon and launch additional containers...with volume mounts of additional parts of file system etc. Not particularly confident about that one though

minitech5• 7 months ago

Unintentional vulnerabilities in Docker and the kernel aside, it can only do that if it has access to the Docker API (usually through a bind mount of the Unix socket). Having access to the Docker API is equivalent to having root on the host.

d4mi3n2• 7 months ago

While this is true, the general security stance on this is: Docker is not a security boundary. You should not treat it like one. It will only give you _process level_ isolation. If you want something with better security guarantees, you can use a full VM (KVM/QEMU), something like gVisor[1] to limit the attack surface of a containerized process, or something like Firecracker[2] which is designed for multi-tenancy.

The core of the problem here is that process isolation doesn't save you from whole classes of attack vectors or misconfigurations that open you up to nasty surprises. Docker is great, just don't think of it as a sandbox to run untrusted code.

1. https://gvisor.dev/

2. https://firecracker-microvm.github.io/

socalgal2• 7 months ago

that's a really good point .. but, I think 99% of docker users believe it is a a sandbox and treat it as such.

hsbauauvhabzb3• 7 months ago

Virtual machines are treated as a security boundary despite the fact that with enough R&D they are not. Hosting minecraft servers in virtual machines is fine, but not a great idea if they’re cohosted on a machine that has billions of dollars in crypto or military secrets.

Docker is pretty much the same but supposedly more flimsy.

Both have non-obvious configuration weaknesses that can lead to escapes.

tgsovlerkhgsel9• 7 months ago

I hear the "Docker is not a security boundary." mantra all the time, and IIRC it was the official stance of the Docker project a long time ago, but is this really true?

Of course if you have a kernel exploit you'd be able to break out (this is what gvisor mitigates to some extent), nothing seems to really protect against rowhammer/memory timing style attacks (but they don't seem to be commonly used). Beyond this, the main misconfigurations seem to be too wide volume bindings (e.g. something that allows access to the docker control socket from inside the container, or an obviously stupid mount like mounting your root inside the container).

Am I missing something?

michaelt• 7 months ago

Firstly, the attacker just wants to mine Monero with CPU, they can do that inside the container.

Second, even if your Docker container is configured properly, the attacker gets to call themselves root and talk to the kernel. It's a security boundary, sure, but it's not as battle-tested as the isolation of not being root, or the isolation between VMs.

Thirdly, in the stock configuration processes inside a docker container can use loads of RAM (causing random things to get swapped to disk or OOM killed), can consume lots of CPU, and can fill your disk up. If you consider denial-of-service an attack, there you are.

Fourthly, there are a bunch of settings that disable the security boundary, and a lot of guides online will tell you to use them. Doing something in Docker that needs to access hot-plugged webcams? Hmm, it's not working unless I set --privileged - oops, there goes the security boundary. Trying to attach a debugger while developing and you set CAP_SYS_PTRACE? Bypasses the security boundary. Things like that.

Nextgrid3• 7 months ago

Container escapes exist. Now the question is whether the attacker has exploited it or not, and what the risk is.

Are you holding millions of dollars in crypto/sensitive data? Better assume the machine and data is compromised and plan accordingly.

Is this your toy server for some low-value things where nothing bad can happen besides a bit of embarrassment even if you do get hit by a container escape zero-day? You're probably fine.

This attack is just a large-scale automated attack designed to mine cryptocurrency; it's unlikely any human ever actually logged into your server. So cleaning up the container is most likely fine.

trhway• 7 months ago

there still would need to be a vulnerability in docker for it to “attack” the host, or am I missing something?

non necessary vulnerability per. se. Bridged adapter for example lets you do a lot - few years ago there were a story of something like how a guy got a root in container and because the container used bridged adapter he was able to intercept traffic of an account info updates on GCP

easterncalculus• 7 months ago

If the container is running in privileged mode you can just talk to the docker socket to the daemon on the host, spawn a new container with direct access to the root filesystem, and then change anything you want as root.

CGamesPlay2• 7 months ago

Notably, if you run docker-in-docker, Docker is probably not a security boundary. Try this inside any dind container (especially devcontainers): docker run -it --rm --pid=host --privileged -v /:/mnt alpine sh

I disagree with other commenters here that Docker is not a security boundary. It's a fine one, as long as you don't disable the boundary, which is as easy as running a container with `--privileged`. I wrote about secure alternatives for devcontainers here: https://cgamesplay.com/recipes/devcontainers/#docker-in-devc...

cyphar3• 7 months ago

You really need to use user namespaces to get this kind of security protection -- running as root inside a container without user namespaces is not secure. Yes, breakouts often require some other bug or misconfiguration but the margin for error is non-existent (for instance, if you add CAP_SYS_PTRACE to your containers it is trivial to break out of them and container runtimes have no way of protecting against that). Almost all container breakouts in the past decade were blocked by user namespaces.

Unfortunately, user namespaces are still not the default configuration with Docker (even though the core issues that made using them painful have long since been resolved).

minitech5• 7 months ago

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.

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

This article’s LLM writing style is painful, and it’s full of misinformation (is Puppeteer even involved in the vulnerability?).

jakelsaunders949• 7 months ago

Yeah fair, I asked claude to help because honestly this was a little beyond my writing skills. I'm real though. Sorry. Will change

seafoamteal• 7 months ago

Hi Jake! Cool article, and it's something I'll keep in mind when I start giving my self-hosted setup a remodel soon. That said, I have to agree with the parent comment and say that the LLM writing style dulled what would otherwise have been a lovely sysadmin detective work article and didn't make me want to explore your site further.

I'm glad you're up to writing more of your own posts, though! I'm right there with you that writing is difficult, and I've definitely got some posts on similar topics up on my site that are overly long and meandering and not quite good, but that's fine because eventually once I write enough they'll hopefully get better.

Here's hoping I'll read more from you soon!

sincerely• 7 months ago

Just a data point - I would rather read bad human writing than LLM output

minitech5• 7 months ago

Seconding what others have said about preferring to read bad human writing. And I don’t want to pick on you – this is a broadly applicable message prompted by a drop in the bucket – but please don’t publish articles beyond your ability to fact check. Just write what you actually know, and when you’re making a guess or you still have open questions at the end of your investigation, be honest about that. (People make mistakes all the time anyway, but we’re in an age where confident and detailed mistakes have become especially accessible.)

croemer4• 7 months ago

It still says Puppeteer in multiple places.

jakelsaunders949• 7 months ago

I fixed it, apologies for the misinformation.

Eduard• 7 months ago

I still see Puppeteer mentioned several times in your post and don't understand what that has to do with Umami, nextjs, and/or CVE-2025-66478.

3np10• 7 months ago

It still says:

IT NEVER ESCAPED.

You haven't confirmed this (at least from the contents of the article). You did some reasonable spot checks and confirmed/corrected your understanding of the setup. I'd agree that it looks likely that it did not escape or gain persistence on your host but in no way have you actually verified this. If it were me I'd still wipe the host and set up everything from scratch again[0].

Also your part about the container user not being root is still misinformed and/or misleading. The user inside the container, the container runtime user, and whether container is privileged are three different things that are being talked about as one.

Also, see my comment on firewall: https://news.ycombinator.com/item?id=46306974

[0]: Not necessarily drop-everything-you-do urgently but next time you get some downtime to do it calmly. Recovering like this is a good excercise anyway to make sure you can if you get a more critical situation in the future where you really need to. It will also be less time and work vs actually confirming that the host is uncontaminated.

_fqqr• 7 months ago

This article is very interesting at first but I once again get disappointed after reading clear signs of AI like "Why this matters" and "The moment of truth", and then the whole thing gets tainted with signs all over the place.

dinkleberg• 7 months ago

Yeah personally I’d much rather read a poorly constructed article with actually interesting content than the same content put into the formulaic AI voice.

venturecruelty5• 7 months ago

Article's been edited:

Edit: A few people on HN have pointed out that this article sounds a little LLM generated. That’s because it’s largely a transcript of me panicking and talking to Claude. Sorry if it reads poorly, the incident really happened though!

For what it's worth, this is not an excuse, and I still don't appreciate being fed undisclosed slop. I'm not even reading it.

zamadatix2• 7 months ago

I don't use Docker for my containers at home, but I take it by the concern that user namespacing is not the employed by them or something?

heavyset_go4• 7 months ago

If you're root in a namespace and manage to escape, you can have root privileges outside of it.

zamadatix2• 7 months ago

Are you referring to user namespaces and, if so, how does that kind of break out to host root work? I thought the whole point of user namespaces was your UID 0 inside the container is UID 100000 or whatever from the perspective of outside the container. Escaping the container shouldn't inherently grant you ability to change your actual UID in the host's main namespace in that kind of setup, but I'm not sure Docker actually leverages user namespaces or not.

E.g. on my systemd-nspawn setup with --private-users=pick (enables user namespacing) I created a container and gave it a bind mount. From the container it appears like files in the bind mount created by the container namespace's UID 0 are owned by UID 0 but from outside the container the same file looks owned by UID 100000. Inverted, files owned by the "real" UID 0 on the host look owned by 0 to the host but as owned by 65534 (i.e. "nobody") from the container's perspective. Breaking out of the container shouldn't inherently change the "actual" user of the process from 100000 to 0 any more than breaking out of the container as a non-0 UID in the first place - same as breaking out of any of the other namespaces doesn't make the "UID 0" user in the container turn into "UID 0" on the host.

j4515• 7 months ago

Never expose your server IP directly to the internet, vps or baremetal.

miramba• 7 months ago

Is there a way to do that and still be able to access the server?

Carrok• 7 months ago

Many ways. Using a "bastion host" is one option, with something like wireguard or tinc. Tailscale and similar services are another option. Tor is yet another option.

sh3rl0ck• 7 months ago

Either via a VPN or a tunnel.

iLoveOncall2• 7 months ago

Yes, CloudFlare ZeroTrust. It's entirely free, I use it for loads of containers on multiple hosts and it works perfectly.

m00x• 7 months ago

Yes, cloudflare tunnels do this, but I don't think it's really necessary for this.

I use them for self-hosting.

j4515• 7 months ago

Yes, of course.

Free way - sign up for a cloudflare account. Use the DNS on cloudflare, they wil put their public ip in front of your www.

Level 2 is install the cloudflare tunnel software on your server and you never need to use the public IP.

Backend access securely? Install Tailscale or headscale.

This should cover most web hosting scenarios. If there's additional ports or services, tools like nginx proxy manager (web based) or others can help. Some people put them on a dedicated VPS as a jump machine.

This way using the Public IP can almost be optional and locked down if needed. This is all before running a firewall on it.

procaryote• 7 months ago

As in "always run a network firewall" or "keep the IP secret"? Because I've had people suggest both and one is silly.

j4515• 7 months ago

A network firewall is mandatory.

Keeping the IP secret seems like a misnomer.

Its often possible to lock down the public IP entirely to not accept connections except what's initiated from the inside (like the cloudflare tunnel or otherwise reaching out).

Something like a Cloudflare+tunnel on one side, tailscale or something to get into it on the other.

Folks other than me have written decent tutorials that have been helpful.

mrkeen• 7 months ago

You're going to hate this thing called DNS

j4515• 7 months ago

Been running production servers for a long time.

DNS is no issue. External DNS can be handled by Cloudflare and their waf. Their DNS service can can obsfucate your public IP, or ideally not need to use it at all with a Cloudflare tunnel installed directly on the server. This is free.

Backend access trivial with Tailscale, etc.

Public IP doesn't always need to be used. You can just leave it an internal IP if you really want.

palata6• 7 months ago

Unless you need it to be reachable from the Internet, at which point it has to be... reachable from the Internet.

j4515• 7 months ago

Public facing services routed through a firewall or waf (cloudflare) always.

Backend access trivial with Tailscale, etc.

sergsoares• 7 months ago

Not expose the server IP is one practice (obfuscation) in a list of several options.

But that alone would not solve the problem being a RCE from HTTP, that is why edge proxy provider like Cloudflare[0] and Fastfy[1] proactivily added protections in his WAF products.

Even cloudflare had an outage trying to protect his customers[3].

- [0] https://blog.cloudflare.com/waf-rules-react-vulnerability/ - [1] https://www.fastly.com/blog/fastlys-proactive-protection-cri... - [2] https://blog.cloudflare.com/5-december-2025-outage/

j4515• 7 months ago

No provider is perfect - It's totally possible to run your own FW behind it, or run CF Tunnel on a separate container that routes traffic to individual application containers using something like traefik, nginx proxy manager, etc.

cortesoft3• 7 months ago

Any server? How do you run a public website? Even if you put it behind a load balancer, the load balancer is still a “server exposed to the internet”

j4515• 7 months ago

Public facing services routed through a firewall or waf (cloudflare) always.

Backend access trivial with Tailscale, etc.

Public IP never needs to be used. You can just leave it an internal IP if you really want.

iLoveOncall2• 7 months ago

ls -la /tmp/.XIN-unix/javae

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.

qingcharles4• 7 months ago

Yeah, my Umami box was hit, but the time between the CVE disclosure and my box getting smacked was incredibly low. Umami patched it very quickly. And then patched it again a second time when the second CVE dropped right after.

Nothing is immune. What analytics are you going to run? If you roll your own you'll probably leave a hole somewhere.

Hackbraten• 7 months ago

No more Umami. I’m salty.

But kudos for the word play!

grekowalski• 7 months ago

Recently, those Monero miners were installing themselves everywhere that had a vulnerable React 19. I had exactly the same problem.

qingcharles4• 7 months ago

I had to nuke my Oracle Cloud box that runs my Umami server. It got hit. Was a good excuse to upgrade version and upgrade all my backup systems etc. Lost a few hours of data while it was returning 500 errors.

tgsovlerkhgsel9• 7 months ago

I love mining malware - it's reasonably visible and causes almost no damage. Essentially, it's like a bug bounty program that you don't have to manage, doesn't generate costly bullshit reports, and only costs you a few bucks of electricity when a vulnerability is found.

If you have decent network or process level monitoring, you're likely to find it, while you might not realize the vulnerable software itself or some stealthier, more dangerous malware that might exploit it.

codegeek• 7 months ago

tl:dr: He got hacked but the damage was only restricted to one docker container runn ing Umami (that is built on top of NextJS). Thankfully, he was running the docker container as a non privileged non-root user which saved him big time considering the fact that the attack surface was limited only within the container and could not access the entire host/filesystem.

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

d4mi3n2• 7 months ago

If you're using the container to manage stuff on the host, it'll likely need to be a process running as root. I think the most common form of this is Docker-in-Docker style setups where a container is orchestrating other containers directly through the Docker socket.

wnevets8• 7 months ago

Sure does seem like the primary outcome of cryptocurrencies being released onto the world has been criminals making money.

dylan6042• 7 months ago

Is that really a surprise though?

venturecruelty5• 7 months ago

Not for anyone who doesn't have a financial stake in said fraud, no.

nrhrjrjrjtntbt• 7 months ago

And fast malware detection.

BLKNSLVR3• 7 months ago

Criminals and the porn industry are almost invariably early adopters of new technologies. For better or worse their use-cases are proof-of-concepts that get expanded and built on, if successful, by more legitimate industries.

Re: the Internet.

Re: Peer-to-peer.

Re: Video streaming.

Re: AI.

lapetitejort• 7 months ago

What is the average length of time for new tech to escape porn and crime and integrate into real applications? Longer than 15 years?

denismenace• 7 months ago

How were criminals the early adopters of Internet, Video streaming and AI?

akimbostrawman9• 7 months ago

Sure does seem like the primary outcome of email being released onto the world has been criminals making money.

wnevets8• 7 months ago

Absolutely not.

burnerRhodov2• 7 months ago

Well, because crypto has been a crime for it's entire lifetime. Any of my friends who got funding to work on crypto got debanked, fined, jail time etc. Throughout the entire Obama-Biden era. Only under the latest Trump admin are there new VC funding and things like ETF's, stablecoin settlements, and crossborder regulation being "Accepted" even though we have no legal framework.

So... Crypto is illegal so anyone using is defacto a criminal by definition.

Also, for this particular instance this is the best bug bounty program i've ever seen. Running a monero node that hits your daily budget cap is not that bad... It could be way worse like steal you DB creditials and sell it to the highest party... So, crypto actually made this better.

tgsovlerkhgsel9• 7 months ago

I'd argue mining malware is a net benefit to society. I'd much rather have my vulnerable server exploited by mining malware than left alone. If it gets exploited by mining malware, it gives me an extra chance to catch it before something actually bad happens, at almost zero cost to myself and a small reward for the person who found the vuln.

meisel• 7 months ago

Is mining via CPU even worthwhile for the hackers? I thought ASICs dominated mining

jsheard2• 7 months ago

ASICs do dominate Bitcoin mining but Monero's POW algorithm is supposed to be ASIC resistant. Besides, who cares if it's efficient when it's someone else's server?

minitech5• 7 months ago

Hard for it not to be worthwhile, since it’s free for them. Same automated exploit run across the entire internet.

Bender• 7 months ago

Optimal hardware costs money. Easy to hack machines are free and in nearly unlimited numbers.

justinsaccount• 7 months ago

If the effectiveness of mining is represented as profit divided by the cost of running the infrastructure, then a CPU that someone else is paying for is worth it as long as the profit is greater than zero.

heavyset_go4• 7 months ago

Yes, for Monero it is the only real viable option. I'd also assume that the OP's instance is one of many other victims whose total mining might add up to a significant amount of crypto.

edm0nd• 7 months ago

Its easily worth it as they are not spending any money on compute or power.

If they can enslave 100s or even 1000s of machine mining XMR for them, easy money if you set aside the legality of it.

tgtweak7• 7 months ago

Monero's proof of work (RandomX) is very asic-resistant and although it generates a very small amount of earnings, if you exploit a vulnerability like this with thousands or tens of thousands of nodes, it can add up (8 modern cores 24/7 on Monero would be in the 10-20c/day per node range). OPs Vps probably generated about $1 for those script kiddies.

pixl97• 7 months ago

Hit 1000 servers and it starts adding up. Especially if you live somewhere with a low cost of living.

asdff• 7 months ago

So $40 a year? Does that imply all monero is mined like this because it's clearly not cost effective at all to mine legitimately?

rnhmjoj• 7 months ago

This is the PoW scheme that Monero currently uses:

RandomX utilizes a virtual machine that executes programs in a special instruction set that consists of integer math, floating point math and branches. These programs can be translated into the CPU's native machine code on the fly (example: program.asm). At the end, the outputs of the executed programs are consolidated into a 256-bit result using a cryptographic hashing function (Blake2b).

I doubt that you anyone managed to create an ASIC that does this more efficiently and cost effective than a basic CPU. So, no, probably no one is mining Monero using an ASIC.

nikanj3• 7 months ago

When your cost per host is $0, even $5 / mo / hacked host profit can make for an ok business

tolerance• 7 months ago

Was dad notified of the security breach? If not he may want to consider switching hosting providers. Dad deserves a proper LLM-free post mortem.

jakelsaunders949• 7 months ago

Hahaha, I did tell him this afternoon. This is the bloke who has the same password for all his banking apps despite me buying him 1password though. The imminent threat from RCE's just didn't land.

dylan6042• 7 months ago

Buying someone 1Pass, or the like, and calling it good is not enough. People using password managers forget how long it takes to visit all of the sites you use to create that site's record, then update the password to a secure one, and then log out and log back in with the new password to test it is good. For a lot of people having a password manager bought for them is going to be over it after the second site. Just think about how many videos on TikTok they could have been watching instead

suspended_state• 7 months ago

Careful, HN isn't your average IRC channel.

heavyset_go4• 7 months ago

I wouldn't trust that boot image or storage again, I'd nuke it for peace of mind.

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

jakelsaunders949• 7 months ago

Yeah I did consider just killing it, I'm going to keep an eye on it for a few days with a gun to it just in case.

I was lucky in that my DB backups were working so all my persistence wax backed up to S3. I think I could stand up another one in an hour.

Unfortunately I didn't keep an image no. I almost didn't have the foresight to investigate before yeeting the whole box into the sun!

muppetman• 7 months ago

Enable connection tracking (if it's not already) and keep looking at the conntrack entires. That's a good way to spot random things doing naughty stuff.

qingcharles4• 7 months ago

As an aside, if you're using a Hetzner VPS for Umami you might be over-specced. I just cut my Hetzner bill by $4/mo by moving my Umami box to one of the free Oracle Cloud VPS after someone on here pointed out the option to me. Depends whether this is a hobby thing or something more serious, but that option is there.

tgtweak7• 7 months ago

The manageability of having everything on one host is kind of nice at that scale, but yeah you can stack free tiers on various providers for less.

ianschmitz• 7 months ago

I would pay $4/mo to stay as far away from Oracle as possible

spiderfarmer• 7 months ago

I pay for Hetzner because it’s an EU based, sane company without a power hungry CEO.

mos873• 7 months ago

Orange Man Bad?!?

angulardragon032• 7 months ago

All fine and well, but oracle will threaten to turn off your instance if you don’t maintain a reasonable average CPU usage on the free hosts, and will eventually do so abruptly.

This became enough of a hassle that I stopped using them.

treesknees• 7 months ago

Do you mean if it’s idle, or if it’s maxed out? I’ve had a few relatively idle free-tier VMs with Oracle and I’ve not received any threats of shutoff over the last 3 years I’ve had them online.

qingcharles4• 7 months ago

I assumed the same, but as long as you keep a credit card on file apparently they will let you idle it too. I went in and set my max budget at $1/mo and set alerts too, just in case.

jakelsaunders949• 7 months ago

I've got a whole Hetzner EX41 bare metal server, as opposed to a VPS. It's gotr like 20 services on it.

But yeah it is massively overspecced. Makes me feel cool load testing my go backend at 8000 requests per second though!

tgtweak7• 7 months ago

Just a note - you can very much limit cpu usage on the docker containers by setting --cpus="0.5" (or cpus:0.5 in docker compose) if you expect it to be a very lightweight container, this isolation can help prevent one roudy container from hitting the rest of the system regardless of whether it's crypto-mining malware, a ddos attempt or a misbehaving service/software.

freedomben2• 7 months ago

This is true, but it's also easy to set at one point and then later introduce a bursty endpoint that ends up throttled unnecessarily. Always a good idea to be familiar with your app's performance profile but it can be easy to let that get away from you.

jakelsaunders949• 7 months ago

This is a great shout actually. Thanks for pointing it out!

fragmede2• 7 months ago

The other thing to note is that docker is for the most part, stateless. So if you're running something that has to deal with questionable user input (images and video or more importantly PDFs), is to stick it on its own VM and then cycle the docker container every hour and the VM every 12, and then still be worried about it getting hacked and leaking secrets.

tgtweak7• 7 months ago

Most of this is mitigated by running docker in an LXC containers (like proxmox does) which grants a lot more isolation than docker on it's own - closer in nature to running separate VMs.

Koffiepoeder• 7 months ago

If I can get in once, I can do it again an hour later. I'd be inclined to believe that dumb recycling is not very effective against a persistent attacker.

tracker13• 7 months ago

Another is running containers in read-only mode, assuming they support this configuration... will minimize a lot of potential attack surface.

3eb7988a1663• 7 months ago

Never looked into this. I would expect the majority of images would fail in this configuration. Or am I unduly pessimistic?

miladyincontrol2• 7 months ago

Soft and hard memory limits are worth considering too, regardless of container method.

moebrowne• 7 months ago

While this is a good idea I wonder if doing this could allow the intrusion to go undetected for longer - how many people/monitoring systems would notice a small increase in CPU usage compared to all CPUs being maxed out.

venturecruelty5• 7 months ago

I still can't believe that there are so many people out here popping boxen and all they do is solve drug sudokus with the hardware. Hacks are so lame now.

ryanto• 7 months ago

Sorry to hear you got hacked.

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.

DANmode• 7 months ago

Hacks are humans. For like, ten more minutes anyway.

If the human involved can’t escalate, the hack can’t.

pigbearpig• 7 months ago

You might want to harden that those outbound firewall rules as another step. Did the Umami container need the ability to initiate connections? If not, that would eliminate the ability to do the outbound scans.

Also could prevent something to exfiltrate sensitive data.

danparsonson4• 7 months ago

No firewall! Wow that's brave. Hetzner will let you configure one that runs outside of the box so you might want to add that too, as part of your defense in depth - that will cover you if you make a mistake with ufw. Personally I keep SSH firewalled only to my home address in this way; if I'm out and about and need access, I can just log into Hetzner's website and change it temporarily.

Nextgrid3• 7 months ago

But the firewall wouldn't have saved them if they're running a public web service or need to interact with external services.

I guess you can have the appserver fully firewalled and have another bastion host acting as an HTTP proxy, both for inbound as well as outbound connections. But it's not trivial to set up especially for the outbound scenario.

danparsonson4• 7 months ago

No you're right, I didn't mean the firewall would have saved them, but just as a general point of advice. And yes a second VPS running opnSense or similar makes a nice cheap proxy and then you can firewall off the main server completely. Although that wouldn't have saved them either - they'd still need to forward HTTP/S to the main box.

jwrallie• 7 months ago

Password auth being enabled is also very brave. I don’t think fail2ban is necessary personally, but it’s popular enough that it always come up.

tete• 7 months ago

Firewalls in the majority of cases don't get you much. Yes it's a last line of defense if you do something really stupid and don't even know where or what you configure your services to listen on, but if you don't the difference between running firewalls and not is minuscule.

There are way more important things like actually knowing that you are running software with widely known RCE that don't even use established mechanisms to sandbox themselves it seems.

The way the author describes docker being the savior appears to be sheer luck.

danparsonson4• 7 months ago

The author mentioned they had other services exposed to the internet (Postgres, RabbitMQ) which increases their attack surface area. There may be vulnerabilities or misconfigurations in those services for example.

Good security is layered.

monster_truck• 7 months ago

extremely loud incorrect buzzer noise, what are you going to say next "bastion servers are a scam"

3abiton2• 7 months ago

Honestly fail2ban is amazing. I might doa write up on the countless of attempts on my servers.

dizhn6• 7 months ago

The only way I've envisioned fail2ban to be of any use at all is if you gather IPs from one server and use them on your whole fleet and I got it running like this for a while. Ultimately I decided that all it does is give you a cleaner log file since by definition its working on logs for attacks/attempts that did not succeed. We need to stop worrying about attempts we see in the logs and let software do its job.

figassis2• 7 months ago

Yup. All my servers are behind Tailscale. The only thing I expose is a load balancer that routes tcp (email) and http. That balancer is running docker, fully firewalled (incl docker bypasses). Every server is behind herzner’s firewall in addition to the internal firewall.

App servers run docker, with images that run a single executable (no os, no shell), strict cpu and memory limits. Most of my apps only require very limited temporary storage so usually no need to mount anything. So good luck executing anything in there.

I used, way back in the day, to run Wordpress sites. Would get hacked monthly every possible way. Learned so much, including the fact that often your app is your threat. With Wordpress, every plugin is a vector. Also the ability to easily hop into an instance and rewrite running code (looking at you scripting languages incl JS) is terrible. This motivated my move to Go. The code I compiled is what will run. Period.

dizhn6• 7 months ago

I have SSH blocked altogether and use wireguard to access the server. If something goes wrong I can always go to the dashboard and reenable SSH for my IP. But ultimately your setup is just as secure. Perhaps a tiny bit less convenient.

danw19792• 7 months ago

The only time I have ever had a machine compromised in 30 years of running Linux is when I ran something exposed to the internet on a well known port.

I know port scanners are a thing but the act of using non-default ports seems unreasonably effective at preventing most security problems.

jraph• 7 months ago

I do this too, but I think it should only be a defense in depth thing, you still need the other measures.

rainonmoon• 7 months ago

This is very, very, very bad advice. A non-standard port is not a defence. It’s not even slightly a defence.

tonyplee• 7 months ago

If you do any npm install, pip install ..., docker pull ... / docker run ... , etc in linux. It is very easy to get compromise.

I did docker pull a few times base on some webpost (looks reasonable) and detect app/scripts from inside the docker connect to some .ru sites immediately or a few days later....

oakhaven• 7 months ago

I don't whitelist IPs for ssh anymore, but I always run sshd on randomly selected port, in order to not get noticed by port scanners.

I do it for a really long time already, and until now I am not sure if it has any benefit or it's just umbrella in a sideways storm.

lordnacho• 7 months ago

As long as you understand it's security by obscurity, rather than by cryptography.

I don't think it's wrong, it's just not the same as eg using a yubikey.

forbiddenlake• 7 months ago

This won't hide you completely, but it will reduce log spam.

My sshd only listens on the VPN interface

xetera• 7 months ago

For the record this is only available for their VPS offering and not dedis. If you rent a dedi through their server auction you still need to configure your own firewall.

danparsonson4• 7 months ago

Dedicated servers can configure external firewalls too; there's a tab for it on the server config. It's basic but functional.

OutOfHere2• 7 months ago

You're lucky that Hetzner didn't delete your server and terminate your account.

croemer4• 7 months ago

With which justification?

OutOfHere2• 7 months ago

Cryptocurrency software usage. It is strictly against their policy. Afaik, their policy does not differentiate with voluntary and involuntary use.

They have done it to others.

mythrwy• 7 months ago

If they do that they don't get paid for the service the subsequent month.

nodesocket• 7 months ago

I also run Umami, but patched once the CVE patch was released. Also, I only expose the tracking js endpoint and /api/send via Caddy publically (though, /api/send might be enough to exploit the vul). To actually interact with Umami UI I use Twingate (similar to Tailscale) to tunnel into the VPC locally.

Computer0• 7 months ago

Still confused what I am supposed to do to avoid all this.

movedx2• 7 months ago

Learning to manage an operating system in full, and having a healthy amount of paranoia, is a good first step.

doublerabbit2• 7 months ago

Then, write all your own software to please the paranoia for the next 15 years.

Next year is the 5th year of my current personal project. Ten to go.

nikanj3• 7 months ago

Host your personal blog on wordpress.com or similar

seymon• 7 months ago

What's considered nowadays the best practice (in terms of security) for running selfhosted workloads with containers? Daemon less, unprivileged podman containers?

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

movedx2• 7 months ago

You’ll set yourself up for success if you check the dependencies of anything you run, regardless of it being containerised. Use something like Snyk to scan containers and repositories for known exploits and see if anything stands out.

Then you need to run things with as least privilege as possible. Sadly, Docker and containers in general are an anti-pattern here because they’re about convenience first, security second. So the OP should have run the contains as read-only with tight resource limits and ideally IP restrictions on access if it’s not a public service.

Another thing you can do is use Tailscale, or something like it, to keep things being a zero trust, encrypted, access model. Not suitable for public services of course.

And a whole host of other things.

elric• 7 months ago

As always: never run containers as root. Never expose ports to the internet unless needed. Never give containers outbound internet access. Run containers that you trust and understand, and not random garbage you find on the internet that ships with ancient vulnerabilities and a full suite of tools. Audit your containers, scan them for vulnerabilities, and nuke them from orbit on the regular.

Easier said than done, I know.

Podman makes it easier to be more secure by default than Docker. OpenShift does too, but that's probably taking things too far for a simple self hosted app.

3np10• 7 months ago

I also enabled UFW (which I should have done ages ago)

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

Configuration is backed by xml files in /etc/firewalld and /usr/lib/firewalld instead of the brittle pile of sticks that is the ufw rules files. Use the nftables backend unless you have your own reasons for needing legacy iptables.

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.

exceptione7• 7 months ago

  > Specifically for docker it is a very common gotcha that the container runtime can and will bypass firewall rules and open ports anyway.

Like I said in another comment, drop Docker, install podman.

3np10• 7 months ago

This affects podman too.

figassis2• 7 months ago

In docker, simply clearly define the interface (ip) and port. It can be 0.0.0.0:80 for example. No bypass happens.

dns_snek• 7 months ago

podman is not a drop-in replacement for Docker. You can replace it with podman but expect to encounter minor inconsistencies and some major differences, especially if you use Docker Compose or you want to use podman in rootless mode. It's far from just being a matter of `alias docker=podman`.

The only non-deprecated way of having your Compose services restart automatically is with Quadlet files which are systemd unit files with extra options specific to containers. You need to manually translate your docker-compose.yml into one or more Quadlet files. Documentation for those leaves a lot to be desired too, it's just one huge itemized man page.

kh_hk3• 7 months ago

I keep reading comments by podman fans asking to drop Docker and yet every time I have tried to use podman it failed on me miserably. IMHO it would be better if podman was not designed and sold as a docker drop in replacement but its own thing.

newsoftheday8• 7 months ago

No, I'm happy with Docker, Docker works very well.

newsoftheday8• 7 months ago

Nothing in the article talked about podman or podman vs docker. Umami with its NexJS and React CVE vulnerability was the issue. BTW, I use Docker because it works extremely well and because there is so much astroturfing from the podman gang I wouldn't use it if my life depended on it until that shit calms down.

denkmoon2• 7 months ago

I’ll just mention Foomuuri here. Its bit of a spiritual successor to shorewall and has firewalld emulation to work with tools compatible with firewalld

3np10• 7 months ago

Thanks! Would be cool to have it packaged for alpine since firewalld requires D-Bus. There is awall but that's still on iptables and IMO at bit clunky to set up.

egberts13• 7 months ago

Foomuuri is ALMOST there.

I mean there are some payload over payload like GRE VPE/VXLAN/VLAN or IPSec that needs to be written in raw nft if using Foomuuni but it works!.

But I love the Shorewall approach and your configuration gracefully encapsulated Shorewall mechanic.

Disclaimer: I maintain vim-syntax-nftables syntax highlighter repo at Github.

lloydatkinson• 7 months ago

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.

This sounds like great news. I followed some of the open issues about this on GitHub and it never really got a satisfactory fix. I found some previous threads on this "StrictForwardPorts": https://news.ycombinator.com/item?id=42603136.

gus_3• 7 months ago

it doesn't matter what netfilter frontend you use if you allow outbound connections from any binary.

In order to stop these attacks, restrict outbound connections from unknown / not allowed binaries.

This kind of malware in particular requires outbound connections to the mining pools. Others downloads scripts or binaries from remote servers, or try to communicate with their c2c servers.

On the other hand, removing exec permissions to /tmp, /var/tmp and /dev/shm is also useful.

3abiton2• 7 months ago

Is there an automated way of doing this?

crote2• 7 months ago

It is really unfortunate that a lot of services expect to have write access to their config files, so you can tweak settings with a web UI.

If this weren't the case, plenty of containers could probably have a fully read-only filesystem.

Aeolun• 7 months ago

Wasn’t there that npm malware thing a while ago that trashed your home folder if it couldn’t phone home?

bostik2• 7 months ago

On the other hand, removing exec permissions to /tmp, /var/tmp and /dev/shm is also useful.

Sadly that's more of a duck tape or plaster, because any serious malware will launch their scripts with the proper '/bin/bash /path/to/dropped/payload' invocation. A non-exec mount works reasonably well only against actual binaries dropped into the paths, because it's much less common to launch them with the less known '/bin/ld.so /path/to/my/binary' stanza.

I've also at one time suggested that Debian installer should support configuring a read-only mount for /tmp, but got rejected. Too many packaging scripts depend on being able to run their various steps from /tmp (or more correctly, $TMPDIR).

rglover• 7 months ago

One of those rare HN comments that's just pure gold.

newsoftheday8• 7 months ago

The don't use ufw but use firewalld comment? I disagree. I've used ufw since 2006 and have no plans to change. Works great.

Ey7NFZ3P0nzAe• 7 months ago

You might be interested in ufw-docker: https://github.com/chaifeng/ufw-docker

skirge• 7 months ago

also docker bypasses ufw

sph• 7 months ago

The problem with firewalld is that it has the worst UX of any program I know. Completely unintuitive options, the program itself doesn’t provide any useful help or hint if you get anything wrong and the documentation is so awful you have to consult the Red Hat manuals that have thankfully been written for those companies that pay thousands per month in support.

It’s not like iptables was any better, but it was more intuitive as it spoke about IPs and ports, not high-level arbitrary constructs such as zones and services defined in some XML file. And since firewalld uses iptables/nftables underneath, I wonder why do I need a worse leaky abstraction on top of what I already know.

I truly hate firewalld.

bingo-bongo2• 7 months ago

Coming from FreeBSD and pf, all Linux firewalls I’ve tried feels clunky _at best_ UX-wise.

I’d love a Linux firewall configured with a sane config file and I think BSD really nailed it. It’s easy to configure and still human readable, even for more advanced firewall gateway setups with many interfaces/zones.

A have no doubt that Linux can do all the same stuff feature-wise, but oh god the UX :/

ps2• 7 months ago

Hate it as well. Why should I bother learning about zones and abstract away ports, adresses, interfaces etc. only to find out pretty soon that my baremetal server actually always needs fine grained rules at least from the firewalld's point of view.

dizhn6• 7 months ago

If you can, do not expose ports like this 8080:8080, but do this "192.168.0.1:8080:8080" so its bound to a private IP. Then use any old method expose only what you want to the world.

In my own use I have 10.0.10.11 on the vm that I host docker stuff. It doesn't even have its own public IP meaning I could actually expose to 0.0.0.0 if I wanted to but things might change in the future so it's a precaution. That IP is only accessible via wireguard and by the other machines that share the same subnet so reverse proxying with caddy on a public IP is super easy.

zwnow2• 7 months ago

Yup the regular "8080:8080" bind resulted in a ransom note in my database on day 1. Bound it to localhost only now.

andix3• 7 months ago

It's really a trap. I'm surprised they never changed the default to 127.0.0.1 instead of 0.0.0.0. So you would need to explicitly specify it, if you want to bind to all interfaces.

PeterStuer• 7 months ago

Hetzner has a free firewall service outside of your machine. You can use that as the first line of defence.

reddalo• 7 months ago

That's what I use. Is it enough? Or should I also install a firewall on my machine?

nvarsj• 7 months ago

The problem with Hetzner's firewall service is it nukes network performance especially on ipv6.

newsoftheday8• 7 months ago

It's a good idea. At OCI, I have the VCN firewall enabled and ufw firewall enabled within my VPS's.

peanut-walrus• 7 months ago

Personally I find just using nftables.conf straightforward enough that I don't really understand the need for anything additional. With iptables, it was painful, but iptables has been deprecated for a while now.

DaSHacka2• 7 months ago

Same here, I'm surprised most linux users I know like to install firewalld, UFW, or some other overlaying firewall rather than just editing the nftables config directly. It's not very difficult, although I've never really dug deep into the weeds of iptables. I suspect many people who have used iptables long ago in the past assume nftables is samilar and avoid interacting with it directly out of habit.

crote2• 7 months ago

Do either of them work for container-to-container traffic?

Imagine container A which exposes tightly-coupled services X and Y. Container B should be able to access only X, container C should be able to accesd only Y.

For some reason there just isn't a convenient way to do this with Docker or Podman. Last time I looked into it, it required having to manually juggle the IP addressed assigned to the container and having the service explicitly bind to it - which is just needlessly complicated. Can firewalls solve this?

itintheory• 7 months ago

I can't answer your question about Docker or Podman, but in Kubernetes there is the NetworkPolicy API which is designed for exactly this use-case. I'm sure it uses Linux native tooling (iptables, nftables, etc) under the hood, so it's at least within the real of feasible that those tools can be used for this purpose.

kunley• 7 months ago

..backed by xml?

arminiusreturns2• 7 months ago

UFW and Firewall-CMD both just use iptables in that context though. The real upgrade is in switching to nftables. I know I'm going to need to learn eBpf as the next step too, but for now nftables is readable and easy to grok especially after you rip out the iptables stuff, but technically nftables is still using netfilter.

And ufw supports nftables btw. I think the real lesson is write your own firewalls and make them non-permissive - then just template that shit with CaC.

arminiusreturns2• 7 months ago

edit* Apparently because I haven't used firewall-cmd in a long time, I was wrong on this: firewall-cmd does indeed use nftables by default.

mort96• 7 months ago

I strongly disagree, firewall-cmd is way too complicated. I mean it's probably fine if your main job is being a firewall administrator, but for us who just need to punch a hole in a firewall as a tiny necessary prerequisite for what we actually want to do, it's just too much.

On ufw systems, I know what to do: if a port I need open is blocked, I run 'ufw allow'. It's dead simple, even I can remember it. And if I don't, I run 'ufw --help' and it tells me to run 'ufw allow'.

Firewall-cmd though? Any time I need to punch a hole in the firewall on a Fedora system, I spend way too long reading the extremely over-complicated output of 'firewall-cmd --help' and the monstrous man page, before I eventually give up and run 'sudo systemctl disable --now firewalld'. This has happened multiple times.

If firewalld/firewall-cmd works for you, great. But I think it's an absolutely terrible solution for anyone whose needs are, "default deny all incoming traffic, open these specific ports, on this computer". And it's wild that it's the default firewall on Fedora Workstation.

newsoftheday8• 7 months ago

I've not used firewalld but I have used ufw on my desktops and servers going back to 2006 and can guarantee I have no plans to change from it.

arein32• 7 months ago

Does it have a gui?

lofaszvanitt• 7 months ago

Why people use these abstractions over nftables? Use nftables, it's easy to learn, effective and if you know it you know everything about firewalls.

marwamc2• 7 months ago

Hahaha OP could be in deep trouble depending on what types of creds/data they had in that container. I had replied to a child comment but I figure best to reply to OP.

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.

jakelsaunders949• 7 months ago

Nothing in that container luckily, just what Umami needed to run, so no creds at all. Thanks for the info though!

cobertos• 7 months ago

Luckily umami in docker is pretty compartimentalized. All data is in the and the DB runs in another container. The biggest thing is the DB credentials. The default config requires no volume mounts so no worries there. It runs unprivileged with no extra capabilities. IIRC don't think the container even has bash, a few of the exploits that tried to run weren't able to due to lack of bash in the scripts they ran.

Deleting and remaking the container will blow away all state associated with it. So there isn't a whole lot to worry about after you do that.

simulator5g• 7 months ago

You could just chain this with another exploit, just because it doesn’t run as root by default doesn’t mean it’s not a big deal.

hoppp2• 7 months ago

This nextjs vulnerability is gonna be exploited everywhere because its so easy. This is just the start

christophilus• 7 months ago

I didn’t think it was possible for me to dislike nextjs any more, but here we are. It’s the Sharepoint of the JS ecosystem.

exceptione7• 7 months ago

The first step I would take is running podman instead of Docker to prevent container escapes. Podman can be run truly rootless and doesn't mess with your firewall. Next I would drop all caps if possible.

doodlesdev• 7 months ago

What's the difference between running Podman and running Docker in rootless mode? (Other than Docker messing with the firewall, which apparently OP doesn't know about… yet). I understand Podman doesn't require a daemon, but is that all there is to it, or is there something I'm missing?

exceptione7• 7 months ago

The runtime has been designed from the ground up to be run daemonless and rootless. They also have a K8s runtime, that has an extremely small surface, just enough to be K8s compliant.

But podman has also great integration with systemd. With that you could use a socket activated systemd unit, and stick the socket inside the container, instead of giving the container any network at all. And even if you want networking in the container, the podman folks developed slirp4netns, which is user space networking, and now something even better: passt/pasta.

crimsonnoodle58• 7 months ago

Rootless docker is more compatible than podman I found. I experienced crash dumps in say mssql with podman, but not with rootless docker.

Also rootless docker does not bypass ufw like rootful docker does.

hughw• 7 months ago

You can run Docker Scout on one repo for free, and that would alert you that something was using Next.js and had that CVE. AWS ECR has pretty affordable scanning too: 9 cents/image and 1 cent/rescan. Continuous scanning even for these home projects might be worth it.

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

xp84• 7 months ago

I wonder in a case like this how hard it would be to "steal" the crypto that you've paid to mine. But I assume these people are probably smart enough to where everything is instantly forwarded to their C&C server to prevent that.

akimbostrawman9• 7 months ago

Unless you know the wallets seed phrase you can not access the mined funds. At best you could replace there wallet with your own to mine it yourself.

tgsovlerkhgsel9• 7 months ago

There is no need for the node doing the mining calculations to have access to the private key of the payout wallet.

croemer4• 7 months ago

Not proof read by a human. It claims more than once the vulnerability was related to Puppeteer. Hallucination!

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

loloquwowndueo2• 7 months ago

TFA mentions it’s mostly a transcript of a Claude session literally in the first paragraph.

themafia• 7 months ago

That was added as an edit. It does not cover the inaccuracies contained within. It should more realistically say "this article was generated by an LLM and may contain several errors which I didn't bother to find or correct."

croemer4• 7 months ago

That doesn't excuse publishing errors.

egberts13• 7 months ago

This Monero mining also happened with one of my VPS over at interserv.net, when I forgot to log out of the root console in web-based terminal console to one of my VPS and closed its browser tab instead.

It has since been fixed: Lesson learned.

tgsovlerkhgsel9• 7 months ago

when I forgot to log out of the root console in web-based terminal console to one of my VPS and closed its browser tab instead.

This should not enable the compromise of your session, i.e. either there was some additional vulnerability (and not logging out widened the window during which it could be exploited), or the attack was totally unrelated. Either way, you should find out the real cause.

egberts13• 7 months ago

And they did.

zrn900• 7 months ago

Just use Hetzner managed servers? Very high specs, they manage everything, and you can install a lot of languages, apps etc.

kopirgan2• 7 months ago

Only lesson seems to be use ufw! (or equivalent)

scottyeager• 7 months ago

As others have mentioned, a firewall might have been useful in restricting outbound connections to limit the usefulness of the machine to the hacker after the breach.

An inbound firewall can only help protect services that aren't meant to be reachable on the public internet. This service was exposed to the internet intentionally so a firewall wouldn't have helped avoid the breach.

The lesson to me is that keeping up with security updates helps prevent publicly exposed services from getting hacked.

kopirgan2• 7 months ago

Yes thanks for the clarification.

eyberg• 7 months ago

a) containers don't contain

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

tgsovlerkhgsel9• 7 months ago

a) containers don't contain

Except it seems to have done so in this case?

elif• 7 months ago

This is a perfect example of how honeypots, anti-malware organizations, and blacklists are so important to security.

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

LelouBil• 7 months ago

Something similar happened to me last year, it was with an unsecured user account accessible over ssh with password authentication, something like admin:admin that I forgot about.

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.

CGamesPlay2• 7 months ago

I took issue with this paragraph of the article, on account of several pieces of misinformation, presumably courtesy of Claude hallucinations:

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.

3np10• 7 months ago

"Write your own Dockerfiles" is not useful security advice.

I actually think it is. It makes you more intimate with the application and how it runs, and can mitigate one particular supply-chain security vector.

Agreeing that the reasoning is confused but that particular advice is still good I think.

esaym• 7 months ago

So this is part of the "React2Shell" CVE-2025-55182 issue? I find it interesting that this seems to get so little publicity. Almost like the issue is normal or expected. And it looks like the affected versions go back a little over a year. So if you've deployed anything with Next.js over the last 12 months your web app is now probably part of a million node bot net. And everyone's advice is just "use docker" or "install a firewall".

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

h33t-l4x0r• 7 months ago

I'm hearing about it like crazy because I deployed around 100 Next frontends in that time period. I didn't use server components though so I'm not affected.

mnahkies• 7 months ago

My understanding of the issue is that even if you don't use server components, you're still vulnerable.

Unless you're running a static html export - eg: not running the nextjs server, but serving through nginx or similar

hypeatei2• 7 months ago

You can write web apps without touching the hottest JS framework of the week. I've never touched these frameworks that try to blur the line between frontend and backend.

Pick a solid technology (.NET, Java, Go, etc...) for the backend and use whatever you want for your frontend. Voila, less CVEs and less churn!

reedlaw• 7 months ago

I had a Pangolin instance compromised by this: https://github.com/orgs/fosrl/discussions/2014

syhol• 7 months ago

Frontend churn has chilled out so much over the last few years. The default webapp stack today has been the same for 5 years now, next.js (9yo) react (12yo) tailwind (8yo) postgres (36yo). I'm not endorsing this stack, it just seems to be the norm now.

Compare that to what we had in the late 00's and early 10's we went through prototype -> mootools -> jquery -> backbone -> angularjs -> ember -> react, all in about 6 years. Thats a new recommended framework every year. If you want to complain about fads and churn, hop on over to AI development, they have plenty.

lobsterthief• 7 months ago

I remember that. To be honest it was exhausting. Fun, but exhausting. It’s nice now to have found a stack that is “just fine” for most things.

miohtama• 7 months ago

Use Svelte? (:

newsoftheday8• 7 months ago

For my Java based sites, I use HTML/CSS/JS (vanilla js), no frameworks.

aborsy• 7 months ago

If I’m not wrong, a hetzner VM by default has no firewall enabled. If you are coming from providers with different default settings, that might bite you. Containers that you thought were not open to internet have been open all this time. Two firewalls failed: They bypassed ufw and there was no external firewall either.

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

p0w3n3d2• 7 months ago

  $ 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

As a user of iptables this order makes me anxious. I used to cut myself out from the server many times because first blocking then adding exceptions. I can see that this is different here as the last command commits the rules...

kgeist• 7 months ago

I had this one too: I first denied all incoming requests and was about to allow SSH, but my SSH connection dropped :) Fortunately, I was able to restore the VM with the provider's VM console.

p0w3n3d2• 7 months ago

I have a funny story, when I did it in the startup script, then I ran it. I lost my ssh, and moreover this server was in another country, France. And moreover I set up the internal keyboard layout there to be US as I am writing without looking at the keyboard. In the result, the Polish-French guy there, who was at site, was unable to enter the password correctly unless I translated it to the french keyboard for him.

spoaceman77772• 7 months ago

"No more exposed PostgreSQL ports, no more RabbitMQ ports open to the internet."

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.

microtonal2• 7 months ago

Also, apparently they run an IoT platform for other users on the same host that cannot only visualize sensors, but also trigger (mains-powered) devices.

The right thing to do is to roll out a new server (you have a declarative configuration right?), migrate pure data (or better, get it from the latest backup), remove the attacked machine off the internet to do a full audit. Both to learn about what compromises there are for the future and to inform users of the IoT platform if their data has been breached. In some countries, you are even required by law to report breaches. IANAL of course.

kachapopopow2• 7 months ago

I find it interesting that the recent trend of moving to self-hosted solutions is sparking this rediscovery of security issues that come with self-hosting. One more time and it will be a cycle!

Aachen• 7 months ago

What trend? All I'm seeing here is further centralisation:

Search engines try to fight slop results with collateral damage mostly in small or even personal websites. Restaurants are happy to be on one platform only: Google Maps. Who needs an expensive website if you're on there and someone posts your menu as one of the pictures? (Ideally an old version so the prices seem cheaper and you can't be pinned down for false advertising.) Open source communities use Github, sometimes Gitlab or Codeberg, instead of setting up a Forgejo (I host a ton of things myself but notice that the community effect is real and also moved away from self hosting a forge). The cherry in top is when projects use Discord chats as documentation and bug reporting "form". Privacy people use Signal en masse, where Matrix is still as niche as it was when I first heard of it. The binaries referred to as open source just because they're downloadable can be found on huggingface, even the big players use that exclusively afaik. Some smaller projects may be hosted on Github but I have yet to see a self-hosted one. Static websites go on (e.g. Github) Pages and back-ends are put on Firebase. Instead of a NAS, individuals as well as small businesses use a storage service like Onedrive or Icloud. Some more advanced users may put their files on Backblaze B2. Those who newly dip their toes in self-hosting increasingly use a relay server to reach their own network, not because they need it but to avoid dealing with port forwarding or setting up a way to privately reach internal services. Security cameras are another good example of this: you used to install it, set a password, and forward the port so you can watch it outside the home. Nowadays people expect that "it just works" on their phone when they plug it in, no matter where they are. That this relies on Google/Amazon and that they can watch all the feeds is acceptable for the convenience. And that's all not even mentioning the death of the web: people who don't use websites anymore the way they were meant (as hyperlinked pages) but work with an LLM as their one-stop shop

Not that the increased convenience, usability, and thus universal accessibility of e.g. storage and private chats is necessarily bad, but the trend doesn't seem to me as you seem to think it is

I can't think of any example of something that became increasingly often self-hosted instead of less across the last 1, 5, or 10 years

If you see a glimmer of hope for the distributed internet, do share because I feel increasingly as the last person among my friends who hosts their own stuff

kachapopopow2• 7 months ago

it's slow, but there are people slowly turning towards a more decoupled internet, the problem is that you still *have* to use cloudflare (or any kind of http proxy), it's just a basic requirement that you can't avoid for anything that people would be interested in keeping offline.

I've been on the receiving end of attacks that were reported to be the size of more than 10tbps I couldn't imagine how I would deal with that if I didn't have a 3rd party providing such protection - it would require millions $$ a year just in transit contracts.

There is an increasing amount of software that attempts to reverse this, but as someone from https://thingino.com/ said: opensource is riddled with developers that died to starvation (nobody donates to opensource projects).

tgsovlerkhgsel9• 7 months ago

Would "user root" without --privileged and excessive mounts have enabled a container escape, or just exposed additional attack surface that potentially could have allowed the attacker to escape if they had another exploit?

PlqnK• 7 months ago

They would need a vulnerability in containerd or the kernel to escape the sandbox and being root in the sandbox would give them more leeway to exploit that vulnerability.

But if they do have a vulnerability and manage to escape the sandbox then they will be root on your host.

Running your processes as an unprivileged user inside your containers reduces the possibility of escaping the sandbox, running your containers themselves as un unprivileged user (rootless podman or docker for example) reduces the attack surface when they manage to escape the sandbox.

gppmad• 7 months ago

Well written blog post. Well done, I've learned something new.

mxxc• 7 months ago

regardless of firewalls and best practices and all, i'd just put all sorts of admin-related stuff behind tailscale (or similar), including ssh. hetzner allows you to have ssh closed in your public ip and still open a terminal via the console if ssh-on-tailscale fails. for the web stuff you should do a similar trick. blog and public websites on the public address, while admin stuff goes on tailscale. and if you do it nicely with letsencrypt you can even have nice hostnames pointing to your private stuff.

cachius• 7 months ago

Does anybody know how to just list the processes running inside a single container from within that container?

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.

dilippkumar• 7 months ago

I’m sorry you went through this.

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?

Hendrikto2• 7 months ago

The main reason to use Monero for stuff like this is their mining algo. They made big efforts and changed algorithms several times to make and keep it GPU and ASIC resistant.

If you used the server to mine Bitcoin, you would make approximately zero (0) profit, even if somebody else pays for the server.

But also yes, Monero has technically held up very well.

cylemons• 7 months ago

Didn't Qubic manage to attack Monero?

tgsovlerkhgsel9• 7 months ago

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

No. The reason attackers mine Monero and not some other cryptocurrency isn't the anonymity. Most cryptocurrencies aren't (meaningfully) mineable with CPUs, Monero (apparently) is. There may be others, but I suspect that they either deliver less $ per CPU-second (due to not being valuable), or are sufficiently unknown and/or painful to set up that the attackers just go with the known default.

Trying to mine Bitcoin directly would be pointless, you'd get no money because you're competing with ASIC miners. Some coins were designed to be ASIC resistant, these are mostly mined on GPUs. Monero (and some other coins) were designed to also be GPU resistant (I think). You could see it as a sign that that property has held up (well enough), but nothing else.

rendaw• 7 months ago

I didn't see it mentioned, but wouldn't having a RO root filesystem with writable directories mounted noexec also have been sufficient?

bradley13• 7 months ago

I had something similar, but I was lucky enough to catch it myself. I've used SSH for years, and never knew that it - by default - also accepts password logins. Maybe dumb on my part, but there you go...

broken_broken_• 7 months ago

I am not an expert in incident reaction, but I thought the safe way was to image the affected machine, turn it off, take a clean machine, boot a clean OS image with the affected image mounted read only in a VM, and do the investigation like that ?

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 ?

dewey• 7 months ago

Maybe if your company infrastructure is affected but not the server you use to host your side projects on with “coolify” unless IT security is your hobby.

jlengrand• 7 months ago

TY for the article. You made me look into my server, and also found some strange activity on my docker containers. Good call!

mos873• 7 months ago

so what's the point of containers here? seems only to make things less transparent and more complex to manage.

js scripts running on frameworks running inside containers

PS so I see the host ended up staying uncompromised

ChrisMarshallNY• 7 months ago

Good job.

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.

andix3• 7 months ago

I was surprised by the same thing, a tool I run that uses Next.js without me knowing before.

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 ;)

kalaksi• 7 months ago

After reading some comments: this probably goes without saying, but one should be very careful what to expose to the internet. Sounds like the analytics-service maybe could have been available only over VPN (or similar, like mTLS etc.)

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.

hnarn• 7 months ago

Interesting that this got posted today, I also have a server on Hetzner (although I don't think it's relevant) and noticed yesterday that a Monero miner had been installed.

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

nikanj3• 7 months ago

It makes me irrationally angry that cryptos have given a clear monetary value to raw CPU time, and a very strong incentive to create botnets.

majorbugger• 7 months ago

OK, so am I right that this guy had a completely unsecured metrics endpoint running on his server? Why would you do that in the first place?

nunodonato• 7 months ago

The world will be a better place when all crypto just disappears

tgsovlerkhgsel9• 7 months ago

Would it be better for the victim if that was ransomware (asking for Apple gift cards) or some malware that stealthily siphons off data until it finds something valuable?

prmoustache• 7 months ago

Author forgot one important take: to limit the attack surface what doesn't need to be public facing should not be public facing. Things such as analytics software can easily be accessed through wireguard or even simpler using ssh as socks proxy.

grugdev42• 7 months ago

Roughly 20 years ago, PHP sites were getting hacked everywhere.

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. ;)

urban_alien• 7 months ago

It's almost like... the problem wasn't the tool at all :P

TwoNineFive• 7 months ago

Webdevs still security ignorant. Actually just ignorant. Not sorry to say that because it's beyond true.

IlikeMadison• 7 months ago

I don't think using key-based authentication for SSH and enabling Fail2ban is necessary. Fail2ban is only useful if you keep password authentication. But I might be wrong.

Sohcahtoa823• 7 months ago

I should check my SSH logs.

My intuition is that since the SSH server reports what auth methods are available, once a bot sees that password auth is disabled, they will disconnect and not try again.

But I also know that bots can be dumb.

hank2000• 7 months ago

I've bene working with a GPU security company for the last few months... I can tell you that neo clouds (generally) do not see security as a high priority—or often, even their responsibility. Many do not have hte ability to even know if your GPUs have been compromised and they expect you'll take responsibility.

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

Sohcahtoa823• 7 months ago

I can tell you that neo clouds (generally) do not see security as a high priority—or often, even their responsibility.

AWS explicitly spells this out in their Shared Responsibility Model page [0]

It is not your cloud provider's responsibility to protect you if you run outdated and vulnerable software. It's not their responsibility to prevent crypto-miners from running on your instances. It's not even their responsibility to run a firewall, though the major players at least offer it in some form (ie, AWS Security Groups and ACL).

All of that is on the customer. The provider should guarantee the security of the cloud. The customer is responsible for security in the cloud.

[0] https://aws.amazon.com/compliance/shared-responsibility-mode...

scottydelta• 7 months ago

I have a similar setup but with following additional security configurations:

- 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.

throwawayffffas• 7 months ago

I also enabled UFW (which I should have done ages ago):

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.

racl101• 7 months ago

This is weird. I viewed this blog post on Chrome and it loaded fine. But I sent the link to my fellow dev and he tried viewing it on Microsoft Edge on MacOS but the browser showed a red page with the "This site has been reported as unsafe" message by the Microsoft Defender SmartScreen.

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

eikowagenknecht• 7 months ago

I got another mail from Hetzner on Dec 10, telling me that the BSI told them my web site was having serious security problems with Next.JS. Not having high opinions on the BSI, I first thought this was some very elaborate scam attack but no, it turns out it was legit and also Umamis inbuilt Next.JS for me. But apparently there was no crypto miner or other active abuse yet.

rishikeshs• 7 months ago

What a coincidence. I also received a similar email and upon investigating, found the same Monero mining on my server. Tried rebuilding the image, but same thing was poping up. Then I did a npm update and that fixed everything!

I got hacked: My Hetzner server started mining Monero

Related Stories