AI加速网络攻防：从PHP漏洞到企业与个人的应对

一、主讲人与议题背景

《The Artificial Intelligence Show》的这期节目由Paul Roetzer与Mike Kaput主持，题为《The AI Cybersecurity Crisis Has Arrived - What to Do Now》，时长1,458秒，约24分钟。标题强调危机已经到来，但节目并未给出衡量整个互联网受损程度的统一数据。两位主持人通过梳理事件报道、引用专业人士判断和讨论应对措施，解释AI正在如何改变网络安全风险。节目中被引用的安全负责人并非因此就成为现场受访嘉宾。

Mike先介绍PHP漏洞与针对金融机构的攻击报道，再请Paul评估其严重性。Paul结合自家平台的维护经历，并引用技术机构与业内人士的说法展开讨论。他明确承认，两人都不是网络安全专家，需要借助专业人士理解事件的意义。这种讨论可以帮助业务负责人认识风险、提出问题，但其中的报道转述、Paul的个人推断和他引用的未来预测，各有不同的证据基础；表达的紧迫程度不能代替证据。

二、本期主要内容

Mike首先介绍了10月21日的PHP紧急安全更新。按他的转述，两项严重漏洞可能让攻击者无需登录，就取得易受攻击Web服务器的控制权。风险可能发生在账户认证之前，因此，用户是否设置强密码，并不能回答底层服务器是否需要修补。不过，这里指的是存在漏洞的系统，不能据此认定所有使用相关技术的服务都面临相同风险。

据Mike介绍，Calif研究人员使用了OpenAI模型，Wiz的另一支团队则使用OpenAI与Google模型。Wiz称，AI帮助研究者在数小时内，将复杂漏洞转化为能够跨应用运行的攻击。研究者验证漏洞能否被利用，是推动修复的一部分；同类能力进入攻击流程后，也可能缩短从发现漏洞到实施利用的时间。

但补丁发布前的利用活动，仍有几个关键问题没有答案。Mike说，Amazon在10月17日、即补丁发布前四天，就已发现利用尝试，却无法确认攻击是否在真实系统上成功，也无法确定攻击者如何获知漏洞。两位主持人同样不知道这些攻击者是否使用了AI。因此，可以确认的是修补前已有利用尝试，不能进一步断言这些攻击由AI实施。

针对金融机构的报道，则提供了AI参与犯罪分工的线索。Mike介绍的Cyber Cartel行动涉及拉美400多个金融目标：Claude代理分析攻击选项，Grok代理收集凭据及其他敏感信息；研究人员据称检查了相关工具，以及包含数千条被盗记录的清单。Mike随即说明，这不代表400家银行全部被攻破，也无法确定被盗资金的金额。这些报道所呈现的是AI被纳入有组织犯罪的不同任务，目标名单不能直接当作受害者名单。

节目还提到与Artechs有关、针对韩国金融组织的数据窃取，以及Microsoft披露的另一场针对数百家机构的行动。据报道，部分攻击不到三小时便取得高权限云访问，但大多数针对目标的攻击未能成功。其中，ConnectWise遭入侵后，其云备份服务成为攻击者进入客户Microsoft 365环境的路径。这也说明，评估自身风险时，除了检查网站和系统，还需要考虑供应商服务带来的连接与访问权限。

三、核心观点：推理、例子与边界

AI正在让网络攻防双方同时提速，但谁能先把能力转化为行动，仍决定着系统能否及时获得保护。发现漏洞、验证影响、制作补丁和完成部署环环相扣，任何一步都不能代替下一步。研究者发现问题，不代表服务运营者已经修复；防御模型变强，也不会让存量系统自动安全。Paul所说的竞赛，就发生在这些环节之间。

漏洞披露前的协调同样受时间约束。Paul引用Greg Brockman的说法称，相关方已围绕缓解措施协调约两个月，原定10月22日披露，但细节开始泄露，披露因此提前一天。从准备修复到把修复交付给运营者，中间还有大量协调工作；即使事先已有安排，披露时间改变后，各家的部署进度仍可能不同。补丁发布只是修复开始具备条件，不能被视为业务已经安全。

Cloudflare观察到的利用尝试，让这种时间压力更为具体。Paul引用Matthew Prince的数据称，公开宣布前十小时，Cloudflare网络已有数千次利用尝试；宣布后45分钟内达到数万次，两小时内达到数十万次，随后达到数百万次。这些数字反映的是利用活动迅速增加，并非受害者数量。Paul将其称为“AI规模”，但节目没有说明如何确认这些尝试使用了AI，仅凭流量规模无法得出这一归因。

修补也可能带来短暂的服务中断。Paul说，自家AI学院的供应商主动将平台下线安装补丁，约30分钟后恢复服务。在他的叙述中，这是维护措施，并非遭到入侵的证据。保持服务在线与减少系统暴露之间，可能需要作出取舍，业务团队也需要为维护中断做好解释和协调。不过，这次经历不能证明其他平台采取相同措施就足够，约30分钟的停机时间也不能套用到所有系统。

Paul还强调，AI发现了既有缺陷，并非制造了这些缺陷。按他的转述，问题位于PHP本身，而非某个托管应用的代码；相关漏洞已存在14年，2024年曾发现一个有限版本，但当时未被认为具有重大影响。AI改变的是发现和利用既有问题的能力。他还引用OpenAI的估计称，PHP运行于约70%的网站，并引用Brockman关于潜在代码执行风险可能波及几乎所有已部署PHP应用的说法。这些是有关技术影响范围的判断，不代表相应网站已经遭到入侵，更不能替代对具体系统版本和部署情况的核查。

对未来防御能力的期待，则带有更明显的预测成分。Paul转述Jason D. Clinton提出的约18个月预警，以及强大网络安全能力将进入廉价模型、用于开发阶段的预测，并将其理解为一场寻找和修补既有漏洞的竞赛。如果发现缺陷的成本持续下降，开发者可能更容易在发布前处理问题，但旧系统的修补仍然需要时间。这解释了Paul为何既强调眼前压力，又看好长期防御能力；它并不保证18个月后漏洞消失，也不能成为今天推迟维护的理由。

Paul关于较早预警的日期表述存在冲突：他先提到10月20日，又说是三个月前，随后提到8月20日，无法据此排出准确时间线。他谈及政府或NSA使用Mythos排查系统时，也明确使用了推测性表述，不能写成已经证实的行动。节目支持的判断是，防守方需要争取在攻击者利用漏洞之前完成发现和修补；具体事件记录、对AI作用的推断与未来预测，仍需分别看待。

四、学习与应用

对组织而言，应对首先要落实到具体资产。Paul转述的NSA建议包括：为更新做好准备，盘点与PHP有关的互联网暴露设备和服务，优先安装供应商补丁；如果无法立即更新，考虑暂时下线。技术团队可以据此记录每项服务的运行环境、维护方、补丁状态和待确认事项。这份清单不能证明系统安全，却能帮助负责人明确该联系谁、哪里需要升级，以及哪些问题尚未查清。

盘点还要覆盖容易被遗忘的系统。Paul提醒，多年前建成、如今很少使用的网站，也可能仍然暴露在外。检查范围因此需要涵盖旧活动站点和仍在使用的外部服务，并明确由谁确认版本、安排维护。他建议依靠可信的内部技术团队或外部伙伴快速响应。业务负责人不必独自判断底层技术，但需要确保问题有人处理，结果也能反馈到业务决策中。是否暂时下线，应结合实际暴露情况、可用修复措施与业务中断代价判断，不能将原则性建议执行为所有服务一律停机。

Will Reynolds的案例展示了AI辅助排查的速度。按Paul引用的公开自述，Reynolds让Claude Code检查639家客户公司的网站，通过网页头部、页面代码与博客收集线索，比对版本，并在约2.5分钟内生成附有证据的CSV。结果据称包括208个带有PHP迹象的网站，以及5个确认运行易受攻击版本的网站；其中3个版本过旧，已无法获得官方修复。这个案例提供了一套可借鉴的流程：整理资产、收集线索、比较版本、保留证据，再安排核查。它不能用来推算扫描工具的通用准确率。

节目没有提供完整扫描方法或独立验证过程，外部页面呈现的技术迹象，也不足以说明底层状态已经全部查清。AI可以先整理待核查清单，再由维护方确认版本和处理方式。对于被报告为版本过旧、没有官方修复的系统，负责人还需要评估后续处置，不能止于等待常规补丁。只有排查结果交到有权限、有责任的维护者手中，节省的时间才可能转化为实际修补。

个人防护则涉及节目讨论的两类风险：泄露资料可能让诈骗更具迷惑性，重复使用密码可能使一个旧网站的问题扩散到其他账户。主持人建议更新设备和浏览器，断开不再需要的联网设备，保护银行账户，并使用双因素认证和通行密钥。这些措施分别作用于设备、账户和日常防范，不能据此判断某个网站的服务器是否已经修补。面对包含真实个人资料的消息，也不能仅凭对方掌握这些信息就认可其身份。

Mike还介绍了一个受Ethan Mollick启发的提示词示例：让具备计算机使用能力的助手检查个人账户和已安装软件，列出需要采取的行动。他明确将这一示例限定于个人，而非企业。借鉴时，可以先规定检查范围和允许接触的账户，让助手形成建议，再决定后续操作；个人示例并不构成企业开放广泛访问权限的依据。Paul随即提醒，代理可能访问用户没有指定的网站，也可能采取用户未明确要求的行动。因此，使用AI辅助审计时，仍须关注它的自主权限、访问目的地和可接触的信息。审计助手自身的访问范围，也需要接受检查。

来源

• 原始节目：The AI Cybersecurity Crisis Has Arrived - What to Do Now