深夜的机房灯火通明,屏幕上的警报却无人应答。一家加拿大能源公司的核心代码库正被人悄然搬空,客户关系系统和员工数据库的钥匙,已经握在千里之外的黑客手中。这一幕并非电影桥段,而是正在全球多个大洲同步上演的真实网络攻防战。Acronis威胁研究部门的最新调查揭开了一个令人不安的事实:一个被称为红鹭(Red Heron)的中文威胁组织,正利用Gitea平台一个评分高达9.8的严重远程代码执行漏洞,对暴露在互联网上的自托管服务器展开系统性洗劫。

相关服务:台湾站群服务器租用

开源平台的阿喀琉斯之踵

Gitea作为一款轻量级开源代码托管平台,凭借部署简单、资源占用低、功能完整的特性,在软件工程团队中积累了极高的人气。无论是初创团队还是大型企业,都愿意把最核心的数字资产——源代码——托付给它。互联网扫描数据显示,全球面向公网开放的Gitea部署数以万计,这也意味着一旦平台本身出现安全缺陷,无数的知识产权、开发凭证和配置密钥将同时暴露在火力覆盖之下。

这次的漏洞编号为CVE-2026-60004,CVSS评分达到9.8分的最高严重级别,影响范围覆盖1.17.0至1.27.0之间的所有版本。换句话说,过去数年间部署且从未升级过的Gitea实例,几乎全部处于裸奔状态。漏洞的根源藏在Gitea内部的补丁处理流程中:当服务器处理通过diffpatch端点传入的补丁文件时,会执行带有三路合并回退参数的Git命令,而这一过程恰恰给攻击者留下了注入恶意代码的缝隙。

前端- 47.5k Star! 轻量级自托管代码仓库-Gitea - 程序员凌览- SegmentFault 思否

重复提交补丁,竟能劫持整个服务器

整个攻击链条的精妙之处,在于对Git自身工作机制的利用。攻击者连续两次向服务器提交完全相同的特制补丁文件。第一次提交时,恶意有效载荷被悄悄写入Git索引;紧接着的第二次提交触发合并冲突,迫使Git将文件直接落盘到临时克隆仓库的hooks目录中。由于这个克隆环境是裸仓库结构,仓库根目录与$GIT_DIR完全重合,写入的post-index-change钩子文件会直接落入Git的活动钩子目录。下一次Git访问索引时,这段恶意代码便会以Gitea服务账户的身份被自动执行。

更令人后背发凉的是,Gitea在全新安装后默认开启开放式账户注册。攻击者根本不需要窃取任何现有账号,只要随手注册一个临时账户、创建一个仓库、推送恶意补丁,一台服务器的大门就此敞开。从某种程度上说,这个漏洞把代码协作平台最引以为傲的开放性,变成了引狼入室的通道。

漏洞披露后的短短几天内,GitHub上便出现了公开的概念验证脚本。红鹭组织以惊人的速度将这些公开代码改造成一套全自动化攻击框架:自动注册符合特定命名规律的账户,批量触发远程代码执行,转储数据库表,打包下载目标仓库,最后还能清理数据库日志中的入侵痕迹,大幅拖延受害者的发现时间。整个流程行云流水,几乎不需要人工干预。

红鹭的野心,远不止偷几份代码

如果你以为黑客攻入中央代码库只是为了窃取静态源代码,那就太小看这个组织的胃口了。Acronis的研究人员确认,红鹭维护着一份针对战略性行业的结构化侦察数据库,目标涵盖国防承包商、选举基础设施、航空航天企业和可再生能源供应商。在首次侦察阶段,他们扫描了分布在七个国家的1386个Gitea实例,随后确认的攻击事件已波及加拿大、阿根廷、中国台湾、美国和斯里兰卡的多家组织机构。

黑客攻击服务器或数据库。网络安全、数据库安全和个人数据保护向量例证- Illustration of 设备, 暗箭伤人者: 162677107

横向渗透的深度同样令人咋舌。在加拿大的受害能源公司,攻击者在拿到代码库之后又顺藤摸瓜,径直摸进了内部的客户关系管理系统和员工数据库。在中国台湾的一处部署环境中,红鹭最初只控制了一台暴露的存储服务器,却借此逐步拿下了一个三节点Proxmox虚拟化集群的root权限,并利用系统内置工具完整导出了所有虚拟机的备份。源代码、配置密钥、JSON Web Token、私钥,乃至整台虚拟机的镜像,统统被收入囊中。

JITTERLY与SIXZUT:潜藏在系统深处的幽灵

比数据失窃更难缠的,是攻击者留下的持久化后门。为了长期潜伏,红鹭部署了一个名为JITTERLY的定制C++后门程序,其中还内嵌了一个尚未公开的Linux共享库rootkit,内部追踪代号为SIXZUT。这类恶意软件的可怕之处在于它对系统底层的接管能力:文件列表被篡改,敏感文件在管理员眼皮底下凭空消失;运行进程被隐藏,后门活动从任务管理器中彻底蒸发;网络连接记录同样遭到过滤,外传数据的通道被抹得干干净净。甚至当管理员尝试终止可疑进程时,rootkit还会拦截终止信号,并在进程退出后自动将其重新拉起。

Rootkit - CyberHoot 网络图书馆

这意味着,即便企业事后察觉异常,常规的排查手段也很可能一无所获。攻击者留下的不是一个简单的后门,而是一整套与操作系统深度融合的隐身体系。

留给防御者的时间已经不多了

安全团队的响应速度必须快过自动化攻击工具的传播速度。目前最直接的处置方案,就是将所有自托管Gitea实例立即升级到1.27.1或更高版本。官方修复方案的核心思路是从架构上根除隐患:将处理补丁时的临时克隆从裸仓库改为非裸仓库,让恶意文件再也无法借道$GIT_DIR落入钩子目录,攻击路径被永久性掐断。

服务器机房最佳物理安全实践_搜狐网

对于暂时无法立即升级的团队,还有几道防线可以筑起。公开注册功能除非业务必需,否则应当果断关闭,斩断攻击者零成本入驻的通道。运维人员需要彻查仓库目录中2026年7月之后创建的可疑Git钩子文件,任何来历不明的post-index-change都值得高度警惕。网络层面可以通过虚拟专用网络限制对Gitea网页端的访问,避免管理界面直接暴露公网。主机层面则要留意LD_PRELOAD环境变量是否遭到篡改,这是检测共享库rootkit的重要线索。

还有一点极易被忽视:轮换。所有仓库部署密钥、访问令牌、管理数据库凭据都应当视为已经泄露,全面更换。攻击者获取的每一枚令牌,都是他们再次叩门的备用钥匙。

写在最后

CVE-2026-60004的爆发再次敲响了警钟:开源组件的便利性从来都与风险并存。当一个漏洞拥有公开的概念验证代码、活跃的自动化利用工具和 EPSS高达86.8%的利用概率时,拖延修补的每一天都是在赌运气。代码是企业的命脉,而托管命脉的平台本身,理应得到最严格的看护。立即检查你的Gitea版本,现在就行动。