In short: A crypto miner on the server usually shows itself through persistently high CPU load for no apparent reason, through foreign processes, often under the web server user, and through outgoing connections to unknown destinations. Do not terminate the process hastily: first secure traces, look for the mechanisms that restart it and close the entry point. A miner means that someone was able to execute code on your server.
When the cloud provider's bill is the first warning
Often a crypto miner is noticed not through a security alarm but incidentally. The website becomes sluggish, the hoster reports an overrun of computing time, the fan in your own data center runs constantly, or the cloud provider's bill rises without new projects. For attackers, a miner is an easy way to make money from a compromised server.
Mining means using the computing power of a foreign system to generate cryptocurrency. The damage seems manageable because no data is encrypted. That is deceptive: whoever can start a miner can also read credentials, copy databases and create further backdoors.
After PHP2Shell, the check is especially worthwhile. The vulnerabilities CVE-2026-109618 and CVE-2026-109619 allow the execution of malicious code without logging in. There are no confirmed indicators of compromise, and a miner is not a specific sign of these vulnerabilities. But high load from unknown processes is among the general signs described in Am I already compromised?.
Interpreting the signs of a crypto miner correctly
High load has many harmless causes. The table helps with a first classification:
| Observation | Harmless explanation possible | What you check |
|---|---|---|
| CPU persistently near full load | Backup, image processing, index build | Is the load steady at night and on weekends too? |
| Process with a name like a system service | rarely | Is the program file in the expected system path? |
Process under www-data, apache or nginx that is not PHP |
hardly | Who started it, from which folder? |
Program in /tmp, /var/tmp or /dev/shm |
hardly | Since when does the file exist, who owns it? |
| Persistent outgoing connection to an unknown destination | Monitoring, updates | Does the destination belong to a known service? |
| Load drops as soon as you log in | rarely | Some malware pauses when monitoring tools run |
The more rows apply, the more likely a find is. That the web server user starts foreign programs at all is in itself a strong warning sign, as the article The web server starts a shell shows.
How to check processes and connections
The following commands only read. Note the result and the time before you change anything:
# Processes by CPU usage, with user, start time and full command
ps -eo pid,ppid,user,lstart,%cpu,%mem,args --sort=-%cpu | head -20
# Program file and working directory of a suspicious process (insert the PID)
sudo ls -l /proc/PID/exe /proc/PID/cwd
# Outgoing connections with process
sudo ss -tnp state established
# Executable files in temporary folders
sudo find /tmp /var/tmp /dev/shm -type f -perm -u+x -ls 2>/dev/null
If /proc/PID/exe points to a file with the suffix (deleted), the program was deleted after the start. That is a typical camouflage attempt. The process keeps running, and as long as it runs, the program file can still be secured via /proc. Someone who can handle malware should take that on; never execute the file.
How to go through processes systematically beyond the miner is described in Finding suspicious processes on Linux servers.
Why the miner keeps coming back
Many operators terminate the process, are pleased about the falling load and find the next day that everything starts over. Miners are almost always installed with a restart mechanism. Typical places are:
- Cron jobs of the web server user or system-wide, which check every few minutes whether the miner is running and otherwise reload it.
- System services with inconspicuous names that start at boot.
- A webshell in the web directory, through which the attacker restarts the miner at any time.
- Modified startup scripts or profile files of users.
- Foreign SSH keys with which the attacker logs straight back in.
# Cron jobs of the web server user and system-wide entries
sudo crontab -u www-data -l
ls -la /etc/cron.d /etc/cron.hourly /var/spool/cron 2>/dev/null
# Most recently changed systemd units
sudo find /etc/systemd/system /lib/systemd/system -name '*.service' -newermt "2026-10-17" -ls
Only when all mechanisms are found does the server stay quiet permanently. If the attacker had root rights, a rebuild on a fresh system is usually more reliable than searching for every hiding place.
The right order after the find
A miner looks like a technical annoyance but is a security incident. Proceed in an orderly way:
- Secure: Copy the process list, connections, suspicious files and logs with a checksum before anything is terminated.
- Contain: Isolate the server or block outgoing connections if that is possible without data loss.
- Close the cause: Bring PHP to a fixed version (8.5.12, 8.4.27, 8.3.36, 8.2.35 or a confirmed backport), restart all workers, update the CMS and extensions.
- Clean up or rebuild: Remove the miner, restart mechanisms and backdoors; when in doubt, set up anew.
- Check consequences: Could credentials or personal data have been read? Then clarify data protection and, if applicable, notification duties.
Involve your hoster or cloud provider early. Many providers precautionarily block servers with conspicuous load or conspicuous network traffic. Whoever informs the provider themselves and agrees on the procedure is more likely to keep control over the time of the shutdown. Also ask for the provider's network and access logs, because they sit outside your server and are hard for an attacker to alter.
For management, a short, honest classification is important: the miner itself costs mainly computing time and performance. But the real question is what else the attacker saw. Until that is clarified, the incident should not be considered closed, even if the load is back to normal.
A crypto miner shows that code was executed on your server. Treat all credentials that were on the server as possibly leaked, and renew them after the cleanup.
How does PHP SOS help?
- We classify the load and distinguish between harmless causes and foreign processes.
- We secure processes, files and connections before the miner is terminated.
- We search for all restart mechanisms and backdoors and clean up the server within malware removal or rebuild it.
- We close the entry point, renew access and set up load monitoring that reports unusual patterns early.
Frequently asked questions
How do I recognize a crypto miner on my server?
Typical is a persistently high CPU load that does not fit visitor numbers or scheduled tasks. In addition there are processes with unknown or harmless-sounding names, often under the web server user, and outgoing connections to foreign addresses. A single feature is not yet proof.
Is it enough to terminate the mining process?
No. Miners are usually started again and again via cron jobs, system services or a webshell. If you only terminate the process, you often see it again a short time later. In addition, the entry point through which the miner got onto the server stays open.
Is a crypto miner harmless because it only steals computing power?
No. Whoever could install a miner could execute code on the server. As a rule, that also made configuration files, credentials and databases reachable. The miner is the visible symptom of a break-in.
What harmless causes does a high server load have?
Backups, image processing, search index builds, aggressive crawlers or a faulty extension can also consume a lot of computing time. These causes can usually be assigned to a known process and schedule. If the load remains unexplained, you should check more closely.