x402 SDKの重大な脆弱性により、悪意あるAPIがAIエージェントのウォレットを空にできる

自動マイクロペイメントのためにx402標準を使用していたAIエージェントは、悪意あるAPIによってトークン残高をすべて流出させるという深刻なリスクに直面していました。セキュリティ企業V12は10月22日、x402ソフトウェア開発キット（SDK）のデフォルトクライアントに出費制限がなく、敵対的なサーバーがフルウォレット資金のリクエストと受領を可能にしていたことを明らかにしました。

これらのオープンソースツールを維持管理しているx402財団は8月18日にこれらの重大な欠陥に対する修正版をリリースしましたが、公開アドバイザリーではセキュリティパッチとしてフラグ付けされていませんでした。そのため、エージェント型ワークフローで大きな金銭的損失が発生する可能性があったにもかかわらず、多くの開発者は危険性を認識していませんでした。

何が起きたか

V12はx402コードベースで25件の欠陥を発見し、そのうち3件は重大と評価されました。最も危険な脆弱性は、TypeScript、Python、Goの各SDKにおけるデフォルトクライアントロジックに存在していました。APIサーバーがHTTPステータスコード「402 Payment Required」で応答した場合、任意の金額を含む支払いオプションをリストアップできました。デフォルトクライアントは最初のオプションを自動的に選択し、それが合理的な上限を超えているかどうかを確認せずに、その金額の支払いに署名していました。

攻撃者は、まず小さく正当なリクエストを行ってエージェントのウォレットアドレスを特定することでこの脆弱性を悪用できました。その後、ブロックチェーン上でウォレットの残高を調べ、その正確な金額を要求する後続の402レスポンスを作成できました。エージェントのアプリケーションが具体的な支払いポリシーを設定していなかった場合、SDKはトランザクションに署名し、攻撃者がそれを送信して資金を流出させることが可能でした。このリスクは、人間の介入なしに支払いを自動的に署名するように設定されたエージェントに限定されていました。

他の2つの重大な欠陥は、エコシステムの特定の部分に影響を与えました。Solana向けTypeScriptファシリテーターの1つの脆弱性により、「完全な支払い回避」が可能になりました。ブロックチェーンに到達する前に支払いを検証するファシリテーターは、トークン転送とトークン承認を区別できませんでした。攻撃者は資金を移動せず支出許可のみを与えるトークン承認指示を送信でき、ファシリテーターはこれを有効な支払いとして受け入れていました。マーチャントはリソースを提供しますが、トークンは交換されず、ファシリテーターが取引手数料を支払うことになります。

3つ目の欠陥はSign-In-With-X（SIWx）拡張機能に関係していました。クライアントは、メッセージに記載されているウェブサイト名が現在接続中のサイトと一致することを確認せずに、Ethereumベースのサイトのログインメッセージに署名していました。悪意あるサーバーは、別の信頼できるサイトからのログインメッセージを中継し、エージェントにそれを署名させることができました。攻撃者はその後、この署名を使用してエージェントとして信頼できるサイトにログインし、不正アクセスを得ることができました。

仕組み

x402標準は、HTTPリクエストに支払い指示を直接埋め込むことで、マシン間決済を可能にします。サーバーが支払いを要求する場合、金額、トークンタイプ、受取人を指定した支払いオプションのリストとともに402ステータスコードを返します。クライアントはオプションを選択し、暗号化された支払い証明に署名してからリクエストを再試行します。このプロセスは、API呼び出しに対して自律的に支払う必要があるAIエージェントにとってシームレスになるよう設計されています。

脆弱性は、デフォルトクライアントの実装が安全性よりも利便性を優先したために生じました。これはサーバーから提示された最初の支払いオプションを自動的に選択し、8月18日の更新以前は最大支出制限を課していませんでした。この信頼モデルは、APIプロバイダーが常に公正な金額を要求すると仮定していましたが、悪意ある行為者を扱う場合にはこの前提は成り立ちません。修正版では、取引あたり1ドルのデフォルト上限を導入し、USDCなどの認識されたステーブルコインへの支払いを制限しています（開発者が明示的に異なるルールを設定しない限り）。

Solanaファシリテーターの問題については、厳格な指示検証の欠如が原因でした。Solanaブロックチェーン上では、トークン転送とトークン承認は類似したデータ構造であり、最初の指示バイトのみが異なります。TypeScriptファシリテーターはトランザクションが有効なトークンプログラムを呼び出しているかどうかを確認していましたが、具体的な指示タイプは検証していませんでした。指示タイプのチェックを追加することで、更新されたSDKは実際の転送のみを支払いとして受け入れ、攻撃者が空の承認を使用してシステムを騙すのを防ぎます。

主要な詳細

• V12はx402コードで25件の欠陥を発見し、そのうち3件は重大と評価され、レポートで詳細が記述されています。
• TypeScript、Python、Go向けのデフォルトx402クライアントには、8月18日のリリース前まで出費制限がありませんでした。
• Solana固有のTypeScriptファシリテーターの欠陥により、トークン承認が有効な支払いとして受け入れられ、実際の資金移動を回避できました。
• SIWx拡張機能により、エージェントは現在訪問していないウェブサイトのログインメッセージに署名でき、アカウント乗っ取りが可能になっていました。
• 修正版は8月18日にリリースされましたが、公開セキュリティアドバイザリーは発行されず、npmやPyPIなどのパッケージレジストリでは古いバージョンが脆弱なものとしてフラグ付けされていませんでした。
• 10月23日時点での最新の安全なバージョンは、TypeScript/Goパッケージが2.28.0、Pythonが2.25.0です。

なぜ重要なのか

有料APIと連携するAIエージェントを開発しているエンジニアにとって、この事件は厳格な保護策なしに金融取引を自動化することのリスクを浮き彫りにします。エージェント型ワークフローはしばしば高い自律性で動作するため、単一の未検証のAPI呼び出しが即時の金銭的損失につながる可能性があります。明示的なセキュリティアドバイザリーの欠如は、npm auditなどの標準的な脆弱性スキャナーに依存しているチームがリスクを認識できないままでいることを意味し、パッチが利用可能になった後も本番システムがさらされる状態が続きます。

また、分散型決済システムにおいて外部入力を検証することの重要性も強調されます。お金がプログラム経由で移動する場合、コードはすべての支払いリクエストを潜在的に敵対的なものとして扱わなければなりません。x402の欠陥は、ブロックチェーン指示の微妙な違いやログインフローにおけるドメインチェックの欠落が、完全なシステム侵害につながる可能性があることを示しています。チームは現在、エージェントの設定を監査し、古いSDKを使用していないこと、および必須の出費制御が無効になっていないことを確認する必要があります。

対応策

• すべてのx402パッケージを最新バージョンにアップグレードしてください：TypeScriptとGoは2.28.0、Pythonは2.25.0です。
• アプリケーションでspendControls: falseが設定されていないことを確認してください。これが設定されると、新しいデフォルトの1ドル上限とステーブルコイン制限が無効になります。
• すぐにアップグレードできない場合は、registerPolicy（TypeScript/Go）またはregister_policy（Python）を使用して支払いポリシーを登録し、取引あたりの最大金額を強制してください。
• Solanaファシリテーターの場合、トークン承認による支払い回避を防ぐため、@x402/svmバージョン2.23.0以降を使用していることを確認してください。
• SIWxログイン署名に対するドメインマッチングを強制するため、@x402/extensionsをバージョン2.23.0以降に更新してください。
• エージェントのウォレット権限を監査し、自動APIインタラクション用に限られた残高を持つ専用ウォレットの使用を検討してください。