XMRig Miner auf Webhosting – wie Angriffsvektor finden?

Nach Node und Next will React natürlich auch mitmachen. Das wird noch lustig.

Node.js, next.js und natürlich react.

😶 winter is coming

Hi, ich habe seit gestern um 15 Uhr genau das gleiche Problem, auch bei Webhosting 8000.
Bei mir wurde der Miner vermutlich über eine Umami Installation (verwendet Next.js 15) eingeschleust.
Leider hat sich der Support bis jetzt nicht bei mir gemeldet, sodass meine Services und Webseiten seit gestern offline sind.

Vielleicht findet sich ja hier im Forum ein Support Mitarbeiter, welcher das anliegen schneller bearbeiten kann.

Domvnxk wie hast du die betroffenen Dateien gefunden und gelöscht?
Soweit ich weis gibt es bei dem Hosting kein Zugriff auf zB htop um weitere "unerwünschte" Prozesse im Hintergrund zu finden.

Zitat von Domvnxk

- CVE-2025-29927 betrifft Next.js < 15.2.3

FYI: Der ursprüngliche Patch war nicht vollständig und man muss den Patch nochmals patchen, siehe https://nextjs.org/blog/security-update-2025-12-11

Kontrolliere im WCP bzw. Plesk unbedingt auch, ob es irgendwelche unbekannten Cronjobs ("Geplante Aufgaben") gibt! In der Vergangenheit hat sich bei anderen Angriffen gezeigt, dass die ohne Zugang zum Control Panel über die normale HTTP-Umgebung der Prozesse angelegt werden können. Bereinigt man die nicht, ist das Ding womöglich nicht weg und weiterhin aktiv.

Today I got a similar issue cause by the next.js app, now my account has been deactivated. I need to activate my account so that I can fix the issue.

Zitat von cedrickany

Hi, I've had the exact same problem since 3 PM yesterday, also with Webhosting 8000.
The miner was probably introduced via an Umami installation (using Next.js 15).
Unfortunately, support hasn't contacted me yet, so my services and websites have been offline since yesterday.

Perhaps there's a support representative here in the forum who can address the issue more quickly.

Domvnxk, how did you find and delete the affected files?
As far as I know, this hosting doesn't allow access to, for example, htop to find other "unwanted" background processes.

Alles anzeigen

Are you able to fix your issue? I am facing a similar issue, and currently my server is disabled to make any changes into it. How did you fix it.

fwiw:

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

https://news.ycombinator.com/item?id=46305585

Zitat

Container isolation actually worked. Nice.

Why This Matters: Dockerfiles vs. Auto-Generated Images

Here’s the thing that saved me. I write my own Dockerfiles for my applications. I don’t use auto-generation tools like Nixpacks (which Coolify supports) that default to USER root in containers.

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

• Install cron jobs for persistence
• Create systemd services
• Write anywhere on the filesystem
• Survive reboots

His fix required a full server rebuild because he couldn’t trust anything anymore. Mine required… deleting a container.

from:

Shutting down customers' server for something they didn't do is wrong. Netcup should at least give users a day to respond before locking them out and asking them to provide a straight 4-hour time window in advance to access it or loose it, which only people with lots of freedom can do.

Zitat von KaKi87

Shutting down customers' server for something they didn't do is wrong. Netcup should at least give users a day to respond before locking them out and asking them to provide a straight 4-hour time window in advance to access it or loose it, which only people with lots of freedom can do.

If this is you: https://www.reddit.com/r/VPS/comments…eged_mining_no/ , your legal opinion there as here is just wrong.

Have a look at https://www.netcup.com/en/terms-and-conditions -> Point 5. , and in there especially part 7.:

Zitat

If the customer breaches the code of conduct as set out above or if there is a well-founded suspicion of the same, netcup is entitled to temporarily block the provision of services normally provided to the customer. This applies particularly if a cease-and-desist order is brought against the customer by third parties for certain specified reasons that are not manifestly unfounded, or in the event of an investigation being conducted by state authorities. If possible, netcup will grant the customer a hearing before withdrawing services; if the urgency of the situation makes this impossible, netcup will inform the customer after the event and offer the latter an opportunity to make a statement. Services are resumed as soon as the suspicion proves groundless or infringements are identified that entitle netcup to terminate the contract without notice

In this case, the urgency of the situation seemed to have made a hearing before withdrawing services impossible.

Zitat von KaKi87

Shutting down customers' server for something they didn't do is wrong.

It absolutely isn't!! The customer is the solely responsible person for everything running on servers which are only administered by the customer (should be obvious). When something problematic has happened, it doesn't matter if the customer caused it or not. It is her/his responsibility. Period. One could say that also a hacked server is something a customer did (not securing the server enough, not updating software, installing malware, etc.).

As said on Reddit: you should be thankful that this has happened, so that you can work on the problem instead of having a compromised server online which could do things with way worse consequences for you. Having the server offline damages you less than having it compromised.