我的安全视界观

2026年6月，Varonis披露了Microsoft 365 Copilot的一个高危漏洞链——攻击者只需在合法Copilot URL的q参数中嵌入恶意指令，诱导用户点击一次链接，即可在用户无感知的情况下窃取其所有Copilot可访问的企业数据（邮件、会议记录、文档、2FA验证码），并通过图片URL外传。 这不是一个普通的「代码bug」，而是LLM固有特性导致的系统性问题——AI无法区分「用户指令」和「第三方内容中的恶意指令」。这次漏洞标志着AI安全从「理论风险」正式进入「实战可利用」阶段。 对企业而言，这带来了三个核心警示：传统安全技术无法解决AI指令边界问题；提示注入将成为AI部署的头号威胁（门槛极低，任何会写Prompt的人都能发动攻击）；以及「AI就绪」绝不等于「AI安全就绪」——在AI部署之前做完安全评估，而不是「先上线再补漏洞」，这是每家企业都应该尽快建立的基本认知。 SearchLeak只是一个开始。2026年下半年，会有更多AI实战化漏洞被披露。企业安全团队，现在就得动起来了。

一个恶意URL，无需用户交互，即可劫持AI Agent在宿主机上执行任意代码——这是微软2026年6月18日披露的AutoJack攻击。 该漏洞链横跨三个CWE：CWE-1385（Origin验证被Agent浏览器绕过）→ CWE-306（MCP路径认证缺失）→ CWE-78（URL参数直接执行系统命令）。 核心问题在于，AI Agent既能浏览互联网，又能与本地特权服务通信，"localhost=可信"这一传统假设被彻底打破。 修复方案（commit b047730）将参数存储改为服务端绑定、收紧认证skip-list，但根本性风险依然存在：当Agent成为人机交互的主界面，它同时也成了攻击者的入口。 这不是某个函数的bug，而是整个系统设计假设的失效。AI Agent安全已从"理论风险"进入"可实战利用"阶段，安全左移已非可选，而是必选。

2026 年 6 月 12 日，全球 WordPress 生态遭遇了一场典型的两步跳供应链攻击：攻击者先利用营销服务器上第三方插件 UpdraftPlus 的已知漏洞入侵，窃取存储于该服务器的 CDN API 密钥，随后通过 CDN 直接向 OptinMonster（100 万+ 活跃安装）、TrustPulse、PushEngage 三款插件的 JS 文件注入恶意代码，全球数百万 WordPress 站点在约数小时暴露窗口内受影响。 恶意 JS 在管理员登录态下激活，创建隐藏管理员账户、部署 Web Shell 外泄站点凭证，后门伪装成 "Content Delivery Helper" 等正常插件名称。 这次事件最值得拆解的失误是：营销服务器（非核心业务）上存储了拥有 CDN 写入权限的 API 密钥。攻击成本极低——找一个漏洞插件，就能撬动百万量级的下游。 官方公告的那句话值得每个做企业安全的人贴在墙上："Remediating our systems does not clean a site that was already compromised"——修复感染源不等于修复客户系统。

数据勒索/敲诈团伙ShinyHunters利用CVE-2026-35273（CVSS 9.8，SSRF→RCE）对全球约100家组织实施攻击，其中68%为高等教育机构。该漏洞无需认证、无需交互，只要网络可达即可接管服务器。从5月27日攻击启动到6月10日Oracle发布公告，零日窗口约14天。 攻击者部署MeshCentral远控代理（伪装为Azure服务），通过SSH凭证喷洒横向移动，使用zstd压缩数据外传至ShinyHunters泄露站。诺丁汉大学确认数据泄露已被发布。 这起事件让我感触最深的是：攻击的起点往往就是一个"我以为关了但实际还开着"的端口。PSEMHUB不该暴露在互联网上，但100多家机构就这么暴露着。CAASM持续监测暴露面的价值，在零日攻防中被充分验证。 同时，Mandiant在公开披露前向100+家组织发出预警、部分组织成功阻断——这证明外部情报订阅+内部资产关联是压缩零日响应窗口的关键能力，而不仅仅是靠补丁速度。

2026年6月5日，Include Security与独立研究员Buchodi发布技术分析报告，揭露以色列公司Bright Data通过SDK植入方式，将全球数亿台智能电视和移动设备转化为住宅代理节点，为AI公司提供爬虫流量中转服务。 这个事件最让我不安的是，它用"合法商业"的外壳，把普通用户的设备变成了网络基础设施的一部分，而且是在用户毫不知情或无法理解技术含义的情况下完成的。 从企业安全视角，我们以为"VPN + 防火墙"就够了，但实际上员工设备上的SDK可以绕过所有这些防护。企业需要开始关注设备层面的流量审计。

2026年5月，RedAccess发布研究报告，披露Shadow Builders事件： 使用Lovable、Base44、Netlify、Replit等主流AI编程平台（Vibe Coding）开发的应用中，存在大规模敏感数据暴露问题。 38万+公网可访问应用中，5000+存在安全问题，2000+已确认暴露敏感数据，覆盖航运、医疗、金融、政务等六大洲多个行业。 虽然国内可能还不多，但是本事件折射出AI编程时代的安全治理代际差问题：Vibe Coding将应用开发从专业团队下沉到业务人员，这个转变在数周内完成，但企业安全能力建设可能需要数年。 传统安全工具（EDR/DLP/CASB）在Session层面前近乎失效，攻击发生在Session层而防御部署在端点层，两者之间是一片无人区。 解决之道不在于禁止AI编程，而在于建立适应AI时代的治理框架：承认Shadow Builders已经存在，在Session层建立可见性，持续治理而非一次性清理。

供应链攻击已经进化到「精准投毒+凭证窃取+横向渗透」的组合拳模式。攻击者不需要零日漏洞，不需要高超的漏洞利用技术，只需要找到开源项目维护流程中的一个疏忽时刻。 最令人担忧的是攻击的复制成本极低。一旦攻击者掌握了orphan commit技术，可以批量攻击数百个开源项目。防御方需要为每个项目建立防护，而攻击方只需要找到一个薄弱环节。 如果同样的事情发生在我们公司，我们能在多长时间内完成同样的响应？我们有没有类似的自动化密钥轮换系统？我们的异常检测系统够不够灵敏？我们的应急响应预案在哪里？上次演练是什么时候？ 每个安全负责人都应该定期问问自己这些问题。答案决定了我们能否经受住下一次供应链攻击的考验。

Anthropic正式发布其最强AI模型Claude Fable 5与Mythos 5，首次采用"同一模型、双版本分发"的安全分层策略。Fable 5面向公众开放，搭载安全分类器拦截网络安全相关请求；Mythos 5解除限制，仅限受信机构使用。 此前Project Glasswing已借助该模型发现超1万个高危漏洞，Mythos甚至能从17年前的漏洞自动编写RCE利用程序。 作为安全从业者，我认为这标志着一个关键转折点：AI将漏洞发现速度提升数个数量级，但修复仍依赖人工，"发现-修复"的天平正在失衡。 更值得关注的是，英国AISI已短时间取得通用jailbreak进展，Anthropic也承认"完全防止几乎不可能"——这意味着未来某个prompt就可能让公众版AI变成全能黑客工具。当AI找漏洞的能力变成"基础设施级"能力时，整个行业的攻防天平将永久倾斜。

2026年3月下旬，Anthropic 一周内连续两次"手抖"： 第一波（3月26日）：CMS 配置错误，近 3,000 份内部文件暴露，含未发布模型 Claude Mythos（Anthropic 自述"网络安全能力远超任何其他 AI 模型"）。 第二波（3月31日）：npm 发布 @anthropic-ai/claude-code v2.1.88 时遗漏 source map 过滤，59.8MB .map 文件暴露 51.2 万行源码，GitHub 社区 4.1 万 fork 疯狂传播。 从企业安全视角，我们习惯关注 APT、零日漏洞、供应链攻击，却往往忽视一个更基础的问题：发布流程的可靠性。 Claude Code 的架构设计令人叹服 - - 46K 行查询引擎、40+ 工具权限门控、多 Agent 编排、Bun 运行时、React + Ink 终端 UI。但一个忘记勾选的配置，就让所有努力付诸东流。 这个事件值得每一家 AI 公司引以为戒：当你的模型能力越来越强，你的流程是否也同步变强了？

2026年6月2日，安全初创公司depthfirst宣布其自主AI安全代理在FFmpeg多媒体框架中发现了21个已确认的零日漏洞。这一发现标志着AI驱动的安全研究已经进入实战阶段。 关键数据：约1,000美元成本，扫描约150万行C代码，发现21个零日漏洞，每个都附带可复现的PoC。部分漏洞潜伏时间长达15-20年，涉及堆溢出、栈溢出、整数溢出等多种内存安全漏洞。 FFmpeg作为全球使用最广泛的多媒体处理库之一，被应用于浏览器、流媒体平台、监控系统、移动应用和嵌入式设备。这意味着这些漏洞的影响范围极大，全球数百万应用和设备可能受到影响。 从安全专家视角来看，这一事件带来三重启示： 其一，AI代理的安全研究效率远超传统人工审计，但攻击者同样可以使用相同技术； 其二，开源软件供应链安全需要更系统的管理和监测机制； 其三，安全团队需要升级能力，学习AI安全技术，建立人机协作的新范式。 FFmpeg安全团队已确认漏洞存在并着手修复。作为企业安全负责人，建议立即盘点内部FFmpeg使用情况，建立SBOM清单，升级到最新版本，并持续关注官方安全公告。 AI时代的安全形势正在加速演变，唯有主动拥抱技术变革，才能在这场攻防博弈中占据先机。

提示注入漏洞让一个 GitHub Issue 变成了供应链核弹——影响面 ~1.7 万个仓库，而修复窗口只有 4 天。 真正的风险不在于这个漏洞本身，而在于：当 AI 编程代理大规模进入企业 CI/CD 流水线之后，类似的提示注入漏洞会成为攻击者的标准入口。我们现在不把安全框架建立起来，等出事的时候就晚了。 给企业安全团队的三条硬建议： 1、立即做资产清点 有没有在用 GitHub Actions？有没有引入 AI 编程代理（Claude Code / Copilot Agent / 其他）？ 如果答案是"有"，先搞清楚权限范围是什么——别等出了事再翻日志。 2、最小权限 + 零信任，现在就做 1）AI 代理只给完成任务所需的最小权限，多一个 scope 都不行 2）Pin GitHub Actions 到 commit SHA（防止 tag 被移动投毒） 3）敏感凭证（npm token、API key）与 AI 代理隔离，别让它能读到 /proc/self/environ 3、 建立 AI 代理的审计和应急响应机制 1）启用 GitHub Actions 审计日志，监控异常的工作流触发 2）制定预案：当 AI 代理被入侵时，如何快速吊销凭证、隔离受影响仓库、回溯攻击链？ #AI编程代理#供应链攻击

看到 CVE-2026-0257（PAN-OS GlobalProtect 认证绕过）的细节，利用链和应急响应动作，一切都是那么熟悉。 边界类产品的暴露面最大——必须开放端口、接受外部连接、拥有最高权限。它们是攻击者的首选目标，应急响应优先级应该是最高之一。 安全团队也不能"灯下黑"。 我们天天提醒业务团队打补丁、限制访问、开 MFA， 却往往忽视自己管理的边界类、集权类安全产品： 1、防火墙/VPN 控制台暴露公网，补丁延迟打； 2、EDR/XDR 控制台"只有内网能访问"，就放松警惕； 3、漏洞扫描器、IAM/SSO 自身安全性被遗忘。 做好防护，不止是限制 IP 访问。还要加强： 1、异常行为监测：关键 API（登录、配置修改）的异常调用； 2、账号行为审计：重要账号的操作日志、基线行为模型、实时告警。 #安全产品#漏洞利用#安全事件#PaloAlto

2026年5月，安全公司Push Security披露了一起针对ChatGPT用户的新型供应链攻击——LLMShare。攻击者利用ChatGPT的共享功能（chatgpt.com/s/）托管恶意HTML页面，并通过Google广告精准投放，诱导用户下载伪装成"ChatGPT桌面应用"的恶意软件。 与传统钓鱼攻击不同，这次攻击的核心在于滥用可信平台：恶意内容完全通过ChatGPT官方域名渲染和托管，用户看到的是"chatgpt.com"的链接，天然放松警惕。这种"借壳"攻击方式，标志着AI平台正在成为新的攻击面。 这起攻击最值得警惕的，不是技术手段有多高明，而是攻击平台的演变。过去，攻击者要搭建一个可信的钓鱼网站，需要注册域名、部署服务器、申请SSL证书——每一步都可能暴露痕迹。现在，他们直接利用OpenAI的官方域名来托管恶意内容，成本极低，隐蔽性极强。 对于企业安全团队来说，这意味着"域名可信 ≠ 内容可信"的旧假设正在失效。我们需要重新划定信任边界，不能因为内容托管在知名平台就放松警惕。 更值得思考的是：这种攻击方式会不会蔓延到其他AI平台？Anthropic的Claude、Google的Gemini、百度的文心一言——它们的共享功能是否也存在类似漏洞？ AI安全，不只是防止AI被攻击，还要防止AI平台被滥用。 #安全事件#LLM攻击

2026年5月11日，知名TanStack开源库遭供应链劫持，攻击者通过钓鱼获取维护者OIDC令牌，向62个官方包植入凭证窃取代码。该库周下载量逾1200万次，恶意版本在数小时内完成全球扩散。OpenAI两名员工终端恰在此窗口期中招，导致少量代码仓库凭证泄露。 此事虽未酿成灾难性后果，却暴露出软件供应链的深层脆弱性：一次精准钓鱼 → npm账户沦陷 → 全球依赖链污染 → 大型企业员工终端被突破。整个杀伤链中，企业自身几乎无防御抓手。 作为安全从业人员，我认为最值得警惕的不是"OpenAI也被黑了"，而是这次攻防的时间差：传统"定期扫描"模式对此类速闪投毒完全失效。真正有效的防御必须是实时、自动化的。给同行三点建议： 1、引入SBOM及实时SCA，将开源依赖可视化为资产； 2、开发终端零信任化，持续加强终端安全检测-异常行为； 3、与关键开源社区建立直连应急通道，争取在投毒窗口前的预警时间。 此次OpenAI的应急响应可圈可点——迅速轮换签名证书、强制macOS用户更新——体现了风险意识。但对更多企业而言真正的考题是：当你的核心业务依赖万千开源组件时你能在攻守时间差中守住几道防线？

AI真强，从事产品安全的我们

网络安全从业人员使用AI遇到的困境

时光荏苒~之前，看到很多人都感叹时间过得太快，这次轮到我了。这是我的首个十年工作总结，主要事件、主要作品及主要感悟，虽零散但是我世界中闪亮的星。

2026校招面试，也许是因为这项工作占据了我很多时间，并且刚阶段性的落幕；或许还因为多年来我接触了很多毕业时能力参差不齐的校招生，对于他们的发展有一些观察与思考。

截止2025国庆节前夕，SDL100问系列文章已经完结，也意味着SDL三部曲（SDL最初实践、SDL100问、SDL创新实践）已输出超过2/3。虽说时间比预期多花了1倍，不过好在顺利完成。一个阶段的结束，这对自己来说也是新的开始~

在回顾该问题时，发现提问者并没有把问题定位得很清楚，导致在没有人追问的情况下，大家给出的应答也不具体。说它不清楚在于内部漏洞，在我看来至少有两个主要来源： 1、产品发布上线前各类安全测试发现的漏洞：这种情况其实有比较明确的修复要求，至少是要在系统发版前完成修复，如果做得更好的话，也可以制定明确的修复时间来推动业务方修复，但这个时间一定是要与发版时间相比较，把短的用来做deadline； 2、产品或内部资产运行状态下日常漏扫漏洞：这类漏洞主要是针对内部资产或外部互联网侧的应用，缺少明确的时间参考系，所以要制定修复时间，可以细分出优先级。比如互联网侧的信息系统修复时间要求比内网的短，高危漏洞比低危修复时限要求短，从执行来看互联网系统按照几天甚至几小时比较合适、内网系统按照几周或1个月比较合适。 针对逾期修复的情况，可以在内部做红黑榜进行推动，可以设置安全风险分数（逾期修复天数*漏洞风险等级对应的权重*存在漏洞的资产重要性对应权重），然后按照部门进行风险分数计算并在全公司晒榜，以此激励大家修复漏洞。 ------------更多内容，请访问------------- 1、SDL 100问 SDL100问：我与SDL的故事 SAST误报太高，如何解决？ SDL需要哪些人参与？ 大家都有哪些SDL运营指标？ 开发安全左移和右移，哪一个更好？ SDL 99/100问：如何进行软件安全需求分析？ 2、SDL创新实践 首发！“ 研发安全运营 ” 架构研究与实践 DevSecOps实施关键：研发安全团队 DevSecOps实施关键：研发安全流程 DevSecOps实施关键：研发安全规范 DevSecOps实施关键：研发安全工具 数字化转型下研发安全痛点 一个思考：安全测试驱动产品安全？ 3、SDL最初实践 【SDL最初实践】开篇 【SDL最初实践】安全培训 【SDL最初实践】安全需求 【SDL最初实践】安全设计 【SDL最初实践】安全开发 【SDL最初实践】安全测试 【SDL最初实践】安全审核 【SDL最初实践】安全响应 4、安全运营实践 基于实践的安全事件简述 安全事件运营SOP：钓鱼邮件 安全事件运营SOP：网络攻击 安全事件运营SOP：蜜罐告警 安全事件运营SOP：webshell事件 安全事件运营SOP：接收漏洞事件