前几天，知乎有位网友把自己那台1核1G小服务器的遭遇完整复盘了一遍，看完后背发凉：他只是觉得机器卡，登上去看了眼内存，结果顺着查下去，挖出一整套挖矿木马、rootkit和SSH后门。
更扎心的数字在后面：他那台服务器上的Gitea，账号列表里躺着925个账号，只有1个是他的；仓库总数3627个，也只有1个是他的。剩下那924个账号、3626个仓库，全是攻击者自动注册的——他的小服务器，已经被黑产当成基础设施用了25天。知乎
而这台服务器的入口，就是一个放了两年没人管的Gitea：版本停在1.22.3，开着公开注册，直接暴露在公网上。按那位网友的复盘，同版本同漏洞的两台机器，多开了root密码登录的那台被完整拿下、占领了25天；SSH干净、安全agent活着的那台，攻击者只打到了Gitea账号层。差距就在这一两条配置上。
如果你也在家里的NAS、轻服务器或者一台老VPS上装过Gitea、GitLab、Gogs，这篇值得花5分钟看完。因为刚过去的8月，自建Git服务圈子结结实实挨了一轮组合拳。
8月发生了什么：三款自建Git服务接连中招
先说最实锤的一条。8月17日，GitLab打破常规月度节奏，发布紧急非周期安全更新，一次修掉两个GraphQL接口漏洞，其中CVE-2026-19478的CVSS 3.1评分高达9.4（严重级）：攻击者不需要任何账号、不需要任何交互，只要你的GitLab实例公网可访问，一条HTTP请求就能删除实例内的公开项目、篡改用户账号状态。知乎注意删除是物理删除，没有回收站，没备份就真没了。同批修复的CVE-2026-19650（CVSS 7.1）则是CSRF，可诱导已登录用户执行未授权操作。
极狐GitLab官方随后确认了受影响范围和补丁版本：18.2到19.2全线中招，对应修复版本是18.11.11、19.0.8、19.1.6、19.2.4，这次补丁不含数据库迁移，多节点部署也能零停机热升级；JihuLab.com已运行修复后的版本，托管用户无需任何操作——压力全部落在自托管实例上。知乎另有安全文章援引奇安信鹰图的测绘数据称，国内暴露在公网的风险GitLab资产高达10.8万余个，大多是中小团队没人维护的老实例。
再看Gitea。8月23日那份受害者复盘把攻击链讲得很清楚：入口是Gitea 1.22.x及以下版本diff/patch接口的路径穿越漏洞（CWE-22），攻击者能把文件写到仓库目录之外，写进hooks/目录的脚本会在push时自动执行。知乎拿到代码执行后，攻击者直接改数据库把账号提为管理员，完全绕过权限检查；为了在没有出站网络的机器上回传数据，他们把命令输出写成fork母库里的一个git分支，数据全程不出机器，出站防火墙根本拦不住。
更麻烦的是，8月中旬还披露了CVE-2026-58053：Gitea Actions的act_runner存在容器逃逸风险，恶意工作流可以创建共享宿主机PID/IPC命名空间、拥有全部Linux能力的容器，再用nsenter直接以root接管宿主机。按当时披露文章的说法，漏洞细节和PoC已经公开，官方补丁尚未发布，完整受影响范围也未确认——如果你的Gitea开着Actions功能，这条需要盯紧官方通告。知乎
连相对小众的Gogs也没幸免：6月披露的CVE-2026-52800（CVSS 8.8），组织团队成员管理接口缺少CSRF防护，攻击者诱导组织owner点一个链接，就能把自己塞进Owners团队，等效接管整个组织。修复方案是升级到0.14.3及以上，并排查移除异常的Owners账号。知乎
为什么"我服务器没啥值钱东西"这个想法不成立
很多人不更新、不加固，逻辑是：我一个个人小服务器，攻击我图什么？
那位受害者的日志给出了残酷答案：没人针对你，但扫描器在排队。他的access log里，GET /api/v1/version的指纹探测每隔几小时就来一次，来源五湖四海；攻击者建仓库的节奏是每30分钟一轮、卡在整点和半点——典型的cron定时机器人，境外的固定VPS负责打洞，国内动态IP负责注册、读数据这类"像正常人"的操作，分工明确。知乎漏洞版本摆在那，谁扫到算谁的。
而且黑产要的根本不是你的代码：他们要的是你的算力和你的身份——挖矿、当跳板、用你的Gitea账号继续扩散，你的仓库只是顺路看一眼。所以自查的理由不是"我有价值"，而是"我在扫描器的地图上是亮的"。
5分钟自查清单
对照下面四条，逐条过一遍：
①查版本。 登上机器跑一下：Gitea是`gitea --version`；GitLab看`/opt/gitlab/embedded/service/gitlab-rails/VERSION`或后台Help；Gogs是`gogs --version`。对照：Gitea停在1.22及以下的有在野RCE风险，开源版最新已经更新到1.27.0。知乎GitLab自托管在18.2～19.2区间且低于18.11.11/19.0.8/19.1.6/19.2.4的，中招的正是那个9.4分漏洞；Gogs低于0.14.3的，组织接管漏洞还没修。
②查暴露面。 你的服务是直接公网端口，还是走了VPN/内网穿透/反代加认证？有没有开着公开注册？受害者两台机器的差别就在这：同样版本漏洞，一台多开了root密码登录，root直接被拿下；另一台SSH干净，攻击者只打到Gitea账号层。暴露面每多一条，失守深度就深一层。
③查入侵痕迹。 三条就够：`top`看有没有长期满载但不知道是谁在吃（特别注意陌生守护进程、被改名的系统命令，比如复盘里出现的`top.original`）；Gitea后台看用户数和仓库数有没有莫名暴涨；`crontab -l`和`/etc/cron.*`里有没有不认识的条目。
④查备份。 GitLab这次的删除是物理删除；被挖矿的机器重装是大概率结局。现在问自己一句：仓库的本地副本在哪？能不能今天就导出一份？
查完之后怎么办
版本落后的：升级是唯一根治方案，官方明确说过这个漏洞没有配置开关可关。GitLab这次补丁支持零停机热升级，成本很低；Gitea建议直接升到1.27.0；Gogs升到0.14.3以上。升级前先把仓库导一份备份。
暂时升不了的：GitLab可以先把所有Public项目改成Internal/Private（这个漏洞只能打公开项目），或者在防火墙/反代层禁止公网访问`/api/graphql`；Gitea关掉公开注册、撤下公网端口，躲进VPN后面。
开着Gitea Actions的：CVE-2026-58053目前以官方通告为准，先把fork PR触发Actions的权限收紧，Runner别和存凭据的宿主机混跑。
已经中招的：别纠结"清干净了没有"。受害者说得很对——在一台root被拿了25天的机器上，"我清干净了"是个无法证明的命题，你能证明删了X，证明不了不存在没找到的Y。数据有副本就备份后重装，给自己一个确定的干净起点。
用云端托管的：GitHub、GitLab.com、极狐云、Gitee这类由平台方负责打补丁，这轮风险跟你关系不大，可以松口气——但顺手想想自己的仓库有没有异地备份，总没坏处。
接下来值得盯的两个信号
一是Gitea官方对act_runner容器逃逸（CVE-2026-58053）的补丁进展和完整受影响版本范围，目前各披露口径还不统一，一切以官方公告为准；二是"开源组件+公开PoC+自动化扫描"这套组合拳接下来只会更频繁——自建服务这件事，"装完就不管"的红利期已经结束了。
如果你也是照着教程在NAS上搭了Gitea、然后就再没打开过的那批人，今晚花5分钟查一下版本。这比哪天早上发现机器在替别人挖矿、然后重装系统，便宜太多了。
