起因与总述
8月4日晚发现服务器CPU占用率无故达到100%，猜测服务器遭到了挖矿病毒的入侵，于是前往终端执行top命令，发现名为xmrig的进程占用大量CPU，关闭进程后恢复正常。但由于进程在被关闭后删除了临时文件，因此并未成功定位病毒来源。
8月6日晚再次出现CPU占用100%的情况，于是这次我没关闭进程，直接进行了排查。
最终排查的结果指向gitea，因此我暂时关闭了本地部署的gitea并杀死挖矿进程。之后恢复正常。
8月10日阿里云非常及时的 在我解决问题之后 通知我gitea官方公布了CVE-2026-60004 远程代码执行漏洞并让我小心。目前将gitea更新到最新版本即可解决问题。
阿里云非常及时的提醒
本文为本人此次事件的问题排查记录，用作以后关于服务器维护与安全保障的经验记录，并不能当做任何教程。 不过如果能够帮助到任何人我也会很高兴的。
本次排查过程借助了chatgpt进行输出分析
问题发现
8月6日晚发现CPU占用达到100%之后，立即开始进行排查，在终端执行top命令后，发现一条明显异常的输出：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
487164 ppomega 30 10 2464068 2.3g 4808 S 1101 7.4 12,01 ssl-compet
占用bro1000%的CPU，太弔了
定位进程
1. 查看可执行文件位置
首先查看了该进程的可执行文件位置
执行
$ ls -l /proc/487164/exe
输出
lrwxrwxrwx 1 user user 0 Aug 6 20:04 /proc/487164/exe -> /tmp/.xmon-1000/ssl-compet
之后我尝试查看这个文件夹
$ ls /tmp/.xmon-1000
但终端输出不存在此文件夹
当时的第一反应为程序在启动后自动删除了临时文件夹
但现在复盘看来只是因为程序运行在容器内，自然在宿主机上无法找到
2. 查看命令行
没有找到程序文件夹，因此尝试通过查看进程启动的命令行寻找线索
执行
$ cat /proc/487164/cmdline
输出
sslmon
从中也无法发现任何线索
3.查看进程树
尝试通过查看进程树寻找线索
执行
$ pstree -sp 487164
输出
systemd(1)───containerd-shim(3033)───s6-svscan(3530)───post-index-chan(486543)───post-index-chan(486546)───bash(486548)───ssl-compet(487164)─┬─{ssl-compet}(487168)
├─{ssl-compet}(487169)
├─{ssl-compet}(487170)
├─{ssl-compet}(487171)
├─{ssl-compet}(487172)
├─{ssl-compet}(487251)
├─{ssl-compet}(487252)
├─{ssl-compet}(487253)
├─{ssl-compet}(487254)
├─{ssl-compet}(487255)
├─{ssl-compet}(487256)
├─{ssl-compet}(487257)
├─{ssl-compet}(487258)
├─{ssl-compet}(487259)
├─{ssl-compet}(487260)
├─{ssl-compet}(487261)
├─{ssl-compet}(487262)
├─{ssl-compet}(487263)
├─{ssl-compet}(487264)
├─{ssl-compet}(487265)
├─{ssl-compet}(487266)
├─{ssl-compet}(487267)
├─{ssl-compet}(487268)
├─{ssl-compet}(487269)
├─{ssl-compet}(487270)
├─{ssl-compet}(487271)
└─{ssl-compet}(487272)
从bash里直接复制过来格式乱了，能看得懂就行
从这个输出中可以得到几个重要信息
- 挖矿程序直接的父进程为bash(486548)
- 程序运行在某个容器中——containerd-shim(3033)
这样也能解释为什么之前直接找程序目录会显示不存在。
此时基本可以确认是某个容器内运行的服务的漏洞导致攻击者能够执行挖矿脚本
定位攻击入口
1.再次定位工作目录
尝试从父进程bash(486548)定位工作目录
$ pwdx 486543 '这里也可以换成 ls -l /proc/486543/cwd
输出
/data/gitea/tmp/local-repo/upload.git978644335
从这里就可以看得出是gitea的问题了
当时我没有直接对ssl-compet执行pwdx，因此不清楚直接对ssl-compet执行这个命令是否会输出同样的内容。如果也能输出一样的内容的话其实也不需要通过父进程来寻找了。但是查找进程树这个操作发现了程序运行在容器内，也算是必要的一步
2.登录gitea查看
因为定位到问题出现在gitea，因此我直接登录了gitea并查看后台，发现了大量的未知用户与仓库，这些用户与仓库的名字也明显是通过自动化脚本进行创建的。
至此可以确定是gitea的某个漏洞导致用户可以通过某种方式执行脚本，在攻击目标安装并运行挖矿程序。之后通过查找才知道是CVE-2026-60004。
在当时我直接关闭了gitea并杀死了进程。之后进程没有复活说明问题解决
之后我还进入gitea仓库借助chatgpt查看和分析了攻击者执行的脚本，不过看的不是很完全懂，姑且按下不表
确认宿主机是否受到影响
因为是gitea的漏洞而不是docker的漏洞因此宿主机受到影响的可能性比较小，不过还是简单进行了检查
这部分的检查过程完全依靠chatgpt，我和gpt都没有看出有问题，应该是没有问题了
1.检查docker容器的权限和目录
输入与输出如下
$ sudo docker inspect gitea --format '{{.HostConfig.Privileged}}'
false
$ sudo docker inspect gitea --format '{{json .HostConfig.CapAdd}}'
null
$ sudo docker inspect gitea --format '{{json .HostConfig.Binds}}'
["~/gitea/gitea:/data:rw","/etc/timezone:/etc/timezone:ro","/etc/localtime:/etc/localtime:ro"]
docker容器并没有获得较高权限，也没有建立挂载未知目录，基本可以确认docker容器内的程序没有逃逸到宿主机
2.检查docker容器的日志
$ sudo journalctl -u docker --since "2026-08-01" | grep -Ei "exec|create|start|privileged"
这一条的输出就非常长了，因此我直接丢给gpt让他帮我看
gpt表示没有异常
3.检查宿主机的计划任务
确保挖矿程序没有通过计划任务复活的可能
输入
$ sudo crontab -l
no crontab for root
$ crontab -l
no crontab for ppomega
基本可以确认宿主机安全了
后续
我经过检查发现当初部署gitea的时候没有关闭开放注册的功能，这也是导致了本次中招的原因，这种放在公网上的服务越小心越没错
能不放公网的东西就不放公网是最好的
以上便是本次服务器受到挖矿程序攻击的排查记录，以后在遇到类似事情的时候给自己留个流程，也算在服务器维护经验上添了一笔。
