F5 BIG-IP APM の CVE-2026-94127 - OAuth認可サーバー構成を狙う未認証RCEのゼロデイと対応手順

はじめに

F5は2026年9月22日(米国時間)、アプリケーション配信コントローラ製品BIG-IPのアクセス制御モジュールBIG-IP APM(Access Policy Manager)に、未認証の攻撃者がリモートからコードを実行できる脆弱性CVE-2026-94127があるとして、アドバイザリK000162605を公開しました。種類はヒープベースのバッファオーバーフロー(CWE-122)で、CVSS v3.1のベーススコアは9.8、CVSS v4.0では9.3です。

注目すべき点は、公表の時点ですでに実際の攻撃に使われていたことです。いわゆるゼロデイとして修正と同時に明らかになり、米CISAは同日にKnown Exploited Vulnerabilities(KEV)カタログへ追加しました。連邦民間機関への対応期限は2026年9月25日、つまり追加からわずか3日です。さらにKEVのエントリには、修正だけでなく侵害有無の調査(フォレンジックトリアージ)も求めるフラグが立っています。

一方で、影響を受けるのは「APMをOAuthの認可サーバーとして構成している」場合に限られます。BIG-IPを使っているすべての組織が直ちに危険というわけではなく、まず自社の構成が該当するかどうかを切り分けることが対応の出発点になります。

本記事では、NVD、CISA KEVのJSONフィード、CERT-EUのアドバイザリ、F5の技術文書を一次情報として、脆弱性の中身と影響範囲、実務での確認と対応の手順を整理します。F5のアドバイザリ本体(K000162605)はログイン不要で閲覧できますが、JavaScriptで描画されるページのため本記事の調査では本文を機械的に取得できませんでした。アドバイザリにしか載っていない細部(ホットフィックスの正式名称など)は、報道とCERT-EUの記述を引用したうえで「K000162605で要確認」と明記しています。

概要(早見表)

影響を受ける構成とバージョン

条件は「OAuth認可サーバーとして動かしていること」

NVDに登録されたF5の説明では、影響を受ける条件を次のように限定しています。

• BIG-IP APMのアクセスポリシーとOAuthプロファイルが、同じ仮想サーバーに設定されていること
• APMがOAuth Authorization Server(認可サーバー)として構成されていること
• APMをOAuth Client / Resource Serverとしてのみ使っている(認可サーバー用のプロファイルが無い)構成は影響を受けない

BIG-IP APMのOAuth機能には大きく2つの立場があります。1つは、外部のIdP(Azure AD/Entra IDやOktaなど)が発行したトークンを受け取って検証するクライアント/リソースサーバーとしての使い方です。もう1つは、APM自身がクライアントアプリケーションを登録し、アクセストークンやリフレッシュトークンを発行する認可サーバーとしての使い方です。今回問題になっているのは後者です。

F5の技術文書「Using APM as an OAuth 2.0 Authorization Server」(BIG-IP 17.1.0向け)によると、認可サーバーとしてのAPMは、Authorization Code/Hybrid、Implicit、Resource Owner Password Credentialsの各グラントに対応し、トークンとしてはデータベースに保存する不透明トークン(opaque token)とJWTの両方を扱えます。設定はGUIのAccess > Federation > OAuth Authorization Server配下(Client Application、Resource Server、Scope、OAuth Profile)で行い、作ったOAuthプロファイルをアクセスプロファイルに関連付け、そのアクセスプロファイルを仮想サーバーに割り当てる、という構造です。

OAuthの認可サーバーとクライアント、リソースサーバーの役割分担そのものについては、OAuth 2.0 / OpenID Connect 入門で詳しく解説しています。

影響バージョンと修正

NVDのCPE構成とCERT-EUのアドバイザリは、影響バージョンを次の3系統としています。修正はF5が各ブランチ向けに出したエンジニアリングホットフィックスです。ホットフィックスの名称はF5のアドバイザリ本文を直接確認できなかったため、The Hacker Newsの報道に掲載された表記を載せています。適用前にK000162605で正式な名称と対象を必ず確認してください。

補足として、次の点も押さえておく必要があります。

• Appliance modeのBIG-IPも影響を受けます(NVDのF5説明)。Appliance modeはBashへのアクセスを制限する運用モードですが、今回の脆弱性はデータプレーンの問題なので防御になりません。
• サポート終了(EoTS)に達したバージョンは評価対象外です(同)。16.1系や15.1系などの古いブランチが一覧に無いのは「安全と確認された」からではなく「調べていない」からです。該当ブランチでOAuth認可サーバーを動かしている場合は、影響を受ける前提でサポート対象バージョンへの移行を検討すべきです。
• SecurityWeekの報道によると、F5はBIG-IP APM以外の自社製品は影響を受けないとしています。
• 通常の保守リリース(ホットフィックスではない正式なポイントリリース)で修正が取り込まれる時期は、本記事の調査時点では未確認です。

脆弱性の技術的な位置づけ

F5もCISAも、脆弱なコードの具体的な箇所や、どのエンドポイントへのどんなリクエストで発火するかは公表していません。公表されているのは「OAuthプロファイルを持つ仮想サーバーに特定の悪意あるトラフィックを送ると、ヒープベースのバッファオーバーフローが起きてリモートコード実行につながる」という点までです。

ヒープベースのバッファオーバーフローは、mallocなどで動的に確保した領域に、確保したサイズを超えるデータを書き込んでしまう不具合です。隣接するヒープ上の管理情報や別オブジェクトの関数ポインタを壊せると、攻撃者は処理の流れを乗っ取れる可能性があります。ヒープの内部構造がどうなっているかはメモリアロケータ入門で扱っています。

BIG-IPでデータプレーンのトラフィックを処理するのはTMM(Traffic Management Microkernel)と呼ばれるプロセスです。F5がIOCとして「TMMのSIGABRT」を挙げていることから、攻撃の過程でTMMが異常終了するケースがあると読み取れます。TMMが落ちるとその間はトラフィック処理が止まるため、攻撃の痕跡が可用性の低下として表に出ることもありえます(これは公表情報からの推測で、F5は明言していません)。

OAuthの認可サーバーは、その性質上「まだ認証されていないクライアントからのリクエスト」を受け付ける必要があります。トークンエンドポイントやUserInfoエンドポイントは、正当なトークンを持っているかどうかを判定する側であり、判定前の入力を解析しなければなりません。認証の手前で動くパーサに境界チェックの漏れがあれば、そのまま未認証RCEになる、という構図は今回に限らず繰り返し見られるパターンです。

悪用状況とCISAの対応

ゼロデイとしての公表

CERT-EUのアドバイザリによると、F5は実環境での悪用を確認しています(vendor confirmed active exploitation in the wild)。CISAのKEVはCVE-2026-94127を2026年9月22日に追加し、NVDに付与されたCISAのSSVC評価は次のとおりです。

攻撃者の属性、被害組織の数、初回の悪用時期といった情報は、本記事の調査時点ではF5からもCISAからも公表されていません。ランサムウェアでの利用状況も、KEV上は「Unknown」です。

BOD 26-04の「3日+フォレンジックトリアージ」

今回のKEVエントリで目を引くのは、対応期限が追加日の3日後(9月25日)に設定され、JSONフィードのforensicTriageフィールドがYesになっていることです。これは2026年6月10日に発出されたBOD 26-04「Prioritizing Security Updates Based on Risk」に基づく区分です。

BOD 26-04は、KEVに載っているかどうかだけで一律に期限を決めていた従来のBOD 22-01(およびBOD 19-02)を置き換え、資産の露出、KEV掲載の有無、攻撃の自動化可能性、技術的影響の4つの変数で期限を決める方式に改めました。そのうち最も厳しい区分が、次の条件の組み合わせです。

• 資産がインターネットに公開されている
• 攻撃が自動化可能である
• 技術的影響が「完全な制御」である

この区分では3日以内の修正に加えて、資産が侵害されていないかを評価するフォレンジックトリアージが求められます。CVE-2026-94127のSSVC評価(automatable: yes、technical impact: total)は、まさにこの区分に当てはまります。

KEVエントリの注記には、さらに具体的な順序が書かれています。

For temporary mitigation to allow for proactive forensic triage, apply the vendor-provided iRule. Once completed, install the final vendor patch as soon as possible.

つまり「まずベンダー提供のiRuleで暫定的に塞ぎ、その状態でフォレンジックトリアージを行い、終わったら最終的なパッチを入れる」という流れです。いきなりホットフィックスを入れて再起動すると、メモリ上やログの痕跡が失われる可能性があるため、調査の機会を確保する意図だと読めます。BOD 26-04の対象は米国の連邦民間機関ですが、この順序は民間組織にとっても参考になります。

KEVに載ったF5製品の脆弱性

2026年9月23日版のKEV JSONフィード(カタログバージョン 2026.09.23)でvendorProjectがF5のエントリを数えると、今回を含めて8件あります。

過去の多くは管理画面(TMUIやiControl REST、Configuration Utility)が入口で、「管理インターフェースをインターネットに出さない」ことが最大の防御策でした。今回はデータプレーン側、しかも本来インターネットに公開して使うOAuthエンドポイントが入口です。管理面の露出を絞っていても防げない点で性質が異なります。

対策と確認手順

CERT-EUのアドバイザリは、推奨対応を「証拠の保全」「ホットフィックスの適用」「侵害の兆候の確認」の順に挙げています。CISAの注記と合わせると、次の流れが妥当です。

1. 自社のBIG-IPが該当構成かを確認する

最初に、バージョンとOAuth認可サーバー用プロファイルの有無を確認します。tmshのapm profile oauthは、F5のtmshリファレンスで「OAuth Authorization Serverを構成するための設定群」と説明されているプロファイルです。

# バージョンの確認
tmsh show sys version
 
# OAuth認可サーバー用プロファイルの一覧
# 既定の親プロファイル "oauth" は常に存在するため、それ以外に自作のプロファイルがあるかを見る
tmsh list apm profile oauth
 
# 仮想サーバーに割り当てられたプロファイルの確認(<VS名> は対象の仮想サーバー名)
tmsh list ltm virtual <VS名> profiles

GUIではAccess > Federation > OAuth Authorization Server > OAuth Profileで一覧を確認できます。自作のOAuthプロファイルがあり、それを関連付けたアクセスプロファイルが仮想サーバーに割り当てられていれば該当します。Access > Federation > OAuth Client / Resource Server側の設定だけであれば、F5の説明上は影響を受けません。

なお、上記のtmshコマンドの出力形式はバージョンによって異なる場合があります。判断に迷う場合はF5サポートへの確認を推奨します。

2. 証拠を保全する

該当構成であれば、ホットフィックス適用の前に証拠を確保します。CERT-EUが確認対象として挙げているのは次の4点です。

• /var/log/apmに記録された、繰り返しのOAuth認証失敗
• OAuth関連の統計で、失敗件数が不自然に増えていないか
• /var/log/auditの不審なエントリ
• システムのクラッシュを示すTMMのコアファイル

BIG-IPではqkviewで診断情報をまとめて取得できます。ログのローテーションで痕跡が消える前に、該当ログとqkview、コアファイルを機器の外へ退避しておくのが安全です。

3. 暫定緩和(iRule)を入れ、ホットフィックスを適用する

直ちにホットフィックスを適用できない場合、F5はF5サポートから入手できるiRuleを影響を受ける仮想サーバーに適用する暫定緩和を案内しています(CERT-EU、CISA KEV注記)。iRuleの中身は公開情報として確認できていないため、本記事には載せていません。サポート契約経由で入手してください。

そのうえで、前述のブランチ別エンジニアリングホットフィックスを適用します。ホットフィックスの適用には再起動やトラフィック断を伴う可能性があるため、HA構成であればスタンバイ側から順に適用してフェイルオーバーさせるなど、平常時と同じ変更管理の手順を踏みます。

OAuth認可サーバーの機能を実際には使っていない(検証用に作ったまま放置している等)ことが分かった場合は、仮想サーバーからの割り当てを外すことも攻撃面を減らす手段になります。

4. 侵害の痕跡を確認する

F5がアドバイザリで挙げたIOCは3つで、SecurityWeekによればF5は「単独ではなく、組み合わせて頻繁に現れる場合に攻撃と結び付けるべき」という趣旨で説明しています。報道とCERT-EUの記述を合わせると、次のパターンが目安になります。

1. OAuth認証の失敗が複数回続く
2. その直後に不審なコマンドの実行が記録される(/var/log/auditなど)
3. 間を置かずにTMMがSIGABRTで異常終了する

The Hacker Newsは、F5とCERT-EUの情報として、/var/log/apmに「The access token is invalid」というエラーを伴うUserInfoリクエストの失敗が繰り返し記録されること、同一IPアドレスから短時間に10回以上のリクエストがあること、も目安として挙げています。この具体的な閾値はF5のアドバイザリ本文で確認できていないため、参考値として扱ってください。

# APMログでOAuth関連の失敗を探す(ローテーション済みの圧縮ログも対象にする)
zgrep -i "access token is invalid" /var/log/apm*
 
# 監査ログで想定外のコマンド実行を探す(検索語は環境に合わせて調整する)
zgrep -i "cmd" /var/log/audit* | less
 
# TMMのコアファイルの有無(一般に /var/core 配下に出力される)
ls -l /var/core/

5. 侵害が疑われる場合

上記の痕跡が見つかった場合、ホットフィックスを入れただけでは攻撃者が残した足場(追加されたアカウント、改変された設定、持ち出された鍵)は取り除けません。少なくとも次の点を検討してください。

• BIG-IPのローカルアカウント、iControl RESTのトークン、SSH鍵の棚卸しと更新
• OAuth認可サーバーが保持する署名鍵(JWTの鍵設定)とクライアントシークレットの更新
• 発行済みのアクセストークン/リフレッシュトークンの失効
• BIG-IPを経由してアクセスしていた背後のアプリケーション側のログ確認
• 必要に応じてクリーンな状態からの再構築とF5サポートへの相談

認可サーバーが侵害された場合、そこで発行・検証されていたトークンの信頼性そのものが失われる点が、通常のWebサーバー侵害よりも影響を広げます。

この件から読み取れること

1つ目は、管理面を閉じるだけでは足りない種類の脆弱性が増えていることです。過去のF5のKEV入り脆弱性の多くは管理画面が入口でしたが、今回はサービスとして公開しているOAuthエンドポイントそのものが入口でした。ロードバランサやADCは、ロードバランシングのアルゴリズム入門で扱ったような振り分けだけでなく、認証やトークン発行まで担うことが増えており、その分だけデータプレーン側の攻撃面が広がっています。

2つ目は、「該当構成か」を即答できる台帳の重要性です。今回の影響範囲は「APMをOAuth認可サーバーとして使っているか」で明確に切り分けられます。どの機器でどの機能を有効にしているかを把握していれば、影響の有無を数分で判定できますが、把握していなければ全台の設定を洗い出すところから始めることになります。

3つ目は、パッチの前に調査の機会を確保するという順序です。BOD 26-04の「3日+フォレンジックトリアージ」とKEV注記の「iRuleで塞いでから調べ、その後パッチ」という流れは、ゼロデイとして公表された脆弱性では「公表前から攻撃されていた」前提で動くべきだ、という考え方を反映しています。境界機器のゼロデイという点では、Citrix NetScalerの未認証RCE CVE-2026-8452も同じ教訓を示していました。

まとめ

• CVE-2026-94127は、BIG-IP APMをOAuth認可サーバーとして構成した仮想サーバーに対する、未認証のリモートコード実行につながるヒープベースのバッファオーバーフローです(CVSS v3.1 9.8)。
• 影響バージョンは17.1.0から17.1.3、17.5.0から17.5.1、21.1.0で、APMをOAuthクライアント/リソースサーバーとしてのみ使う構成は影響を受けません。EoTSのバージョンは評価されていません。
• 公表時点で悪用が確認されており、CISAは2026年9月22日にKEVへ追加、BOD 26-04の最短区分(3日以内の修正とフォレンジックトリアージ)を適用しました。
• 対応は「該当構成の確認」「証拠保全」「iRuleによる暫定緩和とホットフィックス適用」「IOCの確認」「侵害時の鍵・トークンの更新」の順で進めるのが妥当です。
• ホットフィックスの正式名称、iRuleの内容、IOCの詳細な閾値は、F5のアドバイザリK000162605で必ず確認してください。

参考資料

• K000162605(F5 セキュリティアドバイザリ)
• CVE-2026-94127 Detail(NVD)
• Known Exploited Vulnerabilities Catalog: CVE-2026-94127(CISA)
• BOD 26-04: Prioritizing Security Updates Based on Risk(CISA)
• BOD 26-04 Implementation Guidance(CISA)
• Security Advisory 2026-013: Critical Vulnerability in F5 BIG-IP APM(CERT-EU)
• F5 Patches Critical BIG-IP APM Zero-Day Exploited for Unauthenticated RCE on OAuth Servers(The Hacker News)
• Using APM as an OAuth 2.0 Authorization Server(F5 BIG-IP 17.1.0 Documentation)
• apm profile oauth(F5 tmsh Reference)
• OAuth 2.0 / OpenID Connect 入門 - 認可と認証の違い、Authorization Code Flow + PKCE まで
• メモリアロケータ入門 - malloc/free はヒープに何をしているのか
• Citrix NetScalerの未認証RCE CVE-2026-8452 - DoSと評価された脆弱性が2か月後にKEV入りするまで