F5 BIG-IP APMのCVE-2026-94127。OAuth認可サーバを載せた仮想サーバで起きる未認証RCEとKEV入り後の対応

BIG-IPの仮想サーバは、インターネットからの通信を最初に受け止める場所に置かれることが多い装置です。2026年9月22日にF5が公表したCVE-2026-94127は、BIG-IP Access Policy Manager(APM)をOAuth認可サーバとして動かしている仮想サーバに、認証を経ずにリモートからコードを実行される欠陥があるというものです。F5のアドバイザリには悪用を把握した旨が書かれており、同じ日にCISAがKnown Exploited Vulnerabilities(KEV)カタログへ追加しました。

この記事は、BIG-IPを運用するネットワーク担当とインフラ実務者に向けて、F5のアドバイザリK000162605、NVD、CISAのKEVカタログとBOD 26-04の文書、CERT-EUの勧告で確認できた内容だけを使い、自組織の構成が該当するかの確認から、修正の適用、侵害の痕跡の確認までを順に整理します。F5が公表していない技術的な詳細(攻撃に使うリクエストの形など)は書きません。

F5とCISAが公表した内容#

F5のアドバイザリK000162605「BIG-IP APM vulnerability CVE-2026-94127」は2026年9月22日に公開され、9月23日に更新されています。説明文は、BIG-IP APMのアクセスポリシーとOAuthプロファイルが仮想サーバに構成されているとき、特定の悪意ある通信によってリモートコード実行に至る、というものです。続けて、この脆弱性はBIG-IP APMがOAuth認可サーバ(OAuth Authorization Server)として構成されている場合にだけ存在し、OAuthクライアントやリソースサーバとしてだけ使う構成は影響を受けないと書かれています。

影響の説明は短く、未認証の攻撃者がリモートコード実行を行える、Appliance modeのBIG-IPも影響を受ける、データプレーンの問題でコントロールプレーンへの露出はない、の3点です。F5の社内追跡IDは2524777で、分類はCWE-122(Heap-based Buffer Overflow)です。謝辞の欄には、F5が社内で発見したと記載されています。

悪用については、アドバイザリの冒頭近くに「We have learned that this vulnerability has been exploited.」という一文があります。F5が悪用を把握した具体的な日付は、アドバイザリには書かれていません。CERT-EUは9月22日付の勧告2026-013で、ベンダーが実環境での悪用を確認したと伝えています。

F5のアドバイザリは、この脆弱性はBIG-IP APMがOAuth認可サーバとして構成されている場合にのみ存在し、OAuthクライアントまたはリソースサーバとしてのみAPMを使う構成(OAuth認可サーバのプロファイルを持たない構成)は影響を受けないと述べています。また、悪用を把握したこと、Appliance modeも影響を受けること、データプレーンの問題であることを明記しています。

CISAは同じ9月22日に、Check Point製品の2件とArista VeloCloud Orchestratorの1件とあわせて、このCVEをKEVカタログへ追加しました。KEVでの名称は「F5 BIG-IP APM Heap-based Buffer Overflow Vulnerability」、連邦民間行政機関(FCEB)の対応期限は2026年9月25日、ランサムウェアキャンペーンでの利用有無は「Unknown」です。項目にはフォレンジックトリアージの対象という印が付き、備考欄には、事前のフォレンジックトリアージを行えるよう一時的な緩和としてベンダー提供のiRuleを適用し、それが済んだら最終的なパッチをできるだけ早く入れる、という順序が書かれています。

CVSSの値は誰が付けたものか#

CVSS v3.1の9.8(CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)とv4.0の9.3は、CNAであるF5 SIRTが付与した値です。NVDのページにも同じ値が掲載されていますが、提供元はF5と表示されており、NIST独自の基本値は執筆時点で掲載されていません。ネットワーク越しに、特別な条件なしで、権限も利用者の操作も要らずに悪用でき、機密性、完全性、可用性のすべてに高い影響が出る、という評価です。

NVDにはこのほか、CISAが付与したSSVCの判定も載っています。悪用状況(Exploitation)は「active」、自動化可能性(Automatable)は「yes」、技術的影響(Technical Impact)は「total」です。この3つの判定は、後で扱うBOD 26-04の期限の決まり方に直結します。CVSSの各項目の読み方は、次の記事で整理しています。

影響する版と修正用のホットフィックス#

F5のアドバイザリの表では、BIG-IP APMだけが対象です。BIG-IPのほかのモジュール、BIG-IQ、BIG-IP Next、F5OS、NGINX製品、F5 Distributed Cloudは「Not vulnerable」とされています。

修正は通常のポイントリリースではなく、F5 Downloadsで配布されるエンジニアリングホットフィックス(EHF)です。アドバイザリの注記によれば、これらのEHFにはBIG-IP Hardened Releases 2(HR2)の修正すべてと、K000163302(17.5.1.9と17.1.3.5向けのEHFの概要)に載る修正が含まれます。EHFを入れた後に別のバージョンへ上げる計画がある場合は、移行先にこの修正が含まれるかをアドバイザリの表の更新で確かめてから進めます。

F5は技術サポート終了(EoTS)に達したバージョンを評価の対象にしていません。表に載っていない古い系列を使っている場合、それは影響がないという意味ではなく、評価されていないという意味です。サポート対象の系列への移行を前提に計画を立てます。アドバイザリは、F5 iHealthを使ってBIG-IPが該当するかを診断できることにも触れています(K27404821)。

自組織の構成が該当するかを確かめる手順#

影響の条件は「OAuth認可サーバとして構成されたAPM」です。F5のBIG-IP 17.1向けドキュメントでは、APMをOAuth 2.0の認可サーバとして使う場合、Access > Federation > OAuth Authorization Server > OAuth ProfileでOAuthプロファイルを作り、アクセスプロファイルの作成時にそのOAuthプロファイルを選び、Local Traffic > Virtual Serversで仮想サーバのAccess Profileにそのアクセスプロファイルを割り当てる、という手順になっています。確認はこの逆順にたどります。

tmshで同じ確認をする場合、OAuthプロファイルの一覧はapm profile oauth、仮想サーバに付いているプロファイルはltm virtualの一覧で見られます。

# OAuthプロファイル(認可サーバ用)の一覧
tmsh list apm profile oauth

# 仮想サーバと割り当て済みプロファイルの一覧
tmsh list ltm virtual profiles

構成の差分管理をしている組織では、構成ファイルのバックアップを検索する方が早い場合もあります。いずれの方法でも、HAペアの片系だけを見て終わらせず、構成同期(ConfigSync)の対象外になっている装置がないかも確かめます。APMとOAuthの役割の違いは、次の記事で基礎から整理しています。

データプレーンの問題が意味すること#

F5のK44525501は、BIG-IPのデータプレーンとコントロールプレーンの分担を説明しています。データプレーンは実行時のネットワーク通信の処理のほぼすべてを担い、仮想サーバ、SNATとNATといったトラフィック管理のオブジェクトや、BIG-IP APMとBIG-IP ASMといったモジュールの通信を、Traffic Management Microkernel(TMM)が処理します。TMMはBIG-IPのOS(TMOS)上でリアルタイムのユーザープロセスとして動きます。一方、コントロールプレーンは管理用の通信を扱い、設定ユーティリティ、tmsh、iControl REST、管理IPアドレスへのSSHなどがこちらに入ります。

CVE-2026-94127が「データプレーンの問題でコントロールプレーンへの露出はない」とされているのは、攻撃の入口が管理インタフェースではなく、利用者向けに公開した仮想サーバの通信処理にある、という意味に読めます。ここから実務上の帰結が2つ出てきます。

1つ目は、管理インタフェースへのアクセス制限では防げないことです。BIG-IPの管理画面を管理用セグメントに閉じる対策は多くの組織が済ませていますが、今回はOAuthのトークン発行のために外部へ公開している仮想サーバそのものが攻撃面です。通信を受け付けることが仮想サーバの役割である以上、到達経路を絞る余地は管理面より小さくなります。

2つ目は、BIG-IPが通信の中継点であることです。TMMは仮想サーバを通る通信の処理とAPMのセッション処理を担っています。F5は、コード実行に成功した攻撃者がどの権限でどこまで到達できるかを公表していません。ただ、アドバイザリの侵害の痕跡に「audit logの不審なコマンド」が挙がっていることから、F5は攻撃後にシステム上でコマンドが実行される事態を想定していると読めます(この解釈は筆者の推測です)。認可サーバとして発行してきたトークンや、BIG-IPに置いたTLSの秘密鍵、連携先の認証情報まで影響が及びうる前提で、後の見極めを組み立てます。F5がAppliance modeのBIG-IPも影響を受けると明記している点も、装置の動作モードでは防げないことを示しています。

ネットワーク境界に置く機器が近年狙われ続けている事情は、次の記事で扱っています。

パッチ適用までの緩和策#

F5のアドバイザリは、緩和策として影響するBIG-IP APMの仮想サーバにiRuleを適用する方法を挙げ、そのiRuleはF5サポートへ問い合わせて入手するよう案内しています。iRuleの内容は公開されていないため、この記事でも扱いません。保守契約の窓口と、サポートケースを起票できる担当者を先に確認しておくと、入手までの時間を縮められます。

CISAのKEVの備考は、iRuleを「事前のフォレンジックトリアージを行えるようにするための一時的な緩和」と位置づけ、トリアージが済んだら最終的なパッチを早く入れるよう求めています。iRuleは攻撃の入口を塞ぐための手当てで、EHFの代わりにはなりません。

BOD 26-04の3日という期限の読み方#

BOD 26-04は2026年6月10日に出された連邦機関向けの指令で、脆弱性の修正期限を、公開面への露出、KEVへの掲載、自動化可能性(Automatable)、技術的影響の4つの要素で振り分けています。指令の表1では、KEVに載った脆弱性の期限は3日か14日のどちらかです。公開面に露出した資産では、自動化可能か技術的影響が全面的(Total)のどちらかに当たれば3日、どちらでもなければ14日です。露出していない資産では、自動化可能かつ全面的な場合だけが3日で、それ以外は14日です。KEVに載った脆弱性の3日の区分のうち、技術的影響が全面的なものには「& forensic triage」が付きます。

CVE-2026-94127は、CISAのSSVC判定がAutomatable「yes」、Technical Impact「total」で、公開面への露出の有無にかかわらず「3日 & forensic triage」の区分に当たります。KEVの期限9月25日は、追加日9月22日から3日です。「& forensic triage」の印は、期限内に修正か緩和を終えたうえで、該当資産が侵害されていないかのフォレンジックトリアージを行うことを求めるものです。

BOD 26-04の実装ガイダンスでは、フォレンジックトリアージを6段階に分けています。対象の特定と体制の立ち上げ(2時間以内)、証拠の保全と収集(2時間から24時間)、パッチ適用と安定化(同)、封じ込め(6時間から24時間)、侵害の痕跡の分析(24時間から48時間)、インシデント対応へ格上げするかの判断(48時間から72時間)です。これらの時間はKEV追加時点からの推奨の目安です。ガイダンスは、指令が求めるのは十分なフォレンジックトリアージの実施であり、この時間配分は必須ではないと注記しています。ガイダンスは、可能な限り証拠の収集前にシステムを変更したり修正したりしないよう求めています。

BOD 26-04は米国の連邦民間行政機関に向けた指令で、民間企業に直接の義務はありません。それでも、悪用が確認され、自動化も可能で全面的な制御を奪える脆弱性は露出の有無にかかわらず3日で片づける、パッチの前に証拠を確保する、という組み立ては、そのまま自組織の対応計画の骨格に使えます。KEVを優先順位づけに組み込む方法は、次の記事で整理しています。

直ちに行う対応の順序#

侵害の痕跡を確認する#

F5のアドバイザリは、追跡ID 2524777の侵害の指標(Indicators of Compromise)として、次の要素を挙げています。ポイントは、それぞれ単独では異常と言い切れず、短い時間の中で3つがそろうことが調査の合図になるという点です。F5の言葉では、OAuthの認証失敗が続き、その後に不審なコマンドがあり、間もなくTMMのSIGABRTが起きる、という組み合わせが人による確認の対象になります。

統計の確認には、アドバイザリに記載のコマンドを使います。

tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed

確認は装置内のログだけで完結させません。上流のファイアウォールやWAF、SIEMに残る通信記録から、同じ送信元が仮想サーバへどう接続していたか、BIG-IPから外部への想定外の通信がないかを突き合わせます。ログが保存期間を過ぎて消えている場合、痕跡が見当たらないことを安全側の根拠にはできません。

次の項目は侵害を疑う材料です。対象の仮想サーバがiRuleかEHFを適用するまでインターネットから到達できた場合は、この確認を優先します。当てはまる項目があれば、ログの時刻を突き合わせて人による確認を行います。OAuthの失敗、不審なコマンド、TMMのコアファイルが近い時刻にそろう場合や、説明できない構成の変更やログの欠落がある場合は、侵害を前提とした調査へ進みます。

侵害が疑われる場合は、BIG-IPに置いたTLS証明書の秘密鍵、OAuth認可サーバとして使っている署名鍵やクライアントシークレット、APMが連携する認証基盤のサービスアカウントについて、入れ替えを検討します。入れ替えは連携先の再設定を伴い、手順を誤るとOAuthを使うアプリケーションが一斉に止まります。対象の一覧、切り戻しの手順、実施の時間帯をそろえてから着手します。証拠の扱い方と初動の進め方は、次の2本にまとめています。

恒久策として見直しておきたいこと#

1つは、BIG-IPで動かしている機能の棚卸しです。今回の条件に当てはまったかどうかにかかわらず、APMのうちどの機能(SSL VPN、SAML、OAuthのクライアントや認可サーバなど)をどの仮想サーバで使っているかを一覧にしておくと、次に機能単位の条件付きの脆弱性が出たとき、該当の判定が数分で済みます。今回、該当の判定にアクセスプロファイルと仮想サーバの突き合わせが必要だったことが、その理由です。

もう1つは、BIG-IPのログを装置の外へ集める運用です。F5が挙げた指標は、/var/log/apmと/var/log/auditとTMMのコアファイルの時刻の組み合わせで判断するものでした。装置の中にしか残っていないログは、侵害された場合に消されるおそれがあり、保存期間も限られます。リモートのsyslogやSIEMへ送っておけば、時刻の突き合わせをBIG-IPの外で行えます。

まとめ#

CVE-2026-94127は、BIG-IP APMをOAuth認可サーバとして構成した仮想サーバで、未認証の攻撃者がリモートコード実行に至るヒープベースのバッファオーバーフローです。F5のCVSSはv3.1が9.8、v4.0が9.3で、F5が悪用を把握しており、CISAは9月22日にKEVへ追加して期限を9月25日としました。影響版は21.1.0、17.5.0から17.5.1、17.1.0から17.1.3で、修正は系列ごとのEHFです。

対応の順序は、OAuth認可サーバのプロファイルから仮想サーバまでをたどって対象を確定する、F5サポートにiRuleを依頼する、iRuleやパッチで装置を変える前にログとコアファイルを退避する、iRuleを当ててF5が挙げた3つの指標の組み合わせを確認する、EHFを適用する、です。データプレーンの問題なので、管理画面を閉じていることは安心材料になりません。まずはOAuth Authorization ServerのOAuth Profileの一覧が空かどうかを確かめるところから始めると、対応の要否がすぐに分かります。