安全事件接连发生：AI 时代，我们该如何保护自己？
最近的网络安全事件，让人感觉安全更新通知怎么也看不完。PHP 底层漏洞刚引发紧急修复，AI 开发者常用的 LiteLLM 又发生了供应链攻击。那些平时放心交给工具处理的环节，现在都值得重新检查。
AI 能帮我们写代码、读邮件、调用云服务，也让数据与权限流经更多系统。这篇文章想从近期案例出发，讨论普通用户和小团队怎样调整工作方式，减少一次疏忽引发的连锁损失。
资料核对截至 2026 年 10 月 29 日，台北时间。 本文分析官方公开资料，未对涉事系统开展实测；案例与建议分别说明，事件调查仍可能更新。
几起近期事件，暴露了不同的问题
PHP：运行时的漏洞，会传导到上层业务
PHP 官方在 10 月 21 日公布两项可能导致未认证远程代码执行的严重漏洞，并发布安全更新。漏洞位于运行时，只更新网站插件或应用依赖，可能并没有修复真正的问题。官方随后又在 10 月 23 日和 26 日补充了特殊配置及 Windows 依赖组件的注意事项，需要继续跟进。PHP 官方公告及后续更新
对于网站维护者，更实际的问题是：哪些服务使用了这个组件？谁负责修复？如何确认生产环境已经运行修复后的版本？ 平时缺少资产记录，紧急时就容易边排查边猜测。
LiteLLM：未吊销的密钥，最终影响了软件发布
LiteLLM 在 10 月 21 日发布了被植入恶意程序的 1.107.0 软件包及相关容器镜像，官方指出它们涉及凭据窃取和远程代码加载。判断是否受影响，需要核对具体制品、版本以及执行记录。官方影响范围和处置公告
10 月 23 日的官方复盘明确了攻击链：曾经提交到公开仓库的管理密钥没有被吊销，攻击者借此获取权限过大的 GitHub 凭据，进一步控制了发布流程。早期公告中的部分推测也被修正。从文件里删除密钥后，还必须让密钥本身失效。官方攻击链分析
AI 滥用报告：重视案例，也尊重证据的范围
Anthropic 的 2026 年 9 月威胁报告记录了借助 AI 侦察、开发工具及编排攻击流程的案例，覆盖其在 2025 年 12 月至 2026 年 8 月期间阻止的活动。这些是供应商观察到的精选案例，不能直接推算全球攻击增长率，也不能证明前述 PHP 或 LiteLLM 事件由 AI 发起。Anthropic 原始报告
AI 放大了速度、权限和损失之间的关联
结合这些材料，我的判断是：AI 让原本就重要的管理问题，更容易在短时间内产生更大影响。 主要体现在三个方面。
第一，重复工作的成本降低。 工具可以辅助整理目标、生成内容和迭代代码，攻击者便有机会用更少的人力尝试更多路径。仅凭“我的网站很小”来判断风险，越来越不可靠。
第二，工具授权成为关键边界。 假设一个 AI 助手同时能够读取邮件、查询客户数据、运行程序和发送消息，那么一份恶意文档就可能影响后续操作。这是解释风险的假设场景，实际影响取决于系统授予它的能力。
第三，被盗资源可能直接产生费用。 能调用付费服务的 API 密钥，同时关系到数据安全、账单和服务额度。小团队同样拥有值得保护的账号、算力与客户信任。
普通用户：先保护账号，再决定交出哪些数据
我会先检查主邮箱。它往往是其他账号重置密码的入口，需要独立密码，也要保护账号恢复方式。服务支持时，可以优先使用 Passkey（通行密钥）。FIDO Alliance 将它列为抗钓鱼认证方式，但恢复流程和设备安全仍要一起考虑。FIDO 官方说明
接下来，可以固定几个习惯：
- 自行打开官方应用或书签处理通知。 遇到付款、变更账号或索要验证码的要求，用原本就知道的联系方式核实，别只依赖对方提供的链接和身份说辞。
- 接入 AI 工具前，检查读写权限。 能限定到单个文件夹，就先限制范围；不再使用的连接授权要及时撤销。
- 只提供完成任务所需的数据。 能用脱敏片段解决，就先移除姓名、联系方式、客户记录与密钥，同时检查附件和元数据。
- 为重要文件保留独立备份。 云同步可能同步误删或加密后的结果，未必能满足实际恢复需求。
开发者与小团队：让最小权限真正生效
AI 助手修改一个项目，通常可以通过该项目的有限权限完成。若整个组织的管理员凭据、生产数据库和部署权限都集中在同一工作环境中，误操作或入侵就更容易扩散。
这里还涉及提示词注入：网页、邮件或文档可能藏着改变 AI 行为的指令。OWASP 建议采用最小权限、隔离外部内容以及人工审核高风险操作等措施；授权检查要由工具和服务端执行，不能仅靠提示词约束。OWASP 风险说明、防护实施指南
我会优先安排这些工作：
- 分别管理开发、测试和生产密钥。 使用权限受限、可以吊销的凭据；疑似泄露时，吊销并检查使用记录，删除公开文件并不足够。
- 记录实际部署的内容。 保留依赖版本、锁文件及容器镜像摘要。固定版本方便追溯和控制变更，但仍要核查该版本的安全状态。
- 按风险安排更新。 官方要求紧急修复、已被利用、直接暴露于公网或接近敏感数据的问题应优先评估，同时核实来源和受影响制品，避免把自动追新当成完整防线。
- 验证数据访问和重要操作的边界。 例如用户甲不能读取用户乙的数据；删除生产数据、付款和修改权限时，展示具体影响，由有权人员确认。
- 关注异常访问和费用。 检查异常登录、权限变更、数据导出和 API 用量；确认预算告警是否会真正停止服务，别把提醒误当成硬性额度限制。
真正发生事件时，预先写好的流程很有用
如果出事当天才决定联系谁、暂停哪些服务、从哪里恢复，很容易在压力下遗漏步骤。小团队至少可以准备一页处置流程：
- 限制扩散，保留必要证据。 隔离受影响环境、限制可疑访问，保留时间线与相关日志，避免仓促清除痕迹。
- 在可信管理环境中吊销凭据。 检查密钥、登录会话、连接授权及可能关联的其他账号。
- 使用可信制品重建并验证。 处理漏洞和持续访问路径，测试数据、登录与关键功能，并继续观察异常。
- 按已确认的影响通知相关人员。 分清已知、未知和当前措施，避免把“尚未发现”写成“确定不存在”。
备份也需要真正还原过。美国 HHS 的勒索软件指南建议测试恢复能力，并考虑使用原网络无法直接访问的离线备份；这里引用的是技术建议。备份可以帮助恢复服务，已经被复制出去的数据仍需单独处置。备份与恢复建议
用 AI 辅助核查，也保留可验证的依据
AI 可以辅助整理官方公告、比对脱敏后的资产清单，以及生成修复任务。可以要求它列出来源、公告日期、受影响条件和未确认事项，再由人核对原文与实际环境。
普通用户可以先保护主邮箱、检查 AI 工具授权，再验证一份重要备份；开发者可以先找出权限最大的凭据、对外服务使用的组件，以及紧急时负责处理的人。
我希望 AI 节省的时间，也能用于这些平时容易拖延的基础工作。能清楚回答“工具能访问什么、谁能发现异常、出事后如何收回权限”，使用新工具就会更有把握。
