IBB 计划于 2013 年启动，被广泛视为开源社区最重要的漏洞奖励计划之一。自今年3 月27日起，该计划暂停接收新的漏洞提交报告，HackerOne 给出的原因是漏洞发现的速度与开源维护者修复漏洞的能力之间的失衡正日益加剧。

HackerOne 表示：“漏洞发现的情况正在发生变化。AI 辅助研究正在扩大整个生态系统中漏洞发现的覆盖面，同时提升了发现的速度。开源领域在漏洞发现量与修复能力之间的平衡已经发生了实质性转变。”因此需要重新思考 IBB 这类众包模式项目的结构和激励机制。

紧接着开源 Node.js 项目的维护者也暂停了他们自己的漏洞奖励计划，原因是此前通过 HackerOne 获得的资金已经中断。维护者解释称：“作为一个由志愿者驱动的开源项目，Node.js 没有独立的预算来独自维持一个漏洞奖励计划。”

多位安全专家认为，这些变动虽然影响重大，但考虑到 AI 辅助漏洞发现技术的快速发展，也并非意料之外。SOCRadar 公司的首席信息安全官 Ensar Seker 表示，“这是在AI压力下，漏洞奖励生态系统所做出的一项合理、甚至可以说是早就该做的调整。HackerOne 实际上是在承认瓶颈已经发生了转移：漏洞发现已经被 AI 工业化，但修复能力并没有相应地跟上。”当 AI 能在几小时内生成成千上万个中低质量的发现结果时，开源项目的维护者（通常是资金有限的志愿者）很容易就会被压垮。他提到，“所以没错，HackerOne 说得完全在理：这不是从安全上退缩，而是一次在‘信号与噪声’之间重新寻求平衡的尝试。”

Minimus 公司联合创始人兼首席信息官 John Morello 表示，随着 AI 生成的“垃圾内容”大量涌入，漏洞报告的有效提交率已从大约 15% 下降到了 5% 以下。“AI 辅助的漏洞挖掘不一定能发现更多严重 0day 漏洞；相反，它完全把瓶颈转移到了验证环节，迫使漏洞分类审核团队在海量听起来像那么回事、但实际上无法利用的报告中进行艰难的筛选。”他说。

对于开源项目的维护者来说，“分类审核疲劳”已经成为最大的挑战，他们为了反驳那些凭空捏造的漏洞，就要耗费数小时的开发时间。“不幸的是，当前的漏洞奖励模式在奖励数量而非深度，这实际上等于把无偿劳动武器化，迫使这些小型团队为全球每一台自动化扫描仪充当免费的 QA 部门。”Morello 说。

HackerOne 表示，他们现在的重点是寻找新的途径，以实现让漏洞发现与有效的修复工作相匹配的最初目标，“从而让有意义的发现成果能够为开源项目带来持久的安全改进”。为此，HackerOne 将与项目维护者和研究人员合作，评估各种方法，使激励机制更好地适配开源生态系统的实际情况。

同样运营着众包漏洞发现平台的Bugcrowd的首席战略与信任官 Trey Ford 认为，HackerOne 的决定是一个警钟。“我们得搞清楚，这次暂停真正释放的信号是什么：行业花了多年时间，一直在优化漏洞管道的错误一端。”他说。在压缩漏洞发现所需的时间方面，AI 确实做到了它应该做的事情。“但我们还没有解决的，是方程式中的人这一侧：维护者在收到 40 份有效报告后，只有一个周末的时间来响应。”Ford 说。

现在需做的是以投入漏洞发现的同等紧迫性，加大对漏洞修复能力的投入。“漏洞研究与披露的经济学正在发生变化。AI 降低了漏洞发现的准入门槛，这意味着原始数量不再是研究人员的竞争优势。”Ford 指出。溢价空间将越来越多地向复杂的逻辑缺陷和新颖的攻击链转移，这些需要机器无法复制的人类深度分析与上下文判断能力。“下一代漏洞计划可能会为那些不仅报告漏洞、还能同时提供修复方案的研究人员提供额外奖金，并设立共享资金池，同时资助发现漏洞的研究人员和负责发布补丁的维护团队。”

修复并非唯一的挑战。正如 FusionAuth 公司的产品副总裁 David Hayes 所指出的，围绕人工节奏的漏洞奖励计划正在以远超预期的速度消耗资金。他表示，“当前的运行模式不可持续。”漏洞奖励是为这样一个世界设计的：漏洞发现本身才是瓶颈。现在，漏洞发现正日益走向自动化，瓶颈已经转移到了修复环节，而漏洞奖励并不为修复工作提供资金。他指出，“支撑关键互联网基础设施的那些项目，不能依靠志愿者劳动来大规模处理 AI 生成的报告。行业需要想清楚如何为‘修复’提供资金，而不仅仅是为‘发现’买单。”

Grafana 是一个流行的可观测性平台，用于汇总和追踪与财务、遥测、运维、基础设施、客户等相关的业务数据。由于该平台的性质天然将其与组织内最核心的信息资产连接在一起，因此攻陷Grafana 实例可能会造成毁灭性后果。

AI 安全厂商 Noma 于今日发布文章，详述了名为 “GrafanaGhost” 的间接提示注入攻击，可导致威胁行动者窃取数据。该攻击依赖于 Grafana AI 组件处理信息的方式。简言之，攻击者将在受控的网页中隐藏恶意指令，并通过控制指令显示为无害的方式，将所要求的敏感数据返回给受攻击者控制的服务器。Grafana 的 AI 助手用户将访问由攻击者构造的 URL 路径，Grafana 将在恶意图像文件开始加载后，      。

该漏洞已修复。

Noma 公司研究人员提供的提示注入的目的是了解用户可能与 Grafana AI 组件交互的地方，因为面向用户的任何内容都可能促成提示注入攻击。调试之后，研究人员发现了处理间接提示的地方并认为图像标记是创建恶意命令的可行渠道。尽管外部图像配备有防护措施来抵御此类攻击，但研究人员设法通过使用与协议相关的 URL 规避域验证以及通过关键词 “INTENT” 来禁用 AI 模型防御措施，导致 Grafana 将外部提示视作非恶意性质。设置好后，在图像开始渲染受害者还未察觉到时，数据就被窃取。

研究人员提到，无需防护人员点击加载恶意页面的步骤即可实施攻击。他提到，“攻击者需要将间接提示存储在 Grafana AI 组件后续检索喝处理的位置。一旦 payload 位于数据库中，那么当用户通过 Grafana 实例执行正常互动（如浏览条目日志）时就会自动执行。用户是毫不知情的触发者而非钓鱼攻击的目标，这就是为何攻击如此隐蔽的原因所在。”

Noma 公司盛赞 Grafana 的及时处理。该公司提到，研究员负责任地披露该漏洞后，Grafana“立即着手，与我们一起验证，并尽可能快地推出修复方案，保护用户的安全。”

Grafana Labs的首席信息安全官 Joe McManus 表示，Noma 公司的研究员从 Markdown 组件的图像渲染器中发现了一个问题，并“已被迅速修复”。

不过，Grafana 对于 Noma 所述的“零点击”或攻击可静默并自动在后台执行的情况持有不同意见。前者表示，“任何利用成功都要求大量用户交互，具体而言，最终用户必须反复要求AI助手遵循日志中包含的恶意指令，即使AI助手已提醒用户注意恶意指令后仍然如此。我们申明，未有证据表明该漏洞已遭在野利用，Grafana Cloud 数据并未遭泄露。”

Noma 公司回应称，利用要求“少于两个步骤”，该AI助手从未提醒用户条目日志中存在恶意指令，“没有任何告警、标记或提示要求用户进行确认。该模型自动处理间接提示，将日志内容解析为合法上下文并静默执行操作，无任何限制也没有提醒用户发现异常情况。用户无法看到后台发生的情况也没有机会进行干预。我们尊重 Grafana 的快速响应以及对用户安全的重视。但我们无法容忍对利用机制的不准确描述。漏洞研究成果已记录，我们对研究揭示的情况很有把握。”

Apache ActiveMQ 是一个用 Java 编写的开源消息中间件，通过消息队列或主题来实现异步通信。尽管 ActiveMQ 已推出性能更优的新版 Artemis 分支，但受该漏洞影响的 Classic 版本仍广泛部署于各类基于 Java 构建的企业系统、Web 后端以及政府、公司内部系统中。

Horizon3 公司的研究员 Naveen Sunkavally 表示，他“仅通过几次基础提示词”就借助 Claude 发现了这个问题，“这个成果八成归功于 Claude，剩下两成是人工包装润色。”Sunkavally 指出，Claude 在逐一分析了多个独立组件（Jolokia、JMX、网络连接器以及 VM 传输协议）后，很快就定位到了该漏洞。他提到，“每个功能单独来看都符合预期，但把它们组合在一起就产生了危险。这正是 Claude 大显身手的地方——它能毫无预设偏见且思路清晰地将这条攻击路径从头到尾串联起来。”该研究员于 3 月 22 日向 Apache 维护人员报告了这一漏洞，后者在 3 月 30 日发布的ActiveMQ Classic 6.2.3 和 5.19.4 版本中修复了该漏洞。

Horizon3 发布技术报告指出，该漏洞的根源在于 ActiveMQ 的 Jolokia 管理 API 暴露了函数addNetworkConnector，可滥用于加载外部配置。攻击者可通过发送精心构造的请求，强制消息代理拉取一个远程 Spring XML 文件，并在初始化过程中执行任意系统命令。

触发该漏洞通常需要经过 Jolokia 的身份认证，但由于另一个漏洞 CVE-2024-32114（该漏洞导致 API 在没有访问控制的情况下被暴露）的存在， 6.0.0 至 6.1.1 版本无需进行认证。

研究人员指出，最新披露的漏洞风险不容小觑，并援引了其他已被黑客用于真实攻击的 ActiveMQ 高危漏洞。研究人员提到，“我们建议所有运行 ActiveMQ 的组织机构优先处理该漏洞，因为 ActiveMQ 一直是真实攻击场景中被反复利用的目标，而且针对它的利用及后渗透方法已经相当成熟。无论是影响 Web 控制台的认证 RCE 漏洞 CVE-2016-3088，还是影响 Broker 端口的未认证 RCE 漏洞 CVE-2023-46604，均已被列入美国 CISA 的已知遭利用漏洞目录（KEV）。”

尽管目前尚未有报告显示 CVE-2026-34197 已遭积极利用，但研究人员指出，已在 ActiveMQ Broker 的日志中清晰看到漏洞利用迹象。建议排查使用内部传输协议 VM 的可疑 Broker 连接，以及包含 “brokerConfig=xbean:http://”查询参数的请求。命令执行会在多次连接尝试过程中触发。研究人员表示，如果系统出现了关于配置问题的警告信息，则意味着恶意载荷已经被执行。

该漏洞是一个高危代码注入漏洞，可导致未授权攻击者在暴露于互联网且未打补丁的 EPMM 设备上实现远程代码执行。Ivanti 公司于 1 月 29 日发布安全更新，修复了该漏洞及另一个安全漏洞 (CVE-2026-1281)，并指出这两个漏洞被用于 0day 攻击。Ivanti 当时“强烈建议”所有客户更新系统，以阻断正在进行的漏洞利用行为。Ivanti 公司当时表示：“成功利用该漏洞可导致未授权远程代码执行。在漏洞披露时，我们已知晓极少数客户的解决方案已遭到利用。”

互联网安全监测组织 Shadowserver 目前追踪到近 950 个仍处于暴露状态的Ivanti EPMM 指纹 IP 地址，其中大部分位于欧洲（569 个）和北美（206 个）。不过，目前尚无法知晓其中有多少设备已完成补丁更新。

当地时间本周一 CISA 将该漏洞纳入已知被利用漏洞目录（KEV），并根据《约束性操作指令 22-01》（BOD 22-01）的要求，责令联邦民事行政部门 (FCEB) 机构在 4 月 11 日周六午夜前完成 EPMM 系统的补丁修复。

CISA 警告称：“此类漏洞是恶意网络行为者的常见攻击入口，对联邦机构的企业网络构成重大风险。请按照厂商指引进行加固，遵循 BOD 22-01 中针对云服务的相关指导；若无法实施缓解措施，则应停止使用该产品。”尽管 BOD 22-01 仅适用于美国联邦机构，CISA 仍建议包括私营部门在内的所有防御方，优先修复该漏洞，尽快加固设备安全。

近年来，多个其它 Ivanti 漏洞已在 0day 状态下被用于攻破各类目标，其中包括全球多家政府机构。总体而言，CISA 已将 33 个 Ivanti 漏洞标记为已遭利用，其中 12 个被多个勒索软件团伙利用。

Ivanti的全球合作伙伴超过 7000 家，为超过 40000 家客户提供 IT 资产管理产品服务。

该漏洞的根源在于，系统在未做任何安全检查的情况下便允许注入 JavaScript 代码。该漏洞于去年 9 月公开披露，可用于执行系统命令并访问文件系统。该漏洞位于Flowise 的 CustomMCP 节点上。该节点允许通过配置设置来连接外部 MCP（模型上下文协议）服务器，并对用户输入的 mcpServerConfig进行了不安全的风险求值。在这一过程中，系统会在未经验证其安全性的情况下，直接执行其中的 JavaScript 代码。

该漏洞已在Flowise 3.0.6 版本中修复。当前最新版本为 3.1.1，已于两周前发布。Flowise 是一个开源的低代码平台，用于构建 AI 智能体以及基于大语言模型的工作流。该平台提供拖拽式界面，使用户能够将各个组件连接成数据处理流水线，从而支撑聊天机器人、自动化流程和 AI 系统的开发。Flowise的用户群体广泛，包括从事 AI 原型开发的开发者、使用无代码工具集的非技术人员，以及运营客服机器人与知识库助手的各类公司。

漏洞情报公司 VulnCheck 的安全研究员 Caitlin Condon 在领英上宣布称，他们的蜜罐网络已检测到针对 CVE-2025-59528 的在野利用。尽管目前攻击活动看似有限，仅来自一个 Starlink IP 地址，但研究人员警告称，当前互联网上暴露的 Flowise 实例数量在 12000 到 15000 之间。不过，尚不清楚其中有多少属于存在漏洞的 Flowise 服务器。

Condon 指出，除了 CVE-2025-59528 之外，观测到的攻击活动还涉及同样影响 Flowise 且已被发现遭在野利用的 CVE-2025-8943与CVE-2025-26319。

目前，VulnCheck 仅向其客户提供漏洞利用样本、网络检测特征以及 YARA 规则。建议 Flowise 用户尽快升级到 3.1.1 版本，或至少更新到 3.0.6 版本。如无需外部访问，还应考虑将实例从公网移除。

威胁人员可利用 Codex 处理任务创建请求的方式，通过授予 AI 代理的权限，横向移动到组织机构的 GitHub 环境中。

OpenAI Codex 是一款基于云的编程助手，直接连接到开发人员的 GitHub 仓库。当用户提交一个提示词时，Codex 就会启动一个管理容器来运行多项任务如代码生成或仓库分析。研究人员发现在该容器的设置阶段，系统未能正确清理输入。具体而言，HTTP POST 请求中的 GitHub 分支名称参数被直接传递给环境的设置脚本。攻击者可通过将 shell 命令注入分支名称的方式利用该漏洞。例如，恶意 payload 可强制系统将隐藏的 GitHub OAuth 令牌输出位刻度文本文件。接着攻击者可提示 Codex 代理读取该文件，从而将明文令牌直接暴露到 web 接口中。

而危险会扩散到本地开发者环境中。研究人员发现桌面 Codex 应用将认证凭据本地存储在一个认证文件中。如果攻击者获得对运行 Windows、macOS 或 Linux 的开发者机器的访问权限，则可窃取这些会话令牌。通过使用这些遭攻陷本地令牌在后端 API 进行认证，攻击者可检索用户的所有任务历史。

该后端访问权限还可导致攻击者提取隐藏在容器任务日志深处的 GitHub 访问令牌，同时攻击也可自动化，在无需与 Codex 接口进行交互的情况下攻陷多个用户。在一个 GitHub 共享仓库中直接创建恶意分支，可导致攻击者通过 Codex 在特定代码库中触发利用。

为了绕过 GitHub 用于拦截常规空格的分支-命名限制，攻击者可通过包含内部字段分隔符的 payload 替换这些空格。攻击者还可巧妙地利用 Unicode 表意空格将恶意载荷在用户界面上隐藏起来。对于毫无戒心的受害者而言，恶意分支看起来与标准的 main 分支完全一样。一旦用户或自动流程与之交互，则该 payload 会悄悄在后台执行，将自己的 GitHub 令牌发送给遭攻击者控制的外部分支。

这种自动化分支攻击同样适用于自动化拉取请求。当开发者在拉取请求中标记 Codex 机器人执行代码审查时，系统会启动代码审查容器。如果该仓库中包含该恶意命名的分支，自动化容器就会执行隐藏 payload，从而导致攻击者窃取具有更广权限的 GitHub 安装访问令牌。

该漏洞为“严重”等级，影响 ChatGPT 网站、Codex CLI、Codex SDK 和 Codex IDE 扩展。OpenAI 在2025年12月收到负责任的漏洞报告，并在2026年1月末修复该漏洞。

随着 AI 编程助手日益深度地融入开发者的工作流程，各组织机构必须将智能体容器视为严格的安全边界。

• 开发团队与安全团队应开展以下实践：

• 在将用户可控的所有输入传递给 shell 命令之前，对其进行清理。

• 永远不要认为外部提供商的数据格式本身是安全的。

• 审计授予 AI 应用的权限，严格执行最小权限原则。

• 监控代码仓库中是否出现包含 shell 元字符或 Unicode 空格的异常分支名称。

• 定期更换 GitHub 令牌，并检查访问日志中是否存在异常的 API 活动。

Fortinet 公司告警称：“Fortinet 已发现该漏洞遭在野利用，并敦促受影响客户尽快安装针对 FortiClient EMS 7.4.5 和 7.4.6 版本的热补丁。”该公司表示，该漏洞影响 FortiClient EMS 7.4.5 和 7.4.6 版本，可通过安装以下其中任一热补丁进行修复：

• FortiClient EMS 7.4.5：https://docs.fortinet.com/document/forticlient/7.4.5/ems-release-notes/832484  

• FortiClient EMS 7.4.6：https://docs.fortinet.com/document/forticlient/7.4.6/ems-release-notes/832484

即将发布的 FortiClient EMS 7.4.7 版本也将修复该漏洞。FortiClient EMS 7.2 版本不受影响。

该漏洞由网络安全公司 Defused 发现，后者认为该漏洞是一个预认证 API 访问绕过漏洞，可导致攻击者完全绕过身份验证与授权控制。Defused 在 X 平台上表示，本周早些时候他们观察到该漏洞作为 0day 漏洞被利用，随后依照负责任的披露流程向 Fortinet 公司报告了此事。

互联网安全监测机构 Shadowserver 已发现超过 2000 个暴露在公网的 FortiClient EMS 实例，其中大部分位于美国和德国。上周，FortiClient EMS中的另外一个高危漏洞 CVE-2026-21643，也已遭在野利用。

这两个漏洞均由 Defused 发现，其中CVE-2026-35616的贡献者也包括Nguyen Duc Anh。Fortinet 公司敦促客户立即安装热补丁，或待 7.4.7 版本发布后尽快升级，降低系统被入侵的风险。

本周一，美国网络安全和基础设施安全局 (CISA) 将CVE-2026-35616 纳入已知遭利用 (KEV) 清单，并要求联邦民事行政部门 (FCEB) 在当地时间4月9日12点之前修复该漏洞。CISA 提到，这类漏洞是恶意人员经常利用的攻击向量，为联邦企业带来严重风险。

思科IMC也被称为CIMC，是嵌入在思科服务器主板上的硬件模块，用于为UCS C系列和E系列服务器提供带外管理功能（即使在操作系统关机或崩溃的情况下也能使用），支持通过XML API、网页（WebUI）和命令行（CLI）等多种接口进行管理。

该漏洞存在于思科IMC的密码更改功能中，可被未经身份验证的攻击者远程利用，绕过身份验证并以管理员权限访问未打补丁的系统。思科在周三解释称：“该漏洞是由于对密码更改请求的处理不正确造成的。攻击者可以通过向受影响设备发送特制的HTTP请求来利用此漏洞。成功利用该漏洞可让攻击者绕过身份验证、修改系统上任一用户的密码（包括管理员用户），并以该用户的身份获得系统访问权限。”

尽管思科产品安全事件响应团队（PSIRT）尚未该漏洞遭野外利用的证据或PoC 代码，但由于目前没有可临时缓解此安全缺陷的变通方案，公司“强烈建议客户升级到修复后的软件版本”。

本周，思科还修复了本地版智能软件管理器（SSM On-Prem）中的一个高危漏洞（CVE-2026-20160），它可导致无权限的威胁行动者者在易受攻击的SSM On-Prem主机上实现远程代码执行。攻击者可以通过向受影响服务的API发送特殊构造的请求来利用CVE-2026-20160，以root权限在底层操作系统上执行命令。

本月早些时候，思科修复了位于Secure防火墙管理中心（FMC）中一个CVSS满分的远程代码执行漏洞（CVE-2026-20131），该漏洞曾被Interlock勒索软件团伙在零日攻击中利用。美国网络安全与基础设施安全局（CISA）也已将该漏洞列入其在野被滥用的漏洞目录，并要求联邦机构在三天内完成系统加固。

近日，据BleepingComputer报道称，攻击者利用在近期Trivy供应链攻击活动中窃取到的凭据，攻陷思科的内部开发环境。

Progress ShareFile 是一款文档共享与协作产品，通常用于大中型企业。这类解决方案对勒索软件团伙具有很大的吸引力，此前在 Clop 组织的窃取数据攻击中就已见端倪，他们曾利用 Accellion FTA、SolarWinds Serv-U、Gladinet CentreStack、GoAnywhere MFT、MOVEit Transfer 以及 Cleo 等产品中的漏洞实施攻击。

SZC 允许客户将数据存储在自己的基础设施（本地部署或第三方云服务商）或 Progress 的系统中，从而让客户对其数据拥有更强的控制权。在watchTowr进行负责任的披露后，这两个漏洞已在3月10日发布的Progress ShareFile 5.12.4版本中修复。

研究人员解释称，攻击首先利用身份验证绕过漏洞（CVE-2026-2699）。该漏洞因HTTP重定向处理不当而导致攻击者能够访问ShareFile的管理员界面。进入系统后，攻击者可以修改存储区域的配置设置，包括文件存储路径以及区域密码和相关密钥等安全敏感参数。

通过利用第二个漏洞（CVE-2026-2701），攻击者可以滥用文件上传和解压功能，将恶意的ASPX网页后门放置在应用程序的webroot目录中，从而在服务器上实现远程代码执行。

研究人员指出，要成功利用该漏洞，攻击者必须生成有效的HMAC签名，并提取和解密内部密钥。然而，在利用CVE-2026-2699之后，由于能够设置或控制与密码相关的参数值，这些操作是可以实现的。

研究人员扫描发现大约有30000个存储区域控制器实例暴露在公共互联网上。ShadowServer基金会目前观测到700个Progress ShareFile的互联网暴露实例，其中大部分位于美国和欧洲。

研究人员于2月6日至13日期间向Progress报告。完整的攻击链于2月18日在Progress ShareFile 5.12.4版本上得到确认。该供应商于3月10日发布了5.12.4版本的安全更新。

尽管截至本文撰写时尚未观察到在野的活跃利用，但由于攻击链已公开，因此运行存在漏洞的ShareFile存储区域控制器版本的系统应立即打补丁。

Palo Alto Networks 公司团队Unit 42称，该漏洞涉及如何针对 Vertex AI 权限模型中服务代理默认权限范围过大的特点实施滥用。

Unit 42 团队的研究员 Ofir Shaty 在一份相关报告中表示：“配置错误或被攻陷的代理可能成为‘双重间谍’，表面上在执行其预期功能，暗地里却在窃取敏感数据、破坏基础设施，并在组织机构最关键系统中创建后门。”

具体而言，研究人员发现，与使用 Vertex AI 的 Agent Development Kit（ADK）构建的已部署 AI 代理相关联的“按项目、按产品服务代理”（P4SA），在默认情况下被授予了过多权限。这为一种场景打开了大门，即利用 P4SA 的默认权限来提取服务代理的凭据，并以其名义执行操作。

在通过 Agent Engine 部署 Vertex 代理后，对该代理的任何调用都会调用谷歌的元数据服务，并暴露服务代理的凭证，以及托管 AI 代理的谷歌云 (GCP) 项目、AI 代理的身份和托管该 AI 代理的机器的权限范围。

Unit 42 团队表示，他们能够利用窃取的凭证从 AI 代理的执行上下文跳转到客户项目中，从而有效打破隔离保障，并允许对该项目内所有 Google Cloud Storage 存储桶的数据进行无限制的读取访问。报告指出，“这种级别的访问权限构成了重大的安全风险，将 AI 代理从一个有用的工具转变为一个潜在的内部威胁。”

不仅如此。由于部署的 Vertex AI Agent Engine 在谷歌管理的租户项目中运行，提取的凭证还授予了对该租户内 Google Cloud Storage 存储桶的访问权限，从而揭示了有关该平台内部基础设施的更多细节。不过，研究发现这些凭证缺乏访问这些暴露的存储桶所需的必要权限。

更糟糕的是，同一个 P4SA 服务代理凭证还启用了对受限制的、谷歌拥有的 Artifact Registry 仓库的访问，这些仓库在 Agent Engine 部署过程中被暴露出来。攻击者可以利用此行为从构成 Vertex AI Reasoning Engine 核心的私有仓库中下载容器镜像。

此外，被攻陷的 P4SA 凭证不仅使得下载 Agent Engine 部署期间日志中列出的镜像成为可能，还暴露了 Artifact Registry 仓库的内容，其中包括其它几个受限镜像。Unit 42 团队解释称：“访问这些专有代码不仅暴露了谷歌的知识产权，还为攻击者提供了寻找更多漏洞的蓝图。”

“Artifact Registry 的错误配置凸显了关键基础设施访问控制管理中的另一个缺陷。攻击者可能利用这种非预期的可见性来绘制谷歌内部软件供应链的地图，识别已弃用或存在漏洞的镜像，并策划进一步的攻击。”

此后，谷歌已更新官方文档，明确说明了 Vertex AI 如何使用资源、账户和代理。另外还建议客户使用“使用自己的服务账户”（BYOSA）来替换默认的服务代理，并执行最小权限原则，以确保代理仅拥有执行当前任务所需的权限。

Shaty 表示：“默认授予代理广泛的权限违反了最小权限原则，是一种危险的设计级安全缺陷。组织应以与处理新生产代码相同的严谨态度对待 AI 代理的部署。在生产环境上线前，应验证权限边界，将 OAuth 范围限制为最小权限，审查源完整性，并进行受控的安全测试。”

作为一个与平台无关的 C 语言库，libpng 是无数应用程序中图像渲染的基石，涵盖从网页浏览器到嵌入式系统的广泛领域。这两个漏洞凸显了传统 C 语言代码库中内存管理长期存在的风险。

第一个漏洞CVE-2026-33636，针对的是使用 Neon SIMD 指令的 ARM/AArch64 架构中用于性能优化的代码。调色板扩展路径中存在一处越界读取和写入漏洞。当库将 8 位索引调色板行扩展为 RGB 或 RGBA 时，Neon 循环在处理最后一组像素时未验证是否有足够的剩余输入数据。由于该实现是从行尾反向处理的，最后一次迭代会解引用缓冲区起始位置之前的指针。攻击者可通过提供特制的 PNG 图片轻易导致进程崩溃。由于调色板内容由攻击者控制，堆内存内容可能通过解码后的像素输出被泄露。

此漏洞仅影响启用了硬件优化的系统（具体文件为 arm/palette_neon_intrinsics.c）。基于 Intel（SSE2）、PowerPC 的实现以及通用的 C 语言实现均不受影响。

第二个漏洞CVE-2026-33416，是一个涉及两个内部结构体 png_struct 和 png_info 之间指针别名（别名使用）的经典逻辑错误。此漏洞自 1.0 版本（针对透明数据）和 1.2.1 版本（针对调色板）以来就一直存在于代码库中。

像 png_set_tRNS 和 png_set_PLTE 这样的函数会在两个不同结构体之间共享同一个堆分配的缓冲区。如果应用程序调用 png_free_data，它会通过其中一个结构体释放缓冲区，而另一个结构体则仍持有一个悬空指针。随后的转换操作会读取——有时甚至写入——这块已被释放的内存。

研究人员已在一些环境中演示了远程代码执行。在像 glibc tcache 这样的现代内存分配器上，被释放的 256 字节缓冲区通常会立即被新对象重新使用。如果攻击者控制（通过 tRNS 数据块）重新写入该内存的值，他们就可以劫持应用程序的控制流。这些特殊构造的 PNG 文件 100% 符合标准规范，这意味着传统的验证工具或 Web 应用防火墙在不屏蔽所有 PNG 文件的情况下无法检测到此类攻击。

用户应升级到已修复这两个漏洞的 libpng v1.6.56 或 v1.8.0（主干分支）版本。如果无法立即更新，可以通过在编译时使用以下标志来禁用 ARM Neon 漏洞的硬件优化缓解措施：-DPNG_ARM_NEON_OPT=0。至于第二个释放后使用漏洞，建议开发者审查在 png_read_info() 和 png_read_update_info() 阶段之间调用 png_free_data() 的应用程序模式。

2026 年 3 月 31 日，研究人员 Chaofan Shou 公开披露了这一情况，并发文称：“Claude Code 源代码通过 npm 注册表中的 .map 文件被泄露了！”据称，已发布的 @anthropic-ai/claude-code npm 包中包含一个源映射（.map）文件，该文件引用了完整、未压缩的 TypeScript 源代码，这些代码可直接以 ZIP 压缩包的形式从 Anthropic 自家的 R2 云存储桶中下载。这份原始的未经修改的源代码随后被保存并镜像到一个公共 GitHub 仓库中，位于备份分支 nirholas/claude-code 下。

虽然源代码已在网上传播，但 Anthropic 公司已开始发出数字千年版权法案（DMCA）侵权通知，尽可能下架被泄源代码。

遭泄露的代码库包含了 Claude Code 完整的 src/ 目录，共计约 1900 个文件，超过 512000 行代码，采用严格 TypeScript 编写，使用了 Bun 运行时和 React + Ink 终端 UI 框架。此次泄露范围广泛，涉及该 CLI 工具的每一个关键子系统。

已确认泄露的关键文件包括：QueryEngine.ts（约 46000 行），驱动核心的大语言模型 API 引擎，涵盖流式传输、工具循环和令牌追踪功能；Tool.ts（约 29,000 行），定义了所有代理工具类型及权限模式；以及 commands.ts（约 25,000 行），负责注册和执行该工具中的斜杠命令。

泄露的架构细节显示，该工具包含约 40 个代理工具，包括 BashTool、FileReadTool、FileEditTool，以及用于生成子代理的 AgentTool；同时还包含约 85 条斜杠命令，涵盖 Git 工作流、代码审查、内存管理和多代理编排等功能。

此次泄露还揭示了内部功能标志，如 PROACTIVE、VOICE_MODE、BRIDGE_MODE 和 KAIROS，表明这些是尚未公开发布的产品功能。

开发者们已经开始分析源代码，以寻找未记录的功能并了解该应用程序的工作原理。据 Alex Finn 称，Anthropic 正在测试一种名为“主动模式”的新模式，在该模式下，Claude 将全天候为用户编写代码。这一模式是在 Claude Code 的源代码中被发现的。另一个有趣的功能还包括被称为“梦境 (Dream)”的模式。在该模式下，Claude 可以在后台持续思考、构思想法、改进用户当前的计划，并尝试在用户离开时解决问题。

源映射文件（.map）是标准的开发者工具，旨在将编译或压缩后的 JavaScript 映射回其原始源代码，以便于调试。

然而，当这些文件在无意中被打包到生产环境的 npm 发布版本中时，它们就会将专有源代码暴露给任何知道如何查找的人，实际上完全绕过了代码混淆。这并非 Anthropic 首次受到此类错误的影响；据报道，类似的一次源映射泄露事件已在 2025 年初得到解决。

此次泄露事件给 Anthropic 带来了严重的知识产权问题，因为泄露的代码涵盖了内部 API 客户端逻辑、OAuth 2.0 认证流程、权限执行、多代理协调，甚至包括未公开的功能管线。

Anthropic 证实了源代码遭泄露事件，提到“今天早些时候，Claude Code 的一次发布中包含了一些内部源代码。该事件不涉及也没有暴露任何敏感的客户数据或凭据。这是一次由人为错误导致的发布打包问题，而非安全入侵。我们正在推出相应措施，以防止此类事件再次发生。”

另外，用户声称 Claude 悄然降低了使用额度。这意味着无论用户使用的是 Pro 套餐还是 Max 套餐（5 倍额度），都会更快地耗尽 Claude 的使用额度。事实证明这个问题很普遍，Anthropic 已确认正在调查一个导致额度消耗过快的错误。“我们注意到人们在 Claude Code 中消耗使用额度的速度远超预期。我们正在积极调查，有进展时会分享更多信息。”Anthropic 公司的 Lydia Hallie 在 X 平台上发帖写道。

随后Anthropic 发布了更新称，“[我们]仍在处理此问题。这是团队的首要任务。我知道这让很多人无法正常工作。有进一步消息会立即告知。”一些用户认为这可能是 Anthropic 有意为之的调整，因为过去几周 Claude 的受欢迎程度一直在上升，但在公司没有透露更多细节之前，无法判断这一说法是否属实。

将 Claude Code 集成到其开发工作流程中的组织机构应关注 Anthropic 的官方安全公告。建议开发者查看官方 npm 仓库以获取已修复的版本，并避免使用泄露源代码的第三方镜像。

虽然目前关于该漏洞的公开细节寥寥无几，但多份已发布的报告解释了为何该漏洞会获得如此危险的评级。意大利国家网络安全局发布警报（经由谷歌翻译）称，ZDI-CAN-30207漏洞可对Android和Linux版本的该应用实现疑似零点击、可通过网络远程执行的攻击，这种攻击能够执行任意代码、访问私人通信、实施监控、窃取敏感数据以及破坏设备功能。

该漏洞的利用涉及使用Telegram中一个被篡改的贴纸 (sticker) 作为攻击载体。贴纸是经过特殊处理的媒体文件，用户在使用该应用聊天时常用它们来表达情感或代替短消息。

独立网络安全顾问 Carolina Vivianti 在Red Hot Cyber博客上发文指出：“攻击载体出奇地简单：动态贴纸。”她称该漏洞“极其令人不安”，因为要利用该漏洞实施攻击，用户在Telegram会话中无需点击或打开任何内容。她写道：“仅仅收到内容就足够了。无需确认，无需用户交互。系统会处理这些文件以生成预览图，而攻击恰恰就发生在这个阶段。”

然而，Telegram在X平台上反复声明称，通过贴纸进行此类攻击是不可能的，并声称这种说法“完全忽略了所有上传到Telegram的贴纸在能被Telegram应用播放之前，都会经过其服务器的验证”。

意大利国家网络安全局周一更新了告警并加入了Telegram的否认声明。更新内容写道：“根据这一官方立场，集中式过滤流程阻止了使用被篡改的贴纸作为攻击载体，使得通过此方法执行恶意代码在技术上成为不可能。”目前该机构并未立即回复更多漏洞信息相关问询。

Telegram采用消息加密机制，被许多人用于私人通信。因此，一个能让攻击者窃取数据、实施网络间谍活动及进行各种其它恶意行为的零点击漏洞，会对该平台造成巨大冲击。

事实上，威胁行动者可以利用即时通讯应用中的漏洞，针对通信内容可能具有战略或全球重要性的各类目标人物，包括记者、政治人物、政府官员、公司高管或企业用户。与此同时，Telegram的安全政策也使该公司深陷争议和法律纠纷。值得注意的是，首席执行官Pavel Durov于2024年被法国当局逮捕，原因是Telegram一直拒绝与执法机构共享除恐怖主义案件以外的数据，这一事件迫使该公司对其政策做出了调整。

此外，该应用在网络犯罪分子中也很受欢迎，他们认为可以在此进行恶意活动而无需担心被检测到；事实上，他们经常设立专门的Telegram频道作为非法活动的基础。

在Telegram改变否认该漏洞存在的立场之前，公众在7月之前不太可能知晓该漏洞不仅存在而且如ZDI所担心的那样危险。在此之前，Telegram用户应安装未来几个月发布的所有应用更新，并在补丁出现时立即应用任何为修复该漏洞而部署的补丁，以确保自己使用的是最安全的版本。

在情况变得更加明朗之前，Vivianti为Telegram的企业用户和个人用户分别提出了防御建议。对于前者，她建议通过将消息接收限制为仅限受信任的联系人或高级用户来减少攻击面。她认为，虽然这么做会影响通信流程，但能降低暴露风险。对于普通公众，由于仅禁用自动下载是不够的，因此她建议用户暂时卸载该应用，或通过最新版本的浏览器使用Telegram网页版，从而“利用现代浏览器的沙盒架构”。她表示，与原生客户端相比，网页提供了更强的隔离层。

建议使用 Grafana 进行数据可视化的系统管理员立即应用这些反向移植的补丁，以防系统遭受攻击。

其中CVE-2026-27876（CVSS评分9.1）更为严重，位于 Grafana 的 SQL 表达式功能中。该漏洞可导致攻击者直接向服务器的文件系统写入任意文件，可与其它攻击途径结合，实现完整的远程代码执行。Grafana Labs 确认，这一特定利用路径可被武器化，攻击者能够借此直接与底层主机服务器建立未经授权的 SSH 连接。要成功利用该漏洞，攻击者必须拥有 Viewer 或以上权限以执行数据源查询，且目标系统需已启用 sqlExpressions 功能开关。一旦满足这些严格的前置条件，攻击者便可以覆写 Sqlyze 驱动程序，或恶意篡改 AWS 数据源配置文件。

该漏洞由 Miggo Security 的研究员 Liad Eliyahu 负责任地披露，凸显了持续进行严格外部安全审计的必要性。

第二个漏洞CVE-2026-27880（CVSS评分7.5），是一个高危级别的拒绝服务（DoS）漏洞，影响 OpenFeature 校验端点。由于这些端点无需身份验证，且不加限制地将用户输入直接加载至内存，攻击者可借此轻易压垮系统。攻击者可发送超大请求，瞬间导致 Grafana 实例崩溃，造成监控服务严重停摆。

Grafana Labs 强烈建议所有管理员立即升级至官方已修复版本：Grafana 12.4.2、12.3.6、12.2.8、12.1.10 及 11.6.14。依赖托管云服务的企业可放心使用，因为 Amazon Managed Grafana 和 Azure Managed Grafana 环境已在保密期内完成加固。这些快速发布的更新彰显了 Grafana 致力于为其企业版及开源版用户维护安全生态系统的承诺。对于无法立即升级的企业，完全关闭 sqlExpressions 功能开关可暂时消除 RCE 攻击面。在未打补丁的情况下，为主动防御 DoS 漏洞，管理员应将 Grafana 部署在高可用环境中，确保快速自动恢复。此外，部署 Nginx 或 Cloudflare 等可靠的反向代理，严格限制输入请求的负载大小，可有效阻断内存耗尽这一攻击路径。

这些漏洞凸显了依赖 n8n 处理敏感数据和关键任务自动化的组织所面临的重大风险。第一个严重漏洞CVE-2026-33660，涉及 Merge 节点。Merge 节点是用于合并来自不同数据源的数据的核心组件。当设置为“按 SQL 合并”模式时，该节点会使用 AlaSQL 库。研究人员发现，AlaSQL 沙箱未能充分限制某些 SQL 语句。拥有创建工作流权限且通过身份验证的用户可以利用此漏洞直接从 n8n 主机服务器读取本地文件，或实现完整的远程代码执行，或导致实例完全被接管。

第二个漏洞是位于 GSuiteAdmin 节点参数中常见但影响巨大的原型污染漏洞CVE-2026-33663。通过在节点配置期间提供特殊构造的参数，攻击者可以将未经授权的值写入 Object.prototype。在像 n8n 这样的 Node.js 环境中，操纵全局对象原型可直接导致攻击者：

• 在服务器上执行任意代码。

• 通过将攻击者控制的属性注入应用程序逻辑来绕过安全控制。

n8n 开发团队已为多个发布分支发布了这两个漏洞的补丁。建议管理员立即将其实例更新至以下版本之一：

• 2.14.1

• 2.13.3

• 1.123.27

如果无法立即升级，以下短期措施可以降低但无法完全消除该风险：

• 限制权限：将工作流的创建和编辑权限严格限制在完全受信任的用户范围内。

• 禁用易受攻击的节点：使用 NODES_EXCLUDE 环境变量禁用受影响的节点，可通过如下措施实现：

  Ø添加 n8n-nodes-base.merge 以阻止 SQL 漏洞利用。

  Ø添加 n8n-nodes-base.xml 作为相关风险的缓解措施。

该AI漏洞奖励计划在 Bugcrowd 平台上实施，标志着 OpenAI 开始修复传统安全漏洞范围以外但仍然可能造成实际影响的漏洞。该漏洞奖励计划旨在补充 OpenAI 公司现有的安全漏洞奖励计划，任何存在重大滥用和安全风险的问题甚至是这些问题并非传统安全漏洞的漏洞报告均可提交。

OpenAI 公司将与安全漏洞奖励团队共同对这些漏洞进行初审，并根据漏洞的范围和归属，在两个项目之间进行重新分配。

该计划针对几种不同类别的AI特定安全场景：

包括MCP的代理风险——涵盖第三方提示注入和数据外泄场景，即攻击者控制的文本能够可靠地劫持受害者的AI代理（包括Browser、ChatGPT 智能体及类似的代理型产品），从而执行有害操作或泄露敏感用户数据。如属于该场景，利用行为必须至少有50%的概率可重现。涉及代理型产品大规模执行被禁止或潜在有害行为的报告也在范围内。

OpenAI专有信息——研究人员可报告模型生成内容中无意暴露的推理相关专有信息，以及泄露OpenAI其它保密数据的漏洞。

账户与平台完整性——此类别针对账户和平台完整性信号中的弱点，包括绕过反自动化控制、操纵账户信任信号、以及规避账户限制、暂停或封禁等。

OpenAI已明确说明仅导致粗鲁语言或公开已知信息的通用越狱、无明确安全或滥用影响的一般性内容策略绕过将不在奖励范围内。不过，OpenAI会定期开展针对特定危害类型的私有漏洞赏金活动，例如ChatGPT 智能体和GPT-5中的生物风险内容问题，并会在这些项目启动时邀请研究人员申请参与。

对于能够实现超出允许权限范围对功能、数据或功能进行未授权访问的漏洞，研究人员应转向现有的安全漏洞赏金计划进行提交。

本次推出的AI漏洞奖励计划表明，人们越来越认识到AI系统引入了一个全新的攻击面，这是传统安全框架未曾设计去应对的。OpenAI 公司在对传统漏洞披露进行激励的同时，也对关注安全性的研究给予奖励，从而有效地为针对AI的威胁建模建立一个结构化的框架。

有兴趣参与的研究人员可以直接通过OpenAI在Bugcrowd平台上的安全漏洞赏金页面进行申请。