11 月 8 日到 9 日，两起截然不同但又相互映照的安全事件，把加密基础设施的脆弱面同时暴露出来：一边是去中心化交易所 Arcus，官方在 11 月 9 日披露会计漏洞被利用，漏洞允许运营账户的账面余额记录超过实际持有资产，最终在系统内撕开约 223 万美元 USDG 的缺口；攻击者据称一度尝试提取约 300 万美元，但在跨链桥的速率限制机制下未能瞬间全部转出，Arcus 随后宣布动用公司金库资金全额填平缺口，强调其他用户账户未受直接影响。另一边是闪电网络钱包系统 LNbits，在 11 月 8 日承认存在影响所有 1.7.0 之前版本的钱包漏洞，官方直接将其定性为“旧版资金面临被盗风险”，紧急发布 1.7.0 安全更新，要求运营者升级并迁移到新的服务器环境，同时提醒：若在升级前已有凭证泄露，攻击者可能在升级后继续保持访问权限，需要通过凭证轮换和访问审计等额外运维手段才能真正解除威胁。一个案例体现的是事发之后用金库兜底、把损失锁在系统内部的处理逻辑，另一个案例强调的是尽可能在事前通过补丁和运维把攻击面收窄，两者共同勾勒出当下加密基础设施在事后兜底与事前防护之间难以回避的安全博弈。
Arcus 会计漏洞：虚增余额致223万缺口
回到 Arcus 的案例，项目方在 11 月 9 日把这次事件界定为“会计漏洞”，而不是传统意义上智能合约被攻破。按照官方的说法，系统中存在一类运营账户，其账面记账方式允许余额记录超过真实存入的资产规模，等于给了内层账户一段可以被人为“拉高余额”的灰区。正常情况下，这样的账户应该只在内部运营和资金调度中使用，但一旦被攻击者意识到记账规则与实际资产之间存在错位，就相当于发现了可以在系统内部制造“凭空余额”的入口。
漏洞被利用的过程由此展开：攻击者先通过这套会计逻辑，在系统中制造出远高于真实资产的账面余额，随后再按照常规流程发起提款，最终在账面与链上资产之间撕开了约 223 万美元计价的 USDG 缺口。值得注意的是，在完成这一缺口之后，攻击者并未就此停手，而是进一步提出了约 300 万美元的提款请求；真正阻挡这一步的，不是应用层的风控，而是跨链桥本身的速率限制机制，提款速度被硬性限制，才没有在短时间内放出更大规模资金。Arcus 方面在说明中强调，除这笔由公司金库承担的内部亏损外，其他用户账户未出现直接资金损失，这也让事件的性质被锁定在“金库兜底一笔会计缺口”的范畴之内。
Arcus 金库兜底与速率限制的防线
漏洞被利用后留下的约 223 万美元 USDG 缺口，并没有在用户层面“摊平”，而是被 Arcus 直接认定为运营风险，由公司金库出面全额填补。官方说明中反复强调“未影响其他用户账户”，等于把这笔损失锁定在项目方自担的范围内：一边是被会计漏洞放大的运营账户账面余额，一边是用金库真实资产回填的窟窿，中间的鸿沟由 Arcus 自身资金跨过去。金库兜底的选择，首先说明项目方确实预留了可用的资金缓冲带，其次也是一种姿态——在技术和流程失误导致的事件中，团队愿意把责任收束在公司层面，而不是让链上风险顺着合约逻辑自然传导到所有参与者头上。
与金库兜底同样关键的，是跨链桥速率限制在这次事件里的“被动防守”。攻击方在制造出缺口后，尝试发起约 300 万美元的提款申请，如果跨链桥对资金跨链和提取没有节流设计，这笔资金有可能在极短时间里完成转移。但现实是，速率限制机制让提款被硬性分流，攻击者没能在一个时间窗口内抽离全部目标资金，给项目方保留了处置空间。这个细节，把平时常被视作“体验妥协”的速率限制，转化成了实打实的安全阀。站在 DeFi 治理与用户信任的角度，这次应急方案也暴露出一个长期张力：一方面，中心化金库兜底在事故发生时能迅速稳住局面，保护个体账户不受直接波及；另一方面，它也意味着风险管理的最后一层是由少数主体掌控的资金和决策，去中心化的理想与现实中的容错机制在这里形成难以彻底调和的折中。
LNbits 漏洞波及旧版：1.7.0 升级竞速
几乎在 Arcus 宣布兜底的前一天，闪电网络的钱包系统 LNbits 也被迫按下“紧急刹车”。11 月 8 日，LNbits 官方披露了一项安全漏洞，并明确点名：所有 1.7.0 之前的版本都在影响范围之内。措辞并不含糊——旧版实例中托管的资金被直接定义为“面临被盗风险”，这意味着问题不再是某个特定发行版的偶发缺陷，而是整条版本线都被标记为不安全环境。
在这份警报中，1.7.0 被定位为“安全更新”而非普通迭代，官方要求运营者不仅要尽快完成软件升级，还要将服务迁移到新的服务器环境，以彻底切断潜在攻击路径。LNbits 反复强调时间敏感性，用近乎命令式的语气提醒：拖延升级就等于在为攻击者预留窗口，尤其是那些已经发生凭证泄露的部署，更需要配合凭证轮换和访问审计，才能让升级真正生效。随着公告发出，那些仍在运行旧版 LNbits 的节点和服务商，被集体推上了一场不容缺席的竞速升级赛，安全成为所有运营策略中最先需要兑现的承诺。
泄露凭证阴影下的闪电网络运营风险
LNbits 在公告中点明了一个让运营者难以轻松放下心的事实：即便已经升级到 1.7.0，升级之前被泄露的密钥、令牌或 API 凭证，依然可能让攻击者在新版本上保持访问权限。版本号的跃迁并不会自动使这些“旧钥匙”失效，攻击路径也就没有被完全切断，这直接打破了不少人对“打补丁即可高枕无忧”的技术幻想。
对运行闪电网络钱包的节点和服务商来说，LNbits 的提醒把问题抬升到了运维层面的系统性风险：资金所依赖的不只是代码逻辑，还有散落在各个服务器、脚本和集成服务中的访问控制要素。官方建议迁移至新服务器，本质上是在敦促运营者重新部署整套环境与访问策略，而不是在原有、可能已经被窥探过的基础设施上简单覆盖新版本。凭证泄露往往跨越单次漏洞事件，在时间上具有延续性，如果不在升级动作之外同步完成密钥轮换、清理旧令牌、审计访问日志，这次漏洞就会从一次“修 bug”的插曲，演变成对整体运营安全是否合格的长期拷问。
Arcus 与 LNbits 映照加密安全短板
Arcus 的会计漏洞与 LNbits 的钱包漏洞发生在相近时间，一个落在 DeFi 交易所的账面逻辑，一个暴露在闪电网络钱包的运维面，共同把行业长期忽视的“非纯合约 bug”拉到了台前。Arcus 事件中，运营账户可以在账面上“记出”超过实际持仓的余额，最终形成约 223 万美元 USDG 缺口，攻击者尝试跨链提走约 300 万美元，却被跨链桥的速率限制机制压住节奏，剩余损失由公司金库全额兜底；LNbits 则是在旧版本钱包存在可致资金被盗的漏洞时，选择发布 1.7.0 安全更新，要求运营者升级、迁移至新服务器，并提醒在此之前一旦有凭证泄露，必须通过密钥轮换和访问审计等运维动作才能真正解除隐患。前者用集中金库吸收一次性账面缺口，后者通过强制升级与环境重建降低未来风险，两种响应路径在用户感知上都强调“资金安全”，但长期效果取决于社区如何看待金库兜底的可持续性，以及节点运营者是否真正落实升级、迁移和凭证清理。回到安全本身，这两起事件提示市场，审计不能只盯着合约函数和代码行，还要系统性审视会计逻辑、权限设计、速率限制等架构层风险，持续跟踪 LNbits 升级执行度、运维规范化程度，以及类似 Arcus 的金库兜底模式能否与更严格的事前审计相互补充，才可能在下一轮攻击到来前把这条安全防线真正筑牢。
加入我们的社区，一起来讨论，一起变得更强吧！
AiCoin专属Hyperliquid福利：https://app.hyperliquid.xyz/join/AICOIN88
AiCoin专属Aster福利：https://www.asterdex.com/zh-CN/referral/9C50e2
链上电报（Telegram）社群：https://t.me/AiCoinWhaleData
链上社区：https://www.aicoin.com/link/chat?cid=N6OVMor5g
AiCoin链上推特：https://x.com/aicoinwhaledata
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到[email protected]，本平台相关工作人员将会进行核查。
