密钥管理
该标签下有 23 篇文章
Fireworks AI 安全事件（2026 年 10 月）：账单数据以及部分数据集和模型权重受影响，公司称涉及云服务商遭入侵。客户应怎么做
提供 AI 模型推理基础设施的 Fireworks AI 在 2026 年 11 月 9 日，更新了其 10 月 9 日首次披露的安全事件。据公司称，10 月 6 日发现的最初事件，当时已知只涉及 Fireworks 存储的密钥（例如评估任务中使用的密钥）；此后公司发现账户和账单信息受到影响，而在一小部分账户中，密钥、数据集和不完整的模型权重也受到影响。据其说法，托管其研发机器的一家第三方云服务商在 10 月 23 日发生安全事件，10 月 24 日一名未经授权的第三方借此进入 Fireworks 的开发机器并运行了未经授权的工作负载，造成了额外的客户数据影响。公司当天即发现此事，截至 10 月 25 日，没有再发现攻击者成功访问客户所用平台的证据。公司称，证据表明此事与一个以牟利为目的的网络犯罪团伙有关。公司不存储支付卡号，卡号未受影响。Inference、Training SDK 和 Nexus 默认零数据留存，未发现受到影响。调查期间，自助式数据集的上传和下载已被停用。本站的看法：客户应盘点并轮换自己存放在该平台上的内容；运营者应让开发环境与账单和客户数据系统保持隔离。
NEAR AI 因推理引擎漏洞遭入侵（约 100 名用户的账户信息）：已确认的事实，以及用户和 AI 基础设施运营者应怎么做
提供 AI 聊天和智能体服务的 NEAR AI 在 2026 年 11 月 9 日的官方博客文章中披露，其部分基础设施遭未经授权访问。据公司称，原因是其服务器上运行的开源推理引擎 SGLang 存在远程代码执行漏洞；攻击者在一台推理服务器上运行了代码，并由此进入其他基础设施。公司确认的内容：从已停用的 Private Chat 背后的内部系统中取走了约 100 名用户的账户信息（邮箱地址、姓名，部分账户还有套餐和余额信息）；未在机密计算（TEE）环境中运行的 18 个旧版智能体的聊天记录、设置和日志；另外，两家 Cloud 客户的 NEAR AI Cloud API 密钥曾在日志中暴露（已吊销；报告未说明是否被取走）。11 月 8 日，攻击者还可能观察到被入侵服务器上正在处理的用户请求，其中包括机密模式的请求。公司未发现已存储的 Private Chat 对话或上传文件被访问的迹象。公司称已更换凭据、修复漏洞，并已恢复对 NEAR AI Cloud 的访问（Private Chat 仍处于离线状态）。官方报告未给出 CVE 编号。本站的看法：对 AI 基础设施运营者来说，关键是让推理服务器与内部系统保持隔离、不留下旧环境、不让密钥进入日志。
Ethersphere bee-js 13.3.0 和 Swarm Desktop 0.56.2 带有恶意软件（2026年11月）：受影响版本以及用户该怎么做
去中心化存储网络 Swarm 的开发方 Ethersphere 的 npm 包 @ethersphere/bee-js 的 13.3.0 版本包含恶意代码。2026年11月9日发布的 GitHub 公告（GHSA-hh7j-5m3j-23pf）把 13.3.0 列为唯一受影响的版本，并称没有已修补的版本。公告称，凡是安装或运行了该包的计算机，都应视为已被完全攻陷，其中所有的机密和密钥应立即从另一台计算机上轮换。删除该包可能无法清除安装所带来的全部恶意软件。至于 Swarm Desktop，Ethersphere 的发布说明称，11月9日发布的 0.56.3 取代了被攻陷的 0.56.2。据一家安全公司的分析，bee-js 13.3.0 于11月9日协调世界时约 00:09（日本时间 09:09）出现在 npm 上，约 75 分钟后被撤下。Swarm Desktop 0.56.2 公开了约 8.5 小时，并且通过自动更新送达了 Windows x64 和 Apple Silicon。据报告，bee-js 13.2.0 及更早版本以及 Swarm Desktop 0.56.1 不受影响。同一分析称，Bee 节点的配置文件（其中有明文密码）及其钱包密钥是目标，官方发布自动化所使用的凭据也被滥用。我们的结论：请重建安装过受影响版本的机器或 CI 环境，把钱包迁移到新密钥并转移资金，并从另一台机器上轮换凭据。
mittwald 的 MCP 服务器漏洞被利用，56 个客户项目被攻陷（2026年11月）：已公布的时间线，以及用户和 AI 集成运营者该怎么做
德国网站托管公司 mittwald 在官方博客中表示，其 MCP 服务器（把客户的 AI 助手与其控制面板 mStudio 连接起来）中的一个漏洞被利用，56 个客户项目被攻陷。据该公司称，攻击者于10月21日首次测试该漏洞，从10月23日起用测试账户以普通用户身份活动，并于10月27日 15:03 用另一个账户利用了该漏洞。公司把10月27日以后的所有数据都视为已被攻陷。11月4日发现异常行为，当天公司确认 MCP 服务器是入口并将其关闭。11月6日，公司对 56 个被攻陷的项目和 MCP 服务器进行了取证检查，没有发现更多被攻陷的项目，并称目前检测不到任何攻击者活动。被读取的不是密码，而是用户的会话令牌，公司称已全部撤销。客户中心及其管理的网站未受影响。MCP 服务器仍处于离线状态，是否恢复将在调查后决定。公司称，攻击者的速度表明使用了 AI 工具；这是公司的怀疑。公司称将在下周发布详细说明。我们的观点：对于把 AI 助手连接到托管或生产环境的 MCP 服务器，关键是范围收窄且短期有效的令牌，以及能在试探阶段就发现问题的监控。
Trigger.dev 安全事件（2026年11月）：0.66% 客户的根 API 密钥和环境变量被访问，请重新生成密钥并轮换凭据
运行后台任务和 AI 智能体的平台 Trigger.dev 于2026年11月1日披露了一起安全事件，并在11月6日发布了后续报告。公司称，基础设施告警在11月1日标记出异常活动，公司判断其为恶意行为并阻断了攻击者。此次事件影响了全部客户的 0.66%。攻击者获取了部分客户环境的根 API 密钥；根密钥可完全访问环境的设置，包括其环境变量。在部分环境中，攻击者还列出了最近的运行、部署和定时任务，返回的内容包括 ID、任务名称、运行幂等键、运行状态、标签、部署元数据和错误、定时任务的外部 ID 以及运行元数据。公司称，没有发现其他客户数据、其他服务、公司自身的生产数据库或客户控制台账户被访问的证据。为保护调查和客户，公司不披露攻击途径。受影响的客户已通过邮件（11月1日和2日）和控制台横幅（时间未说明）收到通知，可能受影响的 API 密钥已被吊销。受影响的客户应重新生成 API 密钥，并轮换受影响环境中的凭据（如数据库密码和第三方 API 密钥），同时在签发服务处吊销旧凭据。公司称，没有收到影响通知的客户未受影响，Webhook 签名密钥未暴露，自托管部署未受影响。本站的看法：先查看邮件和控制台横幅；如果受影响，再按公司的指示重新生成密钥并轮换凭据。
Northflank安全事件（2026年10月）：存储的环境变量应视为已被解密，有用户报告AI API密钥遭滥用
2026年10月30日（UTC），云部署平台Northflank在其状态页面发布了一起安全事件。11:43 UTC收到一家安全厂商的威胁告警；公司自12:02 UTC起部署补丁，13:40 UTC通知客户轮换环境变量，13:58 UTC通知客户假定所有环境变量均已被解密。到15:12 UTC，其状态页面已注明多名用户报告其AI密钥被使用，23:38 UTC又表示有用户报告平台上存储的AI API密钥遭未经授权使用。10月31日，公司为所有客户启用了审计日志，并逐个类型发布了附加组件的密钥轮换。11月2日的更新（11:09 UTC，状态为Monitoring）中，公司表示认为已在首次告警后一小时内遏制了攻击，正在运行的工作负载未受影响，也没有迹象表明工作负载或其数据被访问，攻击似乎集中在控制平面中的密钥上。独立的取证审计人员正在审查；公司吊销了访问令牌、会话、VCS集成和跨账户IAM角色（因此用户需要重新登录并重新连接集成），并承诺在调查结果确认后发布根因分析。在11月6日（10:09 UTC）的更新中，公司称已知最早的密钥解密发生在10月30日02:39至03:08 UTC，早于11:43 UTC的首次告警；漏洞在收到通知后60分钟内修补，并在两小时内通知了客户；没有发现客户工作负载或其数据被访问的证据；并已与上游服务商合作，尽可能吊销凭据。取证审查仍在进行。受影响客户的数量、攻击者如何进入以及涉及哪些AI服务商，均未披露。本站的结论是：在签发机构处吊销您存储在Northflank上的每一个密钥，然后查看每家AI服务商的用量和账单，并设置支出上限。
OpenCode Console 安全事件（2026 年 10 月，1.4% 的 Console 用户）：AI 服务商 API 密钥可能已暴露，以及该怎么做
2026 年 10 月 17 日，开源 AI 编程智能体 OpenCode 在其官方 X 账号上表示，前一天晚上发生了一起与大规模蒸馏攻击有关的安全事件，影响了 1.4% 的 OpenCode Console 用户。公司表示，已于当天上午向所有受影响用户发送邮件，没有收到邮件的用户未受影响，受影响用户是关联了外部服务商的部分用户。公司表示，事件仍在进行中，无法透露更多细节，并正在与相关 AI 服务商合作。根据对该邮件及公司说法的新闻报道，用户保存在 Console 工作区中的外部 AI 服务商 API 密钥可能已通过一个旧系统被暴露，受影响用户被告知直接到各服务商处吊销并更换这些密钥。一位联合创始人表示，开源应用和命令行工具未受影响。本站观点：如果您收到了邮件，或者您在 OpenCode Console 中关联过 AI 服务商密钥但不确定是否受影响，请今天就在各服务商的控制台中吊销它们，并检查 10 月 17 日以来的用量和账单。
Zeabur 安全事件（2026 年 10 月，322 万条环境变量被读取）：哪些密钥需要轮换，用户该怎么做
2026 年 10 月 19 日，应用部署平台 Zeabur 发布了关于 10 月 14–15 日（UTC）安全事件的初步报告。公司表示，攻击者利用泄露的 Zeabur 内部凭据进入其共享集群、部分专用服务器（Dedicated Server）和内部系统，并最终在 10 月 15 日 16:10 至 16:47（UTC）之间读取了平台数据库。公司确认，3,218,965 条环境变量记录（名称和值）、321,810 个账户的数据（电子邮件、用户名、电话号码等）以及 566 个 zSend API 密钥被读取，这些 API 密钥已被吊销。公司表示，根本原因在 Zeabur 一方：长期有效的管理员凭据以明文保存，并且可以从公共互联网使用。公司要求所有用户更换存放在 Zeabur 上的所有密码和密钥，即使已在 8 月的另一起事件后更换过。Zeabur 已于 10 月 17 日宣布将于 2026 年 12 月 31 日停止服务，并于 10 月 22 日将此次事件损失索赔的截止日期定为 2026 年 11 月 30 日。本站观点：请把您曾放入 Zeabur 环境变量的每一个密钥都视为已被他人掌握，先在签发方服务处吊销，并检查 10 月 14 日以来的账单和日志。
Railway 环境变量可能已暴露（2026年10月，最多占全部工作区 1.85% 的工作区）：哪些密钥需要轮换，用户该怎么做
2026 年 10 月 21 日（UTC），Railway 宣布检测到存储客户环境变量的系统出现异常活动，未经授权的第三方可能访问了加密的环境变量，并对其中一部分获取了解密后的内容。根据 10 月 22 日的初步报告（按状态页面，于 10 月 23 日 16:38 UTC 公开），攻击从 10 月 20 日 13:58 UTC 持续到 10 月 22 日 03:32 UTC。攻击始于对构建基础设施的权限提升尝试；10 月 21 日，攻击者使用了 CI 环境的凭据，并解密了一部分加密环境变量。据该公司称，最多占全部工作区 1.85% 的工作区（约 100,000 个工作区）的部分环境变量可能已被泄露。公司表示没有 Railway 用户账户被访问，在最终报告发布前尚未排除源代码被访问的可能。攻击者似乎在寻找 AI 服务商的 API 密钥。Railway 建议所有用户轮换 10 月 21 日之前存储的密钥，移除数据库的公网访问，并检查 GitHub 及镜像仓库（如 Docker Hub）的审计日志。本站的结论：即使没有收到通知，也应将存放在 Railway 上的密钥视为已暴露，在来源处重新签发，并先重新部署，再吊销旧值。
LiteLLM 1.107.0 带有凭据窃取程序（2026 年 10 月）：受影响的 PyPI 版本与 Docker 镜像，以及用户该怎么做
2026 年 10 月 21 日（UTC），LiteLLM 背后的公司 BerriAI 宣布其发布流水线遭到入侵，并发布了一个含有恶意软件的 v1.107.0，该恶意软件会窃取凭据并加载远程代码执行工具。受影响的有：PyPI 上的 litellm==1.107.0（11:39 至 13:23 UTC），以及 Docker Hub 上的 v1.107.0、latest、main-latest 和 main-stable 标签（11:46 至 14:20 UTC）和 GHCR 上的同名标签（自 11:46 UTC 起，至 13:51 UTC 前下架，约两小时）。GitHub 上官方的 v1.107.0 源码标签不含恶意文件；这些构建产物是由攻击者控制的仿冒仓库构建的。所有更早的版本都不在此次入侵范围内，公司请用户固定使用 1.106.2 或其他明确指定的更早版本。10 月 24 日（UTC），公司发布了 1.103.8、1.104.6、1.105.4 和 1.106.3，从这些版本起，Docker 镜像和 Helm chart 使用新的 cosign 密钥签名（旧密钥已无法验证）。10 月 23 日，公司发布了根因分析，并更正了最初认为令牌是从内部 LiteLLM 部署的日志中被获取的判断。根据该分析，5 月 27 日一个配置文件被误提交到公开仓库，其中包含某个内部智能体平台的主密钥；该提交被覆盖，但密钥从未被吊销。10 月 10 日，攻击者用该密钥调用该平台的 API，获得了配置在其中的某位 GitHub 组织所有者的 GitHub CLI 令牌。攻击者借此窃取了 CI 机密，进而获得另外两位维护者的令牌，并在 10 月 21 日关闭了分支保护、修改了发布工作流并批准了发布。本站结论：凡是在该时间窗口内安装或启动过 1.107.0 的环境，都应重建，并轮换其可触及的所有密钥，包括 LLM 提供商密钥、代理主密钥、数据库密码和云角色。
公开在 GitHub 上的 543,699 个凭据仍然有效（2026年调查）：为什么要吊销而不是删除，开发者该做什么
一家销售密钥扫描工具的安全公司，检查了为训练 LLM 而收集的约2.24亿个公开仓库的快照，报告称有543,699个凭据在2026年7月下旬仍能通过认证。自暴露以来的时间中位数为784天。npm 和 GitHub 令牌几乎全部失效，而数据库连接字符串有75–88%仍然可用。有效凭据中超过199,000个是在 GitHub 默认开启推送保护之后出现的，超过一半的有效凭据属于推送保护默认不拦截的类型。本站的结论：推送到公开仓库的凭据，无法通过删除文件或改写历史收回，所以要先吊销。泄露的凭据是否会被自动吊销，取决于签发方；连接字符串和许多 API 密钥，在你停用之前一直有效。
TanStack、Nx Console 与 GitHub 的连锁入侵（2026年5月）：开发者需要检查什么
2026年5月11日，TanStack 的 Router/Start 仓库的发布流水线被滥用，向42个 npm 包、84个版本植入了窃取凭据的代码。一名 Nx 贡献者安装了其中一个包，GitHub CLI 令牌被盗；5月18日，被篡改的 Nx Console 扩展（v18.95.0）被发布。同一天，GitHub 表示一名员工的设备因被投毒的 VS Code 扩展而遭入侵，GitHub 内部仓库被外传。三起事件中，攻击都是通过合法的账户和分发渠道进行的，所以防御的关键是：确保仅凭一个被盗的发布凭据（令牌）无法发布新版本，并验证你配置的保护措施确实在生效。
Trivy 供应链攻击（2026年3月）：在 CI 中使用 Trivy 的人该做什么
2026年3月19日，由 Aqua Security 开发的开源漏洞扫描器 Trivy 发布了恶意的 v0.69.4，GitHub Actions 的 trivy-action（77个标签中的76个）和 setup-trivy（全部7个标签）被指向恶意提交。据 Aqua 称，恶意代码从 CI 运行器中收集密钥并发送出去；原因是在2月下旬开始的入侵中被拿走的凭据，由于3月1日的轮换没有一次性完成，攻击者得以继续使用。本站的看法：教训不只是“用提交 ID（SHA）而不是标签来固定 Action”。一个按 SHA 固定的 Action，仍可能按标签调用另一个组件，从而让恶意版本混入。泄露的凭据必须一次性全部替换，否则攻击者可以继续使用。扫描器要放在不持有部署密钥的作业中运行。
Vercel 安全事件（2026年4月）：环境变量外泄后，开发者该做什么
2026年4月19日，Vercel 公开了部分内部系统遭到未经授权访问的事件。据 Vercel 称，一名员工使用的第三方 AI 工具被入侵，攻击者借此接管了该员工的 Google Workspace 账户，进入其 Vercel 账户和一个 Vercel 环境，枚举并解密了一小部分客户未标记为敏感的环境变量。Vercel 已直接联系受影响的客户，并确认其发布的 npm 包没有被入侵。本站的看法：一个变量是否泄露，取决于它的类别：可读（保存后还能再次显示其值）还是只写（可以覆盖，但永远不会显示）。凡是你不需要再读回的密钥，都存为只写（即现在 Vercel 中的 Secret）；员工通过 OAuth（让外部应用访问公司账户的机制）连接到公司账户的 AI 工具，要像依赖一样进行盘点。
npm 供应链蠕虫：凭据如何在安装时被盗，以及如何防御
添加一个依赖，就等于用你的权限运行别人写的代码，所以防线要放在安装的那一刻。本站的看法：签名和来源证明没有挡住这次攻击，因此不能作为信任的依据。有效的是默认禁用安装脚本、新版本发布后等几天再采用、让令牌短期且权限范围窄。如果怀疑已经感染，吊销凭据的顺序很重要。
用 gitleaks 在提交前拦下密钥：在 push 之前堵住 API 密钥泄露
密钥无法『泄露后再删』。一旦被提交，密钥就会留在 Git 历史里，被 push 后就要按已泄露处理，吊销并轮换密钥。gitleaks 是一款免费工具，用正则和熵对整个仓库和提交历史进行扫描，检出 API 密钥、私钥和 token。防守的关键是两处检查：用 pre-commit 钩子在本地 push 前拦住，再用 CI/cron 抓住漏掉的。.gitignore 只能阻止新的追踪，无法检出，所以仍然需要扫描器。
密码管理器安全吗？工作原理与云端、本地的区别，以及如何选择
密码管理器帮助你为每项服务使用强且不重复的密码。零知识加密旨在提供方泄露加密数据时保护内容，但安全性还取决于主密码强度、加密设置和设备安全。通过 MFA 防止未经授权的登录，并按用途选择云端型或本地型。
是否把密钥文件遗忘在了公开目录里：webroot 盘点
放进 webroot 的文件，任何人都能通过 URL 取走。令牌或认证凭据的 JSON、.env、备份一旦遗忘在那里，就会立即暴露；如果源自共用模板，所有站点都带着同一个文件。对策：公开目录只放可以公开的东西，密钥放在 webroot 之外并设为权限 600，一旦发现一处，就排查所有站点和主机。
个人开发 / 小规模运营的安全底线：按优先级排列的行业标准对策
最低限度的对策并非『全都一样重』。本站的优先级 ＝ ①管理账户·域名·邮箱（多因素认证）②密钥与代码 ③应用本体 ④补丁 / 检测 / 恢复。资源有限的个人，按这个顺序从上往下填才是正解。多数事故并非新型攻击，而是这些基本对策的缺失造成的。
安全资产盘点：个人运维多台服务器时最易忽略的 7 项检查
个人运维多台服务器的事故，往往源于「没掌握的状态」而非「缺少防护」。要守的边界是放置密钥的电脑。2FA 按「哪个账号能恢复其他账号」排定优先级（邮箱最先），列出哪把 SSH 密钥能打开哪台服务器，并删除重复、未使用和残留的注册，明文密码从云端清除，整改要可逆且逐项进行，台账里不写机密。比起花哨的新工具，盘点更优先。
自建 Git 服务器和 GitHub，从安全角度看哪个更安全
自建 Git 不是『变安全』，而是『转移风险』。误公开这一类事故确实会消失，但服务器补丁、备份、提交前密钥检测的责任会转移到你身上。能持续做好这些工作就是好选择，放任不管则比 GitHub 更危险。本站视角＝自建运营必须连同补偿性对策一起，否则无法成立。
把密码存到 Google Drive 安全吗？正确的保管方法
把密码以明文形式保存在 Google 文档/电子表格里很危险：一个 Google 账号会成为全部密码的单点故障，账号被盗、恶意关联应用、钓鱼都能让全部密码一次性泄露。最安全的选择是专用密码管理器（即使同步，内容也保持加密）。如果非要用 Drive，就只放加密过的管理文件，并为账号开启抗钓鱼 MFA。
Codecov 篡改事件（2021）——CI 工具被篡改导致机密信息外泄的原因与防御
根源在于『在 CI 中信任并执行的工具（curl|bash 的 Bash Uploader）在上游被篡改』。由于自己的代码毫发无损，约两个月都没能察觉，CI 的机密信息因此外泄。检测靠的是校验和比对。在你的 CI 中，可用取得物的完整性校验、机密的最小权限、轮换、egress 监控来防止重演。