Cognition开源漏洞盘点与修复技能

Cognition 开源了 Devin Vulnerability Fixes，把针对 PHP、Node.js 和自建 GitLab 漏洞的修复流程写成三个 Agent Skills。它想解决的问题很具体：依赖文件改了，线上运行时却可能仍有漏洞。

值得看的不是「AI 自动修漏洞」这个宣传点，而是它如何盘点部署环境、确认修复版本、测试并提交 PR。原文没有公布修复成功率，判断它是否有用，得看这些流程能否覆盖你的实际部署方式。

它修的是运行环境，改 package.json 未必管用

这个插件采用 MIT 许可证，免费开源，包含 fix-php-vuln、fix-node-vuln、fix-gitlab-vuln 三个技能，分别处理三组指定安全公告。

PHP2Shell 包含 CVE-2026-109618 和 CVE-2026-109619，按原文列出的 PHP 评级，两者均为 CVSS v4.0 9.2。前者在内存耗尽后引发内存破坏，后者让前一次请求的残留全局状态进入下一次请求。所有提供 Web 服务的部署方式都受影响，其中 mod_php 风险最高。

对应修复版本为 8.2.35、8.3.36、8.4.27、8.5.12。PHP 8.1 及更早版本没有新的发布包，7.4、8.0、8.1 只有源码回补。

Node.js 部分针对 2026 年 10 月 21 日的安全发布，共涉及 10 个 CVE，其中 4 个为 High。重点漏洞 CVE-2026-111497 是 Brotli 解码器的越界写入，可能导致远程代码执行（RCE）。修复版本为 22.23.4、24.22.1、26.12.1；Node.js 20 及更早版本已经结束维护，没有修复版本。

GitLab CVE-2026-110264 则是正则表达式编译器的整数溢出，可导致未经身份验证的代码执行，评分 CVSS 10.0，影响从 7.0 起的 GitLab CE/EE。原文称 GitLab.com 和 GitLab Dedicated 已修复，但没有列出自建版应升级到的具体版本。

它处理的是运行时和部署配置，依赖声明改对了，还得确认生产环境真的用上了修复版本。

五步流程，比一句「帮我升级」多了什么

三个技能都采用同一套流程。

第一步只读盘点。Agent 扫描 Dockerfile、基础镜像、发行版软件包、CI，以及 Helm、Terraform、Packer、Lambda 和配置管理文件，寻找真正决定运行版本的位置。

第二步由用户选择需要处理的仓库。确认之前不修改，涉及风险更高的次版本或主版本升级时，先提示风险。

第三步核实目标。镜像 tag、digest、软件包版本和校验和，都要在编辑前对照官方来源确认。这里的 digest 是镜像内容的固定标识；如果部署锁定了它，只换 tag 并不能完成升级。

第四步在当前版本上先跑测试，再到新的生产镜像里跑测试。出现回归就停止。先测旧环境，是为了分清失败原本就存在，还是升级引入的。

第五步，每个仓库提交一个 PR，附上版本变化、测试结果、运行时差异、风险标签和回滚方案。

原文还列了几个容易漏掉的细节。Debian、Ubuntu 会把安全补丁回补到旧版本，不能只凭 php -v 判断是否修复。例如 Ubuntu 24.04 的已修复软件包版本是 8.3.6-0ubuntu0.24.04.13。修改 Composer 的 require.php 也不会安装或替换 PHP 运行时，它只是改变兼容性声明。

这些规则的价值，是把容易被省略的检查写进执行流程。但原文没有提供他们团队内部修复的样本量、耗时或成功率。

怎么接入现有的 AI 编程工具

插件能在读取 SKILL.md 的 Agent 中使用。原文列出的工具包括 Devin、Claude Code、Codex、Cursor、Factory Droid、GitHub Copilot、Gemini CLI、OpenCode 和 Windsurf。执行需要 git、shell、Docker，以及 registry 访问权限。

其他 Agent 可以通过下面的命令安装技能：

npx skills add CognitionAI/devin-vuln-fixes

注意安装前提：这条 npx skills 命令需要 Node.js 22.20 或更高版本。这个门槛是安装工具的要求，不能当成安全修复版本。

Devin 用户可以进入 Customize → Plugins → Browse Marketplace，搜索 Vulnerability Fixes；CLI 命令是 devin plugins install CognitionAI/devin-marketplace#plugins/devin-vuln-fixes。Claude Code 用户则先添加 marketplace，再执行 /plugin install vuln-fixes@cognition-skills，原文没有给出添加 marketplace 的具体命令。

安装后可以用自然语言提出修复要求，也可以执行 /fix-php-vuln、/fix-node-vuln、/fix-gitlab-vuln。

它与 Dependabot、Copilot Autofix、Snyk Agent Fix 解决的问题相邻，但落点不同。按原文对比，Dependabot 主要修改依赖清单、锁文件，也覆盖 GitHub Actions；后两者分别处理代码扫描告警和 Snyk Code 发现的问题。这个插件关注基础镜像、系统软件包与基础设施即代码，适合补上应用依赖扫描之外的一层检查。

我的判断

我认同它把只读盘点、目标核实和前后测试放进修复流程。对 Node 服务而言，仓库里的版本约束、CI 使用的版本和生产镜像里的版本可能各由不同文件决定，只改一个位置很容易留下缺口。

但「测试通过」能证明多少，取决于测试覆盖了多少。业务用例跑通，不能单独证明漏洞已经消失；目标包是否包含补丁、部署是否真正切换，同样需要证据。原文也明确说，托管运行时、设备型产品和 Electron 应用只会被标记，不会自动修补。

目前可以认可它的流程设计，不能据此认可它的修复成功率。

原文没有发布基准测试，也没有与 Dependabot 等工具做同任务对照。所谓效果更好、节省多少时间，都没有数据支撑。对只涉及锁文件的小型项目，现成依赖更新工具可能更直接；对版本散落在镜像和部署配置中的项目，这组技能才更值得评估。文中的漏洞信息和版本号也应在实际操作前按官方公告核实。

能拿来做什么

• 给 Node 服务排查安全升级时，同时检查 Dockerfile、CI 和部署配置，把「生产最终运行哪个版本」作为验收项。
• 让 Agent 先输出受影响仓库、版本位置和建议目标，审阅后再修改；涉及跨主版本升级时，单独评估兼容性。
• 在旧环境和新生产镜像中分别运行现有测试，并在 PR 中保留结果、镜像 digest 和回滚办法，方便审查与部署。
• 遇到 Electron、托管运行时或设备型产品时，把插件输出当作排查线索，继续确认对应供应方的修复路径。