composer status 无法发现恶意注入，因为它只比对 composer.lock 中的哈希与 vendor 包当前哈希，不检查文件内容篡改；即使 autoload.php 被替换成 webshell，只要哈希未变就无提示。

composer status 为什么不能直接发现恶意注入

composer status 只比对 composer.lock 中记录的哈希与 vendor 目录下对应包的当前哈希，它不检查文件内容是否被篡改——只要哈希没变，哪怕 vendor/autoload.php 被替换成 eval($_GET['x'])，status 也完全沉默。

常见错误现象：

• 你运行 composer status 输出为空，但网站已被植入 webshell
• composer status -v 显示某包 “modified”，进去一看只是多了一行 var_dump()，误以为这就是全部风险
• 攻击者用 git commit --amend 重写 dist 包的 tag，并更新 lock 文件中的 dist.shasum，让 status 和 install 都“验证通过”

真正要查的是 autoload.php 和 autoload_real.php

这两文件是自动加载入口，也是最常被注入的位置。它们不参与 composer status 的哈希比对，因为：

• vendor/autoload.php 是静态引导文件，内容固定为 require_once __DIR__ . '/composer/autoload_real.php';
• vendor/composer/autoload_real.php 由 Composer 动态生成，但它的哈希根本不在 composer.lock 中记录

实操建议：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 立即执行：grep -q "eval\|system\|shell_exec\|base64_decode\|file_get_contents.*http" vendor/autoload.php && echo "INJECTED" || echo "OK"
• 验证 autoload.php 内容是否原始：sha256sum vendor/autoload.php 应该等于 echo 'require_once __DIR__ . "/composer/autoload_real.php";' | sha256sum
• 抽样检查高危文件：sha256sum vendor/composer/autoload_real.php —— 这个文件一旦被改，所有自动加载逻辑都可能被劫持

结合 verify-checksums 和手动 ref 比对才可靠

composer verify-checksums --strict（Composer ≥2.9.6）能校验已安装包的 dist 哈希，但它只覆盖 dist 安装的包；source 安装（Git 克隆）的包默认跳过，且不校验生成文件。

所以必须补一手轻量级比对：

• 确认包安装方式：composer show vendor/package --format=json | jq -r '.dist.type // "source"'，返回 zip 或 tar 才走哈希校验
• 比对 lock 与实际安装的 commit/ref：composer show --locked --format=json | jq -r '.packages[] | "\(.name) \(.dist.reference // .source.reference)"' | sort > lock-ref.txt，再从 vendor/composer/installed.json 提取对应字段生成 installed-ref.txt，最后 diff lock-ref.txt installed-ref.txt
• 忽略干扰项：跳过 vendor/bin/（软链）、vendor/composer/installed.json（含时间戳），否则比对必失败

CI 和部署前必须加的三道防线

靠人肉跑 composer status 或临时 grep，永远防不住自动化攻击。真正在意安全的团队会在 CI 流水线里固化以下检查：

• 强制校验签名：composer config -g security.signature-verification true，并确保 secure-http=true
• 禁止 untracked 文件残留：composer status -v | grep "Untracked files" && exit 1 || true，防止有人往 vendor/some-package/ 里塞恶意 payload.php
• 锁定 autoload.php 内容：grep -q "autoload_real\.php" vendor/autoload.php || exit 1，这是最基础、最廉价、也最容易被绕过的防线——但至少拦得住脚本小子

真正难防的是那种在 post-install-cmd 里动态下载并写入 autoload_real.php 的攻击，它不改哈希、不碰 Git、不触发 status，只等 composer install 执行时悄悄落盘。这种场景下，--no-scripts 不是可选项，是必选项。