2026 年 5 月 25 日，一段名为 SquidRouterModule 的第三方 Gnosis Safe 模块在以太坊和 Base 上被攻击，攻击者在约两小时的时间窗口内，针对安装了该模块的多签钱包连续下手，最终清空了约 86 个 Gnosis Safe，造成约 300 万至 320 万美元损失。被转走的代币被导入攻击者控制的地址，随后通过其自建的 Uniswap V3 资金池换成 DAI 完成变现。链上安全机构 Blockaid 在攻击进行期间捕捉到这波异常操作，点名目标正是以太坊与 Base 网络上的 SquidRouterModule，并提示受影响的钱包规模。事件最初传播时，部分媒体与链上评论将其直接表述为 “Squid 协议被黑”，短时间内放大了对 Squid 安全性的恐慌情绪；但随着 Squid 官方出面声明该模块并非团队构建或运营、漏洞源自第三方 Safe 模块，且 Squid 核心协议与用户资金未受波及，“Squid 被攻破”的叙事被迅速纠偏，而这段已在 Basescan 完成合约验证却身份模糊的第三方模块则被推上了风口浪尖。
命名撞车：一场被错认的“Squid被黑”
这场攻击一开始之所以被迅速包装成“Squid 被黑”，很大程度上源于命名本身的误导：被锁定的目标叫 SquidRouterModule，听上去像是 Squid 官方的路由合约，且部署在以太坊与 Base 两条主流网络上，是某第三方智能钱包产品中负责聚合路由的 Safe 模块。该模块本身集成了 Squid 及其他服务，并在 Basescan 上完成了合约验证，但开发方与部署者身份在公开材料中并未被清晰标注。攻击发生后，链上安全机构报告中反复出现的 “SquidRouterModule” 字样，很容易在传播链条中被简化为 “Squid Router 被打穿”，部分媒体和链上评论也顺势将叙事滑向“Squid 协议遭到攻击”。
意识到舆论正在把一个第三方 Safe 模块事件，演绎成对核心协议的质疑之后，Squid 官方迅速出面切割边界：声明中明确指出，本次漏洞来源于第三方 Gnosis Safe 模块，与 Squid 团队构建、部署或运营的任何合约无关；Squid 核心协议与合约未受影响，所有 Squid 用户与集成方无需采取任何行动。误报与澄清交错的过程，把 DeFi 多层集成下的认知风险暴露得很直观：当不同项目在模块命名上高度相似、甚至直接叠加品牌词时，一旦某一层出现安全事故，最先被冲击的往往是最显眼的名字本身，哪怕它在技术上并不是真正的“故障源头”。
两小时清空86个Safe：攻击路径的可见部分
时间线往回拨到 5 月 25 日，Blockaid 监测到一段异常密集的链上活动：在约两小时的窗口内，以太坊与 Base 两条网络上，安装了 SquidRouterModule 的 Gnosis Safe 开始“按批次”被清空。所有已知受害者几乎拥有同一个共性——都集成了这枚第三方模块，攻击也始终沿着这一模块所在的钱包展开，最终被统计为约 86 个 Safe 失守。
从链上可见动作看，攻击者在锁定目标 Safe 后，会将其中的代币逐一转出至其控制的地址，随后再集中导入由其控制的 Uniswap V3 资金池，将不同资产统一兑换为 DAI。整个过程中，代币迁移路径与兑换行为清晰可见，但攻击者如何在合约层面取得这些 Safe 的操作权限、具体利用了模块中的哪一处设计或漏洞，目前尚无公开、可验证的技术披露。到目前为止，公开材料能讲清的，只是这场攻击在两小时内横跨两条链、清空 86 个 Safe 并将资产收束为 DAI 的表面路径，至于背后的攻击向量与完整资金去向，还停留在待确认的状态。
Safe模块的黑盒风险：谁在为集成背书
Gnosis Safe 的设计初衷是通过模块化架构，把多签金库变成可扩展的“操作系统”：任何第三方开发者都可以部署模块，智能钱包产品再把这些模块打包成一键调用的功能，直接塞进用户的 Safe。此次遭攻击的 SquidRouterModule 就是这样的第三方模块，它并非由 Squid 团队构建，而是某智能钱包产品的一部分，该产品在同一界面下集成了 Squid 及其他服务，让用户以为自己只是在用一个“功能按钮”，实际却是在授权一个独立开发方编写的合约逻辑。
在链上，这个模块在 Basescan 上完成了合约验证，“已验证”这一标记在普通用户眼中很容易被误读为某种安全背书，但它仅意味着源代码与链上字节码匹配，并不等于经过 Gnosis Safe 官方或专业审计机构的审查。更微妙的是，部分社区评论认为受害者多为自定义或第三方创建的智能钱包，而非官方模板，但这一说法目前尚未得到证实。对终端用户来说，当他们在 Safe 界面里看到“Squid”这样熟悉的名字，很自然会把模块与 Squid 官方协议画上等号，却很难分辨背后究竟是谁在开发、谁在集成、谁在审查，从而在开发方、集成方与基础平台共享同一品牌与入口的结构下，把原本复杂的责任边界想象成了一个单一的“官方”，在这一结构下，Safe 生态的模块自由度与用户对“谁在负责”的想象，已经形成了一道难以忽视的安全灰区。
Blockaid预警与项目澄清：从恐慌到纠偏
当攻击者在以太坊与 Base 上批量扫空安装了 SquidRouterModule 的 Gnosis Safe 时，最先把这一异常串联成事件的是链上安全机构 Blockaid。其在攻击仍在进行时就给出预警：目标是名为 SquidRouterModule 的 Safe 模块，集中发生在约两小时内，约有 86 个 Safe 钱包被清空，损失在数百万美元级别。这一表述，把攻击范围收拢在“安装了特定模块的钱包”这一圈层，也在客观上为后续厘清责任边界提供了坐标。
但在信息滞后的传播链条中，早期媒体与部分链上评论仍沿用“Squid 被黑”“SquidRouter 协议遭攻击”这样的说法，把一个模块级漏洞直接上升为协议层事故。直到 Squid 官方迅速发布声明，反复强调漏洞来源于第三方 Safe 模块、与 Squid 核心协议及合约无关，并表示所有 Squid 用户与集成方未受影响、无需采取行动，这一叙事才被硬生生拉回到模块层面。值得注意的是，截至目前，公开资料中尚未出现关于补救路径、潜在资金追回、受害者赔付或后续审计安排的明确说明，在更多技术细节与责任安排公开之前，这场攻击在市场层面的定价与情绪反应，都只能停留在这组尚不完整的碎片事实之上。
从被误读的黑客案中，DeFi该记住什么
这起在约两小时内清空约 86 个 Gnosis Safe、造成约 300 万至 320 万美元损失的攻击，给模块化钱包生态同时敲了两记警钟：其一，真正被攻破的是挂在 Safe 上的第三方 SquidRouterModule，而不是任何“核心协议”，说明在多签、智能钱包这类基础设施之上，最薄弱的往往是外接模块；其二，从一开始“Squid 被黑”的舆论误读，到官方再三澄清漏洞源于第三方 Safe 模块，这条叙事扭曲链表明，命名与品牌在 DeFi 安全感知中已经变成系统性风险的一部分。对个体用户来说，这起事件的直接教训是：在为钱包安装模块、为合约授权时，不能只看界面上的熟悉名字或 logo，而应主动确认模块由谁开发、谁部署、责任主体是否清晰，必要时比对链上合约信息，避免把对知名协议的信任“顺延”给一个来路不明的集成方。对整个生态而言，关键的后续观察点还在路上：包括漏洞根因的公开复盘何时到位，Gnosis Safe 及其他智能钱包是否会收紧第三方模块的准入、展示和风险提示机制，以及像 Blockaid 这样的安全机构如何在监测之外，提供更可读、能区分“协议本体”与“第三方模块”的预警体系，最终如何在可组合性与安全性之间重划边界，将是接下来 DeFi 基础设施必须持续回答的问题。
加入我们的社区，一起来讨论，一起变得更强吧！
链上电报（Telegram）社群：https://t.me/AiCoinWhaleData
链上社区：https://www.aicoin.com/link/chat?cid=N6OVMor5g
AiCoin链上推特：https://x.com/aicoinwhaledata
AiCoin专属Hyperliquid福利：https://app.hyperliquid.xyz/join/AICOIN88
AiCoin专属Aster福利：https://www.asterdex.com/zh-CN/referral/9C50e2
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
