プライバシー保護型の送金基盤zERC20は2026年9月17日、ポリゴン上の「zJPYC」で不正なトークン発行が発生し、約335万JPYCが外部に流出したとするインシデントレポートを公表した。攻撃者は証明システムNovaの既知の脆弱性と、本来無効化すべき一括出金機能が設定ミスで有効になっていた経路を突き、996万5,000zJPYCを不正にミントしている。zJPYCはzERC20が独自に提供する非公式トークンで、JPYC社は提供にも審査にも関与していない。zERC20は全額補償を表明している。
何が起きたか
攻撃は2026年9月13日に発生した。攻撃者は、累計出金額が1,000万zJPYCであるとする無効な証明を提出し、検証コントラクトがこれを受理。償還手数料0.35%を差し引いた996万5,000zJPYCがミントされた。攻撃者はその一部をJPYCに戻し、交換用の資産管理コントラクトが保有していた3,348,497.584171JPYCを全額引き出した。流出したJPYCは分散型取引所でPOLに交換され、223,790POLがクロスチェーン経由で別のチェーンへ移された。不正ミントから資産移動までは約4分だった。残る6,616,502.415829zJPYCは9月17日時点で攻撃者のアドレスに残っている。原因についてzERC20は、4月ごろの監査で判明していたNovaライブラリの脆弱性に加え、ポリゴンとカイアへのデプロイ時に、本来無効化すべき一括出金機能が設定ミスで有効になっていたためだと説明している。他のデプロイでは同じ経路が塞がれており、流出が確認されたのはポリゴン上のzJPYCのみである。
なぜ重要か
日本の金融機関が電子決済手段を扱ううえでの論点は、発行体の責任範囲がどこで切れるかである。今回、JPYC社の準備資産と償還の仕組みは動いており、発行体側の障害ではない。それでも利用者の目には「JPYCが流出した」と映りうる。銀行や決済事業者が自行の電子決済手段を出す場合、第三者が許諾なくラップしたトークンが流通する事態は避けられず、説明責任の線引きと広報対応をあらかじめ設計しておく必要がある。監査済みであることと、本番環境の設定が設計どおりであることは別の話だという点も、内部統制上の教訓になる。
注視点
JPYC社が公式見解を示すかどうか。zERC20が表明した全額補償の実行状況と、停止中の機能の再開時期。カイア上のzJPYCは同じ設定が適用されながら流出が確認されておらず、その扱いも未定である。業界全体では、デプロイ後の設定確認を監査工程に組み込む運用が標準化するかが問われる。制度面では、金融庁が電子決済手段の第三者ラッパーについて監督上の立場を示すかどうかが、国内の実務に影響しうる。
進捗段階
実装トラック ③（第三者提供のラッパーは本番稼働中だが、当該機能は停止。発行体JPYCの本体機能に停止は生じていない）
用語解説
-
ラッパートークン：既存のトークンを預け入れ、別の性質を持つトークンとして発行し直したもの。プライバシー保護や他チェーンでの利用を目的に使われる。発行体とは無関係の第三者が独自に提供できるため、原資産の発行体は品質や安全性を統制できない。今回のzJPYCはこの類型にあたる。
- 英：wrapper token ／ 用例：The wrapper token was issued by a third party without the original issuer's review. （当該ラッパートークンは、原資産の発行体の審査を経ずに第三者が発行していた）
-
検証コントラクト（Verifier）：提出された暗号学的証明が正しいかどうかを自動で判定し、正しければ処理を通すスマートコントラクト。証明システム側に欠陥があると、無効な証明を正しいものとして受理してしまう。今回はここが不正ミントの入り口になった。
- 英：verifier contract ／ 用例：The verifier contract accepted an invalid proof and allowed the mint to proceed. （検証コントラクトが無効な証明を受理し、発行処理が通ってしまった）
-
一括出金機能（BatchWithdraw）：複数の出金をまとめて処理する機能。処理効率を上げる一方で、証明の検証を一度で済ませる構造になりやすく、欠陥があったときの被害が大きくなる。zERC20は安全策として無効化する設計にしていたが、特定チェーンへの展開時に有効のまま残った。
- 英：batch withdrawal ／ 用例：The batch withdrawal path should have been disabled at deployment but was left open. （一括出金の経路はデプロイ時に無効化されているべきだったが、開いたまま残されていた）
-
デプロイ後監査（post-deployment audit）：本番環境に配置されたコントラクトの権限設定、許可リスト、各機能の有効・無効が設計どおりかを、稼働後に確認する工程。コードそのものを対象とする従来の監査では、設定ミスを捉えられない。zERC20は再発防止策としてこの導入を表明した。
- 英：post-deployment audit ／ 用例：A post-deployment audit checks whether live settings match the intended design. （デプロイ後監査は、稼働中の設定が意図した設計と一致しているかを確認する）
出典
- zERC20 インシデントレポート（公式X、2026年9月17日）: https://x.com/zERC20io/status/2100635758012842070
- あたらしい経済「zERC20、zJPYCで約996万トークンが不正ミント。約335万円相当が流出」（2026年9月18日）: https://www.neweconomy.jp/posts/609156
本記事は公開情報に基づく解説であり、投資助言を目的としたものではありません。