以太坊 Glamsterdam 升级存款漏洞修复完成，操作员盗取质押 ETH 的路径已封堵

以太坊开发者成功修补 Glamsterdam 升级中的一处漏洞，该瑕疵原本可能让操作员通过「同一公钥同时作为 Builder 与验证者」的账务混淆，领走质押服务为新验证者准备的 ETH；Justin Traglia 于 10 月 27-28 日将修补合并进以太坊共识规范，目前没有任何资金损失回报。

漏洞机制：操作员通过公钥复用混淆账务、吞走质押 ETH 的五步路径

依 Avsetsin 推演的情境，此漏洞需要以下具体步骤才能被利用：

步骤一：操作员以公钥 K 向 Glamsterdam 升级后的系统注册为 Builder

步骤二：质押服务（如 Lido）接着用同一公钥 K 存入 ETH，准备启动新验证者

步骤三：升级草稿规则将两笔存款均记到 Builder 名下（账务混淆）

步骤四：操作员以 Builder 身份提领协议资金（质押服务的 ETH）

步骤五：验证者从未被建立，质押服务无法取得能证明资金存在、进而追回款项的凭证

Avsetsin 同时分析了 Lido、Origin 与 Rocket Pool 各自的受影响方式。他强调，既有的检查（拒绝先前的 Builder 存款）已能挡下此路径，不是已确认的实际攻击；事后也没有任何损失回报。

修补提案时程：10 月 23 日重开、周一合并进共识规范

依 GitHub 公开记录，修补提案的完整时程如下：维护以太坊共识规范的 Justin Traglia 于 10 月 19 日以「客户端目前的支持度不足」为由关闭修补提案，暂缓此项变更；Avsetsin 于 10 月 23 日补充测试后，提案重新开启；Traglia 随后于周一（约 10 月 27-28 日）将此修补合并进以太坊共识规范。

此次修补提案能在测试延期空出的时间窗口内翻盘通过，部分原因在于 Hoodi 测试网的延期提供了额外的审查与实施时间。

修补技术细节：改以提款凭证排序存款、防止验证者存款流入 Builder 账户

依 Glamsterdam 共识规范更新，修补方式是改以提款凭证（withdrawal credentials）来排序待处理的存款；提款凭证决定一笔存款最终能流向何处，因此即使 Builder 使用了与验证者相同的公钥，验证者的存款仍会根据提款凭证归属而留在验证者名下，不再被误记到 Builder 账户。

此项变更目前已纳入以太坊共识规范，但各客户端团队仍须将新的存款排序规则实施进自家软件，方视为完全落地；客户端实施进度将直接影响主网是否可排程。

Glamsterdam 部署进度：Sepolia 已完成、Hoodi 延期、主网时程待定

Glamsterdam 已在 Sepolia 测试网完成一轮测试；第二个测试网 Hoodi 的升级上线原定于 10 月 26 日，因故延后，新日期尚未公布。主网时程需等 Hoodi 完成一轮测试后才有着落。此次漏洞由质押服务端的 Lido 社区成员 Avsetsin 发现，而非核心客户端团队，显示外部大型质押协议正逐渐补位 Glamsterdam 的安全审视。

对照此前 ChainSecurity 找出 13 个受影响合约，Glamsterdam 目前累积的安全发现多集中在「存款与入账」这条路径上。

常见问题

此漏洞是否有导致实际资金损失？

依 Avsetsin 的声明及 Glamsterdam 修补公告，此漏洞属于条件式的代码发现，不是确认的实际攻击；既有的检查（拒绝先前的 Builder 存款）已能挡下此攻击路径，事后也没有任何损失回报；整个修补过程中目前没有传出任何资金损失。

修补已合并进共识规范，是否代表漏洞已完全修复？

依 Glamsterdam 技术说明，此修补目前已纳入以太坊共识规范，但各客户端团队（负责验证者参与网络的各种软件）仍需将新的存款排序规则实施进自家客户端软件，方算完全落地；客户端实施进度是决定 Glamsterdam 是否可继续排程主网的关键步骤。

Glamsterdam 主网上线的时程目前处于什么状态？

依现有公开信息，Glamsterdam 已在 Sepolia 测试网完成测试；第二个测试网 Hoodi 的升级上线于 10 月 26 日延后，新日期尚未公布；主网时程需等 Hoodi 完成一轮升级后才能确定，各客户端也需完成新规则的实施。