安全指南

Trigger.dev 安全事件（2026年11月）：0.66% 客户的根 API 密钥和环境变量被访问，请重新生成密钥并轮换凭据

Trigger.dev 11月6日报告：0.66% 的客户受影响，攻击者获取了根 API 密钥。如何确认是否收到通知、重新生成密钥并轮换凭据。

发布于 2026-11-05 更新于 2026-11-07 最后核实 2026-11-07 3 分钟阅读

本页目录

适用对象：在 Trigger.dev 上运行任务或作业，并把 API 密钥、数据库连接信息或云凭据保存在环境中的开发者和团队。本文基于 Trigger.dev 的博客文章和状态页面，不涉及攻击手法。

后续报告已发布：本文将随机构发布更多信息而更新

适用对象: 在 Trigger.dev 上运行任务或作业，并把 API 密钥、数据库连接信息或云凭据保存在环境中的开发者和团队。
已确认的影响范围查看表格 ↓: 受影响客户的占比
根 API 密钥
环境变量
另外1项
运行、部署和定时任务的列表及元数据
尚未确认的事项: 攻击途径（公司为保护调查和客户而不披露）
未经授权的访问从何时开始，持续了多久
受影响客户的实际数量
另外1项
所获取的信息是否被实际滥用
现在要做的事查看步骤 ↓: 查看是否有通知：邮件和控制台横幅都要看
如果受影响，请重新生成您的 Trigger.dev API 密钥
如果受影响，请轮换环境中的凭据
另外3项
在签发服务处检查用量、日志和账单
用新值重新部署，确认任务能运行
设置支出上限，把密钥拆分为小权限的密钥
核实来源（出处）全部来源 ↓: Trigger.dev，博客，事件报告（2026年11月6日）— trigger.dev/blog/security-incident-report-nov-2026
最后核实: 截至2026年11月7日（JST）

续报计划与核实记录

公司在11月6日发布了报告，内容涉及攻击者被阻断、受影响客户的占比、被获取的内容以及客户应采取的措施。公司称将在能够负责任地公开时分享攻击途径。我们于2026年11月7日（JST）查看时，没有发现进一步的更新。

Trigger.dev 用户今天应该做什么

查看是否有通知：邮件和控制台横幅都要看

公司称，受影响的客户已在11月1日（约21:36 UTC）和11月2日（20:27 UTC）收到邮件，并会在控制台中看到通知横幅。请先确认您组织的所有者是否收到了邮件（包括垃圾邮件文件夹），以及控制台是否显示横幅。

公司称，没有收到影响通知的客户未受影响。如果不确定，公司请您用账户邮箱地址写信给 help@trigger.dev，并称会优先处理与此事件相关的支持请求。

如果受影响，请重新生成您的 Trigger.dev API 密钥

公司称，攻击者获取了根 API 密钥，公司已吊销受影响环境中可能受影响的密钥。重新生成的说明已通过邮件发给受影响的客户。如果 CI 或应用仍在使用旧密钥，请替换为新密钥。

公司已发布面向范围受限 API 密钥的 IP 限制以及 OIDC 支持。重新签发密钥时，如果适合您的环境，请加以使用。

如果受影响，请轮换环境中的凭据

这包括受影响环境中的数据库密码、第三方 API 密钥、访问令牌等。请按这个顺序操作：在签发服务处吊销旧凭据（AI 服务商、云、数据库、支付、邮件），创建新凭据，在 Trigger.dev 中设置并重新部署。在 Trigger.dev 中编辑或删除变量，并不能阻止别人已经拿到的副本。

公司称，环境变量在静态存储时是加密的，仅在运行执行时即时解密。但根密钥可完全访问环境的设置，包括其环境变量，因此最稳妥的做法是把受影响环境中的这些变量视为已被取走。

在签发服务处检查用量、日志和账单

在我们读到的来源中，公司没有说明未经授权的访问从何时开始，因此按本站的经验法则，请至少回溯到10月下旬，并把时间窗口放宽。在各个签发服务处，打开用量、访问日志、密钥列表和账单，查看不认识的请求、异常的模型或区域，以及费用的突然上升。

对于数据库，还要查看来自陌生来源的连接，以及您平时不会运行的作业。如果发现可疑使用，请向签发机构报告，并同时替换该环境中的其他密钥。

用新值重新部署，确认任务能运行

设置新值之后，重新部署，并确认正在运行的任务和定时任务能用新值正常工作。由于旧密钥已被吊销，遗漏的变量会让任务失败。可以利用这些失败找出哪个变量仍是旧的。

设置支出上限，把密钥拆分为小权限的密钥

在 AI 服务商和云处，设置每月预算上限和提醒。为每个密钥限定单一用途和最小权限，并按应用和环境使用不同的密钥。密钥越小，泄露造成的损失越小。关于不让密钥进入代码和日志的基础知识，参见.env和API密钥到底危险在哪里。

发生了什么（依据 Trigger.dev 的公告）

以下内容基于公司11月6日的报告、11月1日的博客文章和状态页面条目。11月6日的报告是作为首次披露的后续发布的。

11月1日
公司获知此事件。基础设施告警标记出异常活动；公司判断其为恶意行为，阻断了攻击者并缓解了攻击途径。在博客上首次披露。
11月1日约21:36 UTC
向受影响的客户发送第一封邮件。
11月1日 22:50 UTC
创建同名的状态页面条目。
11月2日 20:27 UTC
向受影响的客户发送第二封邮件。
11月6日 12:27 UTC
状态页面条目被标记为“Resolved”（已解决），并链接到11月6日的报告。
11月6日
公司发布更完整的报告：0.66% 的客户受影响、根 API 密钥被获取、返回了哪些内容，以及客户应怎么做。
11月7日
本站复查。没有发布进一步的更新。

公司的说法

0.66% 的客户。根 API 密钥被获取，环境变量被访问，返回了运行、部署和定时任务的数据

未说明

攻击途径（未披露）、开始日期、实际客户数量、是否被滥用

如果受影响：重新生成 API 密钥，然后在签发服务处吊销并替换该环境的凭据。

公司说了什么，没有说什么

报告所述内容（Trigger.dev，2026年11月6日）

影响: 全部客户的 0.66%。攻击者获取了部分客户环境的根 API 密钥，并访问了这些环境的环境变量
返回的内容: 在部分环境中，返回了最近的运行、部署和定时任务的列表：ID、任务名称、运行幂等键、运行状态、标签、部署元数据和错误、定时任务的外部 ID 以及运行元数据
未发现: 没有发现其他客户数据、其他服务、公司自身的生产数据库或客户控制台账户被访问的证据（公司）
公司的应对: 阻断了攻击者并缓解了攻击途径，作为预防措施轮换了内部凭据，审查了日志，通知了受影响的客户，吊销了可能受影响的 API 密钥，实施了基于风险的自动账户限制，聘请了事件响应专家，并通知了执法部门
未披露: 攻击途径（为保护调查和客户）、开始日期、实际客户数量、是否有任何内容被滥用

已知与未知

以下为截至2026年11月7日（JST）的状态。标为“未说明”的项目不在我们所读到的公司报告中；并不表示已确认安全。

项目	公司的说法	状态
受影响客户的占比	全部客户的 0.66%	已确认（公司）
根 API 密钥	攻击者获取了部分客户环境的根 API 密钥	已确认泄露（公司）
环境变量	攻击者获得了未经授权的访问	受影响（公司）
运行、部署和定时任务的列表及元数据	在部分环境中被返回	已确认泄露（公司）
其他客户数据、其他服务、公司自身的生产数据库、控制台账户	没有证据显示它们被访问	未确认（公司）
Webhook 签名密钥	未暴露	不包含（公司）
自托管部署	未受影响	不包含（公司）
没有收到通知的客户	未受影响	公司说明
攻击途径	为保护调查和客户而不披露；将在能够负责任地公开时分享	调查中（公司未披露）
访问何时开始、持续多久	在我们所读到的报告中未说明	未说明
受影响客户的实际数量	只有占比（0.66%）	未说明
所获取信息是否被滥用	未说明	未说明

如何理解：变量中的凭据是否被使用，目前仍不清楚

公司把已被获取的内容与没有证据显示被访问的内容区分开来。公司没有说明存放在环境变量中的凭据是否被实际使用。如果您受到影响，不要等到确认它们没有被使用；请先在签发服务处吊销。

环境变量被访问可能导致什么

一般而言，从环境变量中被访问的密钥可能被如下滥用。这并不表示此处已发生所有这些情况。

AI 服务 API 密钥：别人以您的账户发送请求，由您承担账单，或者密钥被转售
数据库密码和连接字符串：读取或更改您应用的数据，包括您自己用户的记录
云和支付密钥：创建资源或发起产生费用的调用
签名密钥：接受伪造的请求，或伪造会话

此次返回的运行和部署元数据（任务名称、标签、错误）本身不是机密，但它暗示了您使用哪些服务以及如何使用。这可能被用来编造有针对性、令人信服的消息。

后台任务平台的特点是把许多外部服务的凭据集中放在一处。如果一个平台的变量被看到，多个服务的密钥可能同时面临风险。关于其他涉及环境变量和机密的案例，参见Northflank、Zeabur和Railway。它们是各自独立的案例，没有任何一起被确认与此事件有相同的原因。

面向运营方：从公司披露内容中得到的教训

这些要点来自公司公布的事实，并不是对 Trigger.dev 的进一步评判。

接近根权限的密钥可触及整个环境的设置。公司称，获取根 API 密钥即可访问环境变量。请按用途拆分平台密钥，并尽可能使用公司已发布的收窄选项，如 IP 限制和 OIDC。
通知通过邮件和控制台送达。请把所有者地址设为在人员离职后仍然有效的共享邮箱，避免被垃圾邮件过滤，并定期查看控制台横幅。
让交给平台的密钥能够快速替换。针对每个签发机构，事先确定如何吊销和重新签发，并按环境和用途拆分密钥，以便在通知到来的当天就能采取行动。
给存放在变量中的密钥最小的权限。如果一个平台的变量被看到，损失取决于每个密钥能做什么。

信息来源（公开记录）

本文的事实基于下列公开信息。对于公司尚未披露的攻击途径及其原因，我们不做猜测。

Trigger.dev，博客，事件报告（2026年11月6日）— trigger.dev/blog/security-incident-report-nov-2026
Trigger.dev，博客，“Security Disclosure: Sunday November 1st”（2026年11月1日）— trigger.dev/blog/security-incident-nov-2026
Trigger.dev，状态页面，“Security Disclosure: Sunday November 1st”（2026年11月1日22:50 UTC创建；11月6日12:27 UTC标记为已解决，并链接到11月6日的报告）— status.trigger.dev/incident/1110434

更新记录

2026-11-07：新增公司11月6日的报告：0.66% 的客户受影响，根 API 密钥和环境变量被获取，返回了运行、部署和定时任务的数据，攻击途径未披露。操作步骤现以查看通知（邮件和控制台横幅）、重新生成 API 密钥和轮换环境凭据为核心；并补充了 Webhook 签名密钥未暴露、自托管部署未受影响。 2026-11-05：首版。基于 Trigger.dev 截至2026年11月5日的博客和状态页面。

FAQ

QTrigger.dev 发生了什么？

据 Trigger.dev 称，基础设施告警在11月1日标记出异常活动。公司判断其为恶意行为，并阻断了攻击者。攻击者获取了部分客户环境的根 API 密钥，并访问了这些环境的环境变量。在部分环境中，攻击者还列出了最近的运行、部署和定时任务。公司称全部客户的 0.66% 受到影响。

Q我的组织受影响吗？

公司称，受影响的客户已在11月1日（约21:36 UTC）和11月2日（20:27 UTC）收到邮件，并会在控制台中看到通知横幅。公司称，没有收到影响通知的客户未受影响。请查看所有者的收件箱（包括垃圾邮件）以及控制台。如果不确定，公司请您用账户邮箱地址写信给 help@trigger.dev。

Q如果我受到影响，应该怎么做？

公司给出两个步骤。第一，重新生成您的 Trigger.dev API 密钥；说明已通过邮件发给受影响的客户。第二，轮换受影响环境中的凭据，如数据库密码、第三方 API 密钥和访问令牌，并在各服务商处吊销旧凭据。公司已吊销了可能受影响的 API 密钥。

Q事件是由什么引起的？

未披露。公司称，为保护调查和客户，不披露攻击途径，并将在能够负责任地公开时分享。

Q需要轮换 Webhook 签名密钥吗？

公司称 Webhook 签名密钥未暴露，无需轮换。这是关于公司自身 Webhook 签名的说明。如果受影响的环境中存放了其他服务的凭据，请按上述方式轮换。

Q自托管部署受影响吗？

公司称自托管用户未受影响。对于自托管，公司建议将 WHITELISTED_EMAILS 设置为您控制的账户，以单租户模式运行。

Q如果收到自称来自 Trigger.dev 的消息怎么办？

不要打开邮件或消息中的链接。请直接打开您收藏的控制台，以及公司的博客和状态页面。公司称已通过邮件和控制台横幅联系受影响的客户，但公告没有说明如何识别发件人。切勿在回复或表单中提供密钥的值或验证码。

Q如何检查我的密钥是否被滥用？

如果您受到影响，请针对环境中存放的凭据，打开各签发服务的用量、访问日志和账单页面（AI 服务商、云、支付、邮件）。在我们读到的来源中，公司没有说明访问从何时开始，因此按本站的经验法则，请至少回溯到10月下旬并扩大范围，留意不认识的请求或费用的突然上升。