背景

2026年6月18日、イーサリアムのレイヤー2プライバシー・プロトコル「Aztec Connect」のRollupProcessorコントラクトが攻撃を受けました。攻撃者は、そのEscape Hatch（脱出装置）メカニズムを利用し、Solidity層で独立した資金の帰属と払戻し限度の検証が欠けているという信頼境界の欠陥、ならびに関連する回路の制約の欠落により、TurboVerifierが受理するescape hatch proofを提出。コントラクトの残高から直接1,158 ETH（約206万ドル）を抜き取り、さらに同一メカニズムで150,000 DAIと0.47 renBTCを盗み取りました。合計損失は約222万ドルです。

攻撃概要

攻撃トランザクション：

脆弱性の根本原因

escapeHatch() の信頼境界の欠落

RollupProcessor の公開入口関数 escapeHatch() は escape hatch の状態が有効かどうかのみを確認し、その後ただちに processRollupProof() に入る。呼び出し元の権限検証は一切実行しない：

それに対し、通常のロールアップ処理パス processRollup() は rollupProviders[provider] の認可を検証し、さらに provider の signature を検証する。本攻撃では escapeHatch() を呼び出し、signatures = 0x、viewingKeys = 0x を渡すことで、provider の認可フローを完全に回避している。

verifyProofAndUpdateState() が Verifier に盲目的に信頼している

processRollupProof() に入った後、コントラクトが TurboVerifier.verify(proofData, 0) を呼び出す：

TurboVerifier 自体の挙動は正しい——それは Plonk 証明の数学的検証を完了する。真の問題は、RollupProcessor が数学的検証成功を業務上の合法性と同一視し、Solidity 層でさらに独立した検証を行っていない点にある。

processDepositsAndWithdrawals() は払い出しを無条件に実行

Verifier が成功を返した後の中核となる実行ロジック：

最終的な資金転出関数：

zkSNARK 回路に等式制約ゲートが欠落（根本原因）

Aztec の join-split 証明回路において、old_data_root は2つの独立した経路に分けられて使用される：

• 内部証人 A：join-split サブ回路を渡し、プライベートノートの Merkle メンバーシップを検証する

• 公開入力 B：公開入力として Solidity 層に露出し、validateMerkleRoots() がチェーン上の dataRoot と照合するために使用される

回路に制約 A == B が欠落しているため、両者を独立に割り当て可能：

• A は攻撃者が構築した偽の Merkle 木ルート（木の中に任意の金額のノートが含まれる）になり得る

• B は実際のチェーン上の dataRoot（Solidity のチェックを通過させる）になり得る

制約システムが A ≠ B を許容しているため、zkSNARK 証明全体は依然として有効である。

攻撃手順

準備段階：偽の Merkle 木と proof を作成

攻撃者がローカルで偽の data Merkle 木を構築し、木に1つの秘密ノートを挿入する：

• 価値：1158 ETH（コントラクトが当時保有していたのは約 1158.7598 ETH）

• 所有者：攻撃者が対応する秘密鍵を保有

攻撃者が zkSNARK 証明を構築：

• 内部証人 A（old_data_root）＝偽の木のルート

• 公開入力 B（old_data_root）= チェーン上の実際の dataRoot = 0x184bea7d9493cd9a5efb6b679d04066a8c92a34ac8ec150e9635133c6010977b

第1段階：攻撃トランザクションの構築

攻撃者の EOA 0x6952d9246e9aFE8B887B2877225163436F78E97F が直接 RollupProcessor（0x737901bea3eeb88459df9ef1be8ff3ae1b42a2ba）にトップレベル呼び出しを行う：

• 関数シグネチャ：escapeHatch(bytes,bytes,bytes)

• msg.value = 0

• signatures = 0x

• viewingKeys = 0x

攻撃者が作成した proofData には重要な public inputs が含まれている：

第2段階：権限チェックを回避

escapeHatch() は getEscapeHatchStatus() が true を返すことだけを確認した後、ただちに processRollupProof() を呼び出す。この経路では通常の processRollup() にある rollupProviders[provider] の認可チェックを実行せず、また provider の signature も検証しない。呼び出し元の身元と払い出し受取人の間に何の結び付きもない。

第3段階：Verifier の数学検証

RollupProcessor が TurboVerifier（0x48cb7ba00d087541dc8e2b3738f80fdd1fee8ce8）に STATICCALL を発行：

rollup_size = 0 のため、TurboVerifier は VerificationKeys.getKeyById(0) により EscapeHatchVk（vk.num_inputs = 26）を選択し、Plonk 証明の数学的検証を行う。Verifier は proof と public inputs の数学的整合性のみを検証し、RollupProcessor の状態を読み取らず、残高の帰属も検査しない。

本トランザクションで verifier の呼び出しが成功して返っていることから、攻撃者が提出した escape hatch proof が数学的に正しいことがわかる。

第4段階：払い出しの実行

Verifier が成功を返した後、RollupProcessor がロールアップ状態を更新：

その後 processDepositsAndWithdrawals() に進み、escape hatch モードでは rollupSize == 0 でも 1 件の inner tx として処理される。proofData を解析すると：

withdraw(1158 ETH, 攻撃者アドレス, 0) を直接呼び出し、receiverAddress.call{value: 1158 ETH}("") により資金を転出する。

第5段階：DAI と renBTC で同パターンの攻撃

攻撃者は同時期にまったく同一の脆弱性パスを使い、それぞれ ERC20 資産（assetId ≠ 0）向けの escape hatch proof を構築して、150,000 DAI と 0.47 renBTC を RollupProcessor から窃取した。withdraw() 関数の assetId ≠ 0 分岐で ERC20 の transfer() が実行され、送金が完了する。

3件の攻撃の純利益：

資金追跡

遅霧 MistTrack の反マネーロンダリング追跡システムで、攻撃者の EOA 0x6952d9246e9aFE8B887B2877225163436F78E97F を分析：

資金の出所：攻撃者が作成したアドレスの初期ガスは 0x963737c550e70ffe4d59464542a28604edb2ef9a（unionchain.ai のエンティティアドレス）から来ている。このアドレスは 2026 年 6 月 18 日 02:21:11 UTC に初めて稼働し、攻撃行動の開始時刻とちょうど一致しており、本攻撃のために作られた使い捨てアドレスである。

資金の行き先：盗まれた資金の現在の分布は以下の通り：

• 802 ETH トークンは依然として攻撃者のメインアドレス 0x6952d9246e9aFE8B887B2877225163436F78E97F に残っており、 150,000 DAI と 0.47 renBTC も同様にまだ移転されていない

• 300 ETH が 0x15930a0fef3421f48c6553b5691682cc1b22edb3 に送金された（MistTrack は Aztec Exploiter 関連の悪意あるアドレスとしてマーク）

• 約 56 ETH が別の悪意あるアドレスに送金された（同様に Aztec Exploiter 関連としてマーク）

• 0x33d6a0d9bc210e823e043d604179cd844eb467df の AML リスクスコア 100/100（Severe）。同様に Aztec Exploiter の事案に関与

まとめ

今回の攻撃の核心的な教訓は：zkSNARK 回路の「数学的正しさ」≠「業務上の安全」であるということだ。検証者は「制約を満たすある証人を知っていること」を証明できるだけであり、もし制約自体が間違っている（または欠けている）なら、証明システムは合法的な偽造マシンになってしまう。SlowMist セキュリティチームは、すべてのゼロ知識証明の制約パスについて特別な監査をプロジェクト側に行うことを推奨する。回路の安全性を確実にするためだ。

本記事は SlowMist 脅威インテリジェンスチームが MistEye 脅威インテリジェンスシステム、MistTrack 追跡プラットフォーム、および SlowMist Agent AI を用いた分析を組み合わせて作成した。問題があれば相談・フィードバックを歓迎する。