Brevo供应链攻击将恶意软件注入10万个网站

2026年9月，客户关系管理和数字营销平台Brevo遭遇了一起典型的供应链攻击事件。攻击者并没有直接逐一入侵使用Brevo服务的网站，而是首先控制Brevo自身的基础设施，再利用客户网站嵌入的Brevo JavaScript组件，将恶意代码传播给下游网站和访问者。相关调查显示，超过10万个使用Brevo相关组件的网站可能受到影响，攻击窗口持续约4小时至5个半小时。这个事件最值得关注的地方，是攻击者只需要攻破供应链中的一个关键节点，就可以借助合法的第三方代码分发机制，把一次针对单个企业的入侵迅速放大成影响大量下游网站的供应链安全事件。

事件实际上经历了两个阶段。2026年9月10日，Brevo首先发现攻击者利用其SAML单点登录机制中的安全缺陷，获得了138个Brevo账户的访问权限。其中6个账户被用于向联系人发送钓鱼邮件，43个账户的联系人数据被导出，其余93个账户没有发现有意义的活动。Brevo随后在当天8:30 UTC关闭了攻击者利用的访问路径，并注销所有用户会话。但几天之后，攻击者再次发动攻击，并把目标从客户账户进一步扩大到Brevo的基础设施。

9月14日，攻击者利用一枚已经泄露的、长期有效的Cloudflare API密钥创建了恶意Cloudflare Worker。调查发现，这枚API密钥具有完整账户权限，而且此前被硬编码在应用源代码中。由于权限过大且缺乏有效告警，攻击者可以利用该密钥创建Cloudflare Workers、配置路由以及修改DNS记录，从而在不直接修改Brevo源站文件的情况下，在Cloudflare边缘网络对返回给用户的网页内容进行重写。也就是说，源站文件可能仍然是干净的，但用户实际收到的网页已经被攻击者修改。

攻击者创建的恶意Worker向Brevo多个网站和服务注入恶意JavaScript，包括brevo.com、sibforms.com以及客户网站嵌入的Brevo JavaScript组件。受影响的组件包括Brevo的SDK Loader、Conversations聊天组件等。由于这些JavaScript文件本来就需要被数以万计的网站加载，攻击者无需获得这些客户网站本身的服务器权限，只要修改一次Brevo提供的公共脚本，就可以让大量下游网站在正常加载第三方组件时同时加载恶意代码。这个过程充分体现了软件供应链的“传递性信任”：客户信任Brevo，因此允许Brevo的脚本进入自己的网页；攻击者控制Brevo之后，这种原本用于提供业务功能的信任关系就被转化成了恶意代码传播通道。

安全研究人员捕获到的恶意代码通过多个sendibt1.com子域名加载，包括cdn.sendibt1.com、cdn2.sendibt1.com、cdn3.sendibt1.com、cdn4.sendibt1.com、cdn9.sendibt1.com、cdn10.sendibt1.com和cdn11.sendibt1.com。相关分析发现，攻击者在Brevo合法JavaScript文件末尾追加了一段代码，用于动态创建新的script元素，再从攻击者控制的sendibt1.com基础设施加载f.js恶意脚本。研究人员还发现，cdn.sendibt1.com对应的SSL证书于2026年8月25日创建，而sendibt1.com本身属于Brevo运营的域名，这进一步说明攻击者已经获得了对Brevo相关DNS基础设施的写入能力。

恶意脚本的行为根据访问者身份进行区分。对于普通网站访问者，它会显示一个伪造的“Cloudflare验证你是真人”的页面，诱导用户完成所谓的验证码验证，并进一步要求用户将一段命令复制到计算机上执行。这属于近年来较为活跃的ClickFix社会工程攻击模式。其危险之处在于，攻击者不一定需要诱骗用户下载一个明显的恶意EXE文件，而是利用用户对“验证你是真人”“复制命令完成验证”等页面操作的信任，让用户主动完成高风险操作。因此，浏览器页面本身看起来可能只是一个普通的验证码页面，但最终结果却可能导致恶意程序进入用户终端。

对于使用WordPress的网站，攻击链进一步扩大。恶意脚本能够识别访问者是否以WordPress管理员身份登录。如果发现当前访问者具有管理员权限，则会尝试通过Brevo基础设施加载并部署一个恶意WordPress插件，研究人员认为该插件很可能用于建立持久化后门。这意味着一次第三方JavaScript供应链攻击，不仅可能影响网站普通访问者，还可能进一步攻击拥有管理权限的网站管理员，并把原本只是“访问恶意页面”的风险升级为“网站本身被植入后门”。

从时间参数来看，恶意代码至少从2026年9月14日16:05:18 UTC开始被观察到，最后一次恶意活动大约发生在20:12:53 UTC。Brevo方面给出的暴露窗口约为5个半小时，而独立监测显示恶意脚本实际向用户提供的时间约为4小时。9月15日，相关恶意子域名全部停止解析，Brevo随后撤销被泄露的API密钥及相关凭据、删除攻击者创建的资源、清理边缘缓存，并从源代码中移除硬编码凭据。

独立研究人员估计，可能有超过100000个网站受到影响。相关研究还发现，Brevo自身的网站、预约页面、Conversations聊天组件以及sibforms.com托管表单等多个页面均曾出现恶意脚本。研究人员通过内容安全策略（CSP）监测，在事件窗口及随后缓存继续传播期间，从12个网站收集到了2549条CSP违规报告。这个数字虽然不能直接等同于受感染网站数量，却能够证明恶意脚本曾经通过多个不同的网站和页面实际传播。

攻击者并没有修改Brevo源站文件。由于恶意Worker是在Cloudflare边缘执行，它可以在HTTP响应返回给用户之前修改内容，因此源服务器上的JavaScript文件可能仍然保持正常状态，传统文件完整性检测也就很难发现问题。更进一步，攻击者还删除或绕过了部分安全响应头，包括Content-Security-Policy，使恶意脚本能够更加顺利地进入浏览器环境。这说明现代Web应用的安全边界已经从“服务器上的文件”扩展到了CDN、边缘计算、DNS、API密钥和第三方云控制平面。

第三方JavaScript本身就是供应链。网站开发人员往往会把统计脚本、聊天组件、营销工具、客服工具、支付组件和分析SDK直接嵌入网站，并认为这些代码来自知名服务商，因此风险较低。但一旦第三方服务商遭到入侵，客户网站可能在没有任何本地代码修改、没有任何服务器漏洞被利用的情况下，把恶意代码主动交付给自己的访问者。因此，网站自身“没有被黑”并不意味着网站用户没有受到供应链攻击影响。

这也改变了传统网站安全的责任边界。过去检查一个网站是否遭到入侵，通常重点查看Web服务器、数据库、文件完整性和管理员账号；而面对第三方SaaS供应链风险，还必须进一步梳理网站加载了哪些第三方脚本、这些脚本从哪里加载、由谁控制、是否能够动态修改、是否具备高权限API、发生异常时能否快速切断依赖。如果一个网站依赖几十个第三方JavaScript资源，却没有建立第三方组件清单，那么一旦其中一个供应商被攻击，责任单位可能甚至无法快速知道自己的哪些业务受到影响。

对于安全运营而言，Brevo事件还说明，API密钥实际上已经成为一种高价值身份凭证。一枚长期有效、具有完整权限并被硬编码在源代码中的Cloudflare API密钥，其风险并不亚于一个高权限管理员账号。如果这种密钥长期存在、没有轮换、权限范围过大，而且调用行为没有实时监测，那么攻击者一旦获得它，就可能绕过正常的人机交互流程，直接控制云平台上的资源。因此，API密钥管理、密钥轮换、最小权限、Secrets管理和异常调用监测，都应该成为云安全运营的重要组成部分。

更值得注意的是，这次事件并非单纯的“凭据泄露”。攻击者实际上完成了从身份攻击→云平台控制→边缘Worker部署→JavaScript供应链投毒→下游网站传播→终端社会工程→WordPress持久化的一条完整攻击链。攻击者只需要突破供应链中的一个关键节点，就能够借助下游客户之间已经建立的信任关系实现规模化扩散。这也是供应链攻击最危险的地方：攻击者的攻击成本可能集中在一个节点，而受影响范围却可以沿着依赖关系成倍扩大。

因此，对于使用第三方SaaS、SDK、JavaScript、API和云服务的组织而言，供应链安全不能只停留在“供应商是不是大厂”或者“合同中有没有安全条款”。更重要的是建立真实的依赖关系清单，明确哪些第三方代码能够进入生产环境、哪些第三方身份能够访问云平台、哪些API密钥拥有高权限、哪些组件能够修改网页内容，以及一旦第三方服务出现安全事件，组织能否在分钟级或者小时级完成隔离和替换。

供应链安全最大的风险，不一定来自你自己安装的软件，而可能来自你主动信任并嵌入业务系统的第三方代码。 当第三方SaaS、CDN、Cloudflare Worker、DNS、API密钥和JavaScript形成完整依赖链之后，传统“服务器有没有被入侵”的判断已经远远不够。真正需要回答的是：谁能够修改我的代码？谁能够修改我交付给客户的内容？谁能够代表我的系统访问云平台？如果这个第三方今天被攻破，我有没有能力第一时间发现、切断并恢复？