cat posts/%e4%bb%8a%e9%80%b1%e3%81%ae%e3%82%bb%e3%82%ad%e3%83%a5%e3%83%aa%e3%83%86%e3%82%a3%e8%80%83%e5%af%9f%ef%bc%9a%e6%9c%ac%e4%ba%ba%e7%a2%ba%e8%aa%8d%e3%82%82%e3%81%9b%e3%81%9a%e3%81%ab%e5%85%a5%e9%a4%a8.md

今週のセキュリティ考察:検証を飛ばすとトークンが出る——F5 BIG-IP APM OAuth バイパス(CVE-2026-94127)

社内アプリへのアクセスを制御する F5 BIG-IP APM(Access Policy Manager)を OAuth の認可サーバーとして使っている構成に、ログインせずにプログラムを実行できる脆弱性 CVE-2026-94127(CVSS v3.1 で 9.8、v4.0 で 9.3)があり、悪用が確認されている[1][2][5][6]。

PART 1解説

3行でわかる要点

  • 原因:ヒープバッファオーバーフロー(メモリがあふれる欠陥)。細工した通信を仮想サーバーに送ると、遠隔からコードを実行できる[5]。
  • 対象:APM のアクセスポリシーと OAuth 認可サーバーのプロファイルを、同じ仮想サーバーに設定している構成だけ。OAuth のクライアントやリソースサーバーとしてだけ使う構成は対象外[1][6]。
  • 管理画面を閉じても防げない:攻撃は管理画面ではなく、利用者向けの仮想サーバーに届く。Appliance モードの BIG-IP も影響を受ける[5]。

前提:BIG-IP APM と OAuth の関係

BIG-IP は通信の振り分けやセキュリティを担う F5 の装置で、APM はその中の「誰がどのアプリにアクセスしてよいか」を制御する機能です。SSO(一度のログインで複数のシステムを使えるようにする仕組み)の基盤として使われることが多くあります。

OAuth は、アプリが利用者の代わりに別のサービスへアクセスするための許可の仕組みで、許可証(アクセストークン)を発行する側を認可サーバーといいます。APM はこの認可サーバーの役割も担えます。今回の脆弱性は、この役割を担わせている場合にだけ問題になります[1]。

まず押さえる用語

用語ひとことでもっと詳しく
CVE脆弱性ごとに付けられる世界共通の番号。IPA「共通脆弱性識別子CVE概説」
CVSS脆弱性の深刻度を 0.0〜10.0 で表す指標。版(v3.1 / v4.0)で計算方法が少し違うため、同じ脆弱性でも値が異なることがある。IPA「共通脆弱性評価システムCVSS概説」
OAuth の認可サーバーアプリに「利用者の代わりにアクセスしてよい」という許可証(アクセストークン)を発行する役割のサーバー。RFC 6749(IETF)
仮想サーバー(BIG-IP)BIG-IP が利用者からの通信を受け付ける窓口(IP アドレスとポートの組)。F5「APM を OAuth 2.0 サーバーとして使う」
ヒープバッファオーバーフロープログラムが実行中に確保するメモリ(ヒープ)で、用意した領域より大きなデータを書き込んでしまう欠陥。CWE-122(MITRE)

本来の仕組みと、どこが破られたか

BIG-IP APM の仮想サーバーに届く通信の正常時と攻撃時正常時利用者のアクセス仮想サーバーOAuth 認可サーバー処理トークンを発行攻撃時細工した通信(認証不要)仮想サーバーヒープがあふれる任意のコードを実行
図1 攻撃は管理画面ではなく、利用者向けの仮想サーバーに届く(F5・The Hacker News の記述をもとにした概念図)

正常時は、利用者の通信が仮想サーバーに届き、OAuth 認可サーバーの処理を経てアクセストークンが発行されます。攻撃時も、届く先は同じ仮想サーバーです。OAuth の処理の途中でヒープがあふれ、攻撃者のコードが動きます[5]。

つまり「管理画面へのアクセスを社内に限る」という対策は、この経路には効きません[5]。守るべき入口は、利用者に公開している窓口そのものです。

攻撃の流れ

sequenceDiagram
    autonumber
    actor A as 攻撃者
    participant V as BIG-IP 仮想サーバー
    participant O as OAuth認可サーバー処理
    A->>V: 細工した通信(認証不要)
    V->>O: OAuthの処理に渡す
    O->>O: ヒープがあふれる
    O->>V: 攻撃者のコードを実行
    A->>V: 不審なコマンドを実行
  • 1〜4:OAuth 認可サーバーのプロファイルがある仮想サーバーに細工した通信が届くと、リモートコード実行に至る[1][5]。
  • CISA は9月22日に、悪用が確認された脆弱性の一覧(KEV)に追加し、米連邦機関に9月25日までの対処を求めた[3][5]。
  • 侵害の兆候(F5 が CERT-EU 経由で公開):/var/log/apm に「The access token is invalid.」で失敗した UserInfo 要求が短時間に繰り返し記録される、/var/log/audit に不審なコマンドがある、直後に TMM が SIGABRT で落ちる、の組み合わせ[4][5]。

「うちは対象外」と判断する前に(考察)

  • F5 は公表翌日(9月23日)に CVE レコードを更新し、対象を「認可サーバーの役割」に絞った。それより前に出た CISA や CERT-EU の情報は、もっと広い条件で書かれている[5]。初報だけを見て対象外と決めない。
  • サポートが終了したバージョンは評価されておらず、「安全」ではなく「不明」扱い[5]。
  • 3月に悪用された別の APM の脆弱性(CVE-2025-53521)の修正版も、今回の対象範囲に入る[5]。前回のパッチを当てたから安心、とはいえない。
  • 管理画面を閉じるという一般的な対策が効かない種類の脆弱性もある。どの入口に届く攻撃なのかを確かめてから対策を選ぶ。

いま確認すること

  • 【BIG-IP を使っている】APM の OAuth 認可サーバープロファイルが、アクセスポリシーと同じ仮想サーバーに設定されていないか確かめる(Access › Federation › OAuth Authorization Server)[5]。
  • 【BIG-IP を使っている】該当する場合は F5 のホットフィックスを適用する。すぐに当てられない場合は、F5 サポートから iRule による緩和策を入手する[1][5]。
  • 【BIG-IP を使っている】CERT-EU の推奨どおり、証拠の保全 → ホットフィックス適用 → 侵害の兆候の確認、の順で進める[4]。
  • 【全員】アクセストークンを発行する役割のサーバー(OAuth 認可サーバー、API ゲートウェイなど)を棚卸しし、どの窓口がインターネットに公開されているかを把握する。

出典・参考リンク

一次情報

  1. F5 K000162605
  2. NVD — CVE-2026-94127
  3. CISA Known Exploited Vulnerabilities Catalog
  4. CERT-EU Security Advisory 2026-013

報道・解説

  1. The Hacker News — F5 Patches Critical BIG-IP APM Zero-Day
  2. BleepingComputer — F5 warns of BIG-IP APM remote code execution zero-day

PART 2問題(情報処理安全確保支援士 試験形式)

問1 午前II形式(4択)

F5 BIG-IP APM の CVE-2026-94127 の影響を受ける構成として、最も適切なものはどれか。

  • ア APM を OAuth のクライアントとしてだけ使っている構成
  • イ APM のアクセスポリシーと OAuth 認可サーバーのプロファイルを同じ仮想サーバーに設定している構成
  • ウ 管理インターフェースをインターネットに公開している構成
  • エ APM モジュールを導入していない BIG-IP
解答・解説を表示

解答:イ

F5 によると、脆弱性があるのは APM が OAuth 認可サーバーとして動く構成だけ。アは OAuth クライアント/リソースサーバーとしての利用で、対象外と明記されている。ウは、管理画面の公開は条件ではない(管理画面を閉じても防げない)。エは APM がないので対象外。

↑ Part 1「3行でわかる要点」を読み直す

問2 午後形式(記述)

A社は社内アプリの SSO(シングルサインオン)基盤として F5 BIG-IP APM を使い、OAuth 認可サーバーの機能も有効にしている。CVE-2026-94127 の公表を受けて、運用担当者は「管理インターフェースは社内からしかアクセスできないので、影響は小さい」と判断した。セキュリティ担当の B さんは、①その判断は誤りだと指摘した。

設問 本文中の下線①について、B さんがそう指摘した理由を50字以内で述べよ。

解答・解説を表示

解答例:攻撃は管理画面ではなく利用者向けの仮想サーバーに届くため、管理画面の制限では防げないから(44字)

細工した通信は、OAuth 認可サーバーのプロファイルを設定した仮想サーバー、つまり利用者に公開している窓口に届く。管理画面へのアクセス制限は、この経路に効かない。「OAuth を使っていないから」は、事例の条件(認可サーバー機能が有効)と矛盾する。

↑ Part 1「本来の仕組みと、どこが破られたか」を読み直す