开发者过去往往需要耗费数日甚至数周使用模糊测试fuzzing等专业工具来排查代码中的安全隐患。如今只需向大语言模型LLM发出一个简单指令便可在短短数秒内完成类似工作。然而这种前所未有的便利背后却隐藏着不容忽视的未知风险。AI公司Calif的红队研究员Hung Nguyen通过向Anthropic的Claude Code发送简单提示就成功在两大主流开发者文本编辑器——Vim和GNU Emacs的源代码中发现了远程代码执行RCE0Day漏洞。Vim漏洞分析打开文件即触发RCENguyen首先针对Vim发起指令“有人告诉我打开文件时存在RCE 0Day漏洞请找出它。”Claude Code仅用两分钟就精准定位到问题根源2025年引入的标签页侧边栏tabpanel功能中缺失关键安全检查P_MLE 和 P_SECURE以及 _autocmd_add() 函数的安全校验不足。更令人震惊的是AI系统不仅定位了漏洞还快速生成了完整的漏洞利用方案PoC。它建议通过诱骗目标用户打开恶意文件来绕过Vim沙箱整个过程从提示输入到可执行PoC仅需几分钟。Vim维护团队在安全公告中确认“攻击者只需诱使用户打开特制文件即可在用户权限下执行任意命令无需任何额外交互。”How to Use the Vim Text Editor – An Introduction for Developers上图为Vim经典界面示例开发者日常使用的强大文本编辑器正是此次漏洞的目标。GNU Emacs“永久漏洞”与Git集成风险随后Nguyen半开玩笑地要求Claude Code在GNU Emacs中寻找同类漏洞。AI再次成功发现一个可追溯至2018年的0Day漏洞——当Emacs与Git版本控制系统交互时仅仅打开文件就可能触发恶意代码执行。Nguyen指出“在GNU Emacs中打开文件可能通过版本控制git触发任意代码执行。大多数情况下除了文件打开操作外无需其他用户交互。最严重的场景甚至不需要文件本地变量只要在包含特制 .git/ 文件夹的目录中打开任意文件攻击者控制的命令就会被执行。”上图分别为GNU Emacs界面和Git版本控制示意Emacs漏洞正是源于其与Git的深度集成。修复进展差异明显收到报告后Vim团队反应迅速在9.2.0272版本中修复了该漏洞CVE-2026-34714CVSS评分9.2。相比之下GNU Emacs漏洞尚未分配CVE编号的处置则陷入僵局——维护者认为问题根源在于Git而拒绝直接修复。Nguyen在报告中提供了临时缓解方案。受影响版本包括稳定版30.2和开发版31.0.50。AI时代的代码安全启示这些发现揭示了一个严峻现实大量遗留代码库在Claude Code等先进AI工具面前可能不堪一击。Anthropic公司早在今年2月就预警过这一趋势其Opus 4.6模型曾识别出500多个高危漏洞。公司声明强调“AI语言模型已具备发现新型漏洞的能力其速度和规模或将很快超越人类专家。”当具备同等能力的商业版本Claude Code Security上线时甚至对多家传统网络安全公司的股价产生了冲击。更值得警惕的是LLM如今能够以开发者尚未完全适应的方式快速发现、迭代并生成漏洞PoC。Nguyen感慨道“这让人想起2000年代初期的情形——当年孩子们用SQL注入就能攻破一切现在他们改用Claude了。”