GitHub、Angularのトークン漏えい欠陥を掲載、利用版と送信処理を確認

GitHubは、Angularの通信機能HttpClientで、XSRFトークンが攻撃者側へ漏れる脆弱性「CVE-2026-111753」を勧告に掲載しています。長期サポート対象の20.3.x系では20.3.34で修正されており、利用企業は版と送信処理の確認が必要です。勧告の公開日は資料に記載されていません。

外部の送信先を内部と誤認し、保護用トークンを付ける

対象は、Angularのパッケージ「@angular/common」に含まれるHttpClientです。XSRF保護は、利用者の意図しない操作を送信させる攻撃を防ぐ仕組みで、HttpClientでは既定で有効です。今回は、その保護に使うトークンが外部へ送られる可能性があります。

原因は、URLを判定する正規表現と、ブラウザーが使うWHATWGのURL解析ルールの違いです。HttpClientが細工したURLをアプリと同じオリジンの相対URLと誤認し、XSRFヘッダーを付けます。一方、ブラウザーは外部の送信先と解釈するため、トークン付きのリクエストが外部へ送られます。オリジンとは、通信方式、ホスト名、ポート番号で区別する接続先の単位です。

勧告によると、攻撃者は取得したトークンで組み込みのXSRF保護を回避し、被害者のセッションを使ったCSRF攻撃を行い得ます。CSRFは、ログイン中の利用者に意図しない操作を送信させる攻撃です。

ただし、Angularを使っているだけで攻撃が成立するわけではありません。XSRF保護が有効で、攻撃者が管理するURLへ、アプリに状態変更リクエストを送らせる必要があります。さらに、攻撃者側サーバーが、異なるオリジン間の通信を制御するCORSで、そのリクエストと独自ヘッダーを許可することも条件です。

以前の修正が不完全、20.3.x系は20.3.34で対応

今回の欠陥は、「CVE-2025-66035」への修正が不完全だったことに起因します。以前の脆弱性への対応を終えていても、それだけで今回の確認を省くことはできません。

修正版は標準URLコンストラクターでURLを解析し、アプリと送信先のオリジンを比較します。Angular 21.0.3以降と22.xは、既に別のURL判定を採用しているため影響を受けません。

更新できない場合、勧告は動的に指定されるURLを標準URLで解析し、同一オリジンか確認するよう推奨しています。また、状態変更リクエストには、信頼できないURLや利用者が制御するURLを渡さないよう求めています。

日本での提供は発表には書かれていません。国内での対応判断も、利用している版と、勧告に示された実装条件を照合して進める必要があります。

影響する会社・しない会社

• 影響する: @angular/commonのHttpClientを使い、20.3.x系を運用している会社は、修正版20.3.34への対応状況を確認する必要があります。特に、外部から渡されたURLへ状態変更リクエストを送る処理は確認対象です。
• 影響する: 開発を委託している会社も、委託先に利用版とURLの扱いを確認する必要があります。XSRF保護は既定で有効なため、明示的に設定した覚えがないことは対象外の根拠になりません。
• 影響しない: Angular 21.0.3以降、または22.xを利用する会社は、今回の脆弱性の影響を受けません。
• 影響しない: XSRF保護が無効なアプリは、勧告に記載された攻撃成立条件を満たしません。ただし、これは保護を無効にする対応を勧めるものではありません。

情シスが今日やること

1. 本日の一次確認として、開発担当や委託先に、対象システムの依存パッケージ一覧で@angular/commonの有無と版を調べてもらいます。システム名、利用版、担当者をまとめ、未確認のものを残さないようにします。
2. 20.3.x系の担当者には、20.3.34への更新状況と適用予定日の回答を依頼します。以前のCVEへの対応済みという回答だけで終了せず、今回の修正版を確認します。
3. 更新作業と並行して、HttpClientのXSRF設定と、状態変更リクエストの送信処理をコード上で確認してもらいます。利用者が指定したURLや信頼できないURLを、送信先として渡せる箇所があるかを具体的に聞きます。
4. すぐ更新できないシステムは、標準URLによる解析と同一オリジン確認を開発担当に相談します。今日の確認結果をシステム責任者に共有し、暫定対応の担当者と期限、修正版へ移行する予定を決めます。