2026.09.30 脆弱性・インシデント

BIG-IPの脆弱性CVE-2026-94127とは？APMのOAuth構成の確認コマンドと侵害調査の手順

F5は2026年9月22日、BIG-IP APM（Access Policy Manager）のヒープベースのバッファオーバーフロー CVE-2026-94127 を公表しました。APMをOAuth認可サーバーとして構成している場合に限り、認証されていない攻撃者がリモートからコードを実行できる脆弱性で、F5自身が悪用を確認しています。この記事では、影響を受けるバージョンとホットフィックス、自社のBIG-IPが対象構成かをtmshで判定する手順、ログID 01990004を起点にした侵害調査のコマンド、そしてBIG-IPを認可サーバーにしている業務システム側で必要になる後処理までを、実装者の目線で整理します。記載内容は2026年9月30日時点の公開情報にもとづくものです。

まとめ：OAuth認可サーバー構成のAPMはホットフィックスと侵害調査を並行

CVE-2026-94127 は、仮想サーバーにAPMのアクセスポリシーとOAuthプロファイルが同居し、APMがOAuth認可サーバーとして動いている構成でだけ成立します。APMをOAuthクライアントやリソースサーバーとしてのみ使う構成は対象外です。まず自社の構成がどちらかを切り分けてください。

対象構成なら、やることは2つです。ひとつは21.1.0・17.5系・17.1系それぞれのEngineering Hotfixの適用、もうひとつは適用前の時点から侵害の痕跡を探す調査です。F5が悪用を確認しており、CISAは公表当日に既知の悪用リスト（KEV）へ登録しました。ホットフィックスは侵入済みの攻撃者を追い出しません。

さらに、BIG-IPを自社の業務システムやWebシステムの認可サーバーとして使っているなら、侵害が否定できない時点で署名鍵とクライアントシークレットの入れ替えまでを対応範囲に含めます。案件をまたいでBIG-IPの構成と露出を洗い出す場合は、外部の脆弱性診断で棚卸しを進めると抜けが出にくくなります。

CVE-2026-94127の中身とOAuth UserInfo要求で起きるヒープ破壊

BIG-IPは、負荷分散やSSL終端を担うロードバランサー（ADC）として企業の入口に置かれることが多い製品です。APMはその上で認証・アクセス制御を担うモジュールで、今回の欠陥はAPMのOAuth処理に含まれていました。

ヒープベースのバッファオーバーフローとCVSS 9.8・9.3の評価内訳

NVDのCVE-2026-94127には、F5が採点したCVSS v3.1の基本値9.8（ベクトル AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H）と、CVSS v4.0の9.3が並んでいます。脆弱性の型はCWE-122（ヒープベースのバッファオーバーフロー）です。ネットワーク越しに、認証なし・利用者の操作なしで、機密性・完全性・可用性のすべてに高い影響が出る、という評価になります。スコアの読み方そのものはCVSSの見方と計算方法で解説しています。

欠陥の中身は、発見者であるwatchTowr Labsの技術解説が具体的です。OAuthのUserInfoエンドポイント /f5-oauth2/v1/userinfo へのリクエストで、Authorizationヘッダの値を長さの検証なしに 0x4100 バイト（16,640バイト）のヒープ領域へコピーしていました。これを超える長さのBearerトークンを送るだけで、トラフィック処理を担うTMM（tmm64）のヒープが壊れます。

NVDの記述では、これはデータプレーンの問題で、管理用のコントロールプレーンには露出がありません。Appliance modeのBIG-IPも対象に含まれます。

悪用確認からCISA KEV登録・JPCERT/CC注意喚起までの時系列

公表から各機関の動きまでは、1週間ほどで一気に進みました。

日付（2026年）	出来事	出典
9月22日	K000162605を公表・悪用を確認	F5
9月22日	KEVに登録（対応期限9月25日）	CISA
9月23日	RCEに至る過程の技術解説を公開	watchTowr Labs
9月24日	JPCERT-AT-2026-0028を公開	JPCERT/CC

CISAのKEVカタログの該当項目には、登録から3日という短い期限に加え、フォレンジックの初期調査を求める旨が付記されています。JPCERT/CCの注意喚起は、国内で広く使われている製品であることと、技術解説の公開によって攻撃が広がるおそれを指摘しています。攻撃コードがどう成立し拡散するかはexploitの仕組みで扱っていますが、今回はその成立条件がすでに公開された段階です。

影響を受けるBIG-IPのバージョンとOAuthの役割で決まる露出条件の切り分け

影響の有無は「バージョン」と「APMのOAuthでの役割」の2軸で決まります。どちらか一方だけで判断すると、過剰対応か見落としのどちらかになります。

21.1.0と17.5系・17.1系の影響範囲と修正ホットフィックスの対応

JPCERT/CCの注意喚起が示す対象は、21系の21.1.0、17系の17.5.0〜17.5.1と17.1.0〜17.1.3です。修正はメンテナンスリリースではなく、ブランチごとのEngineering Hotfix（EHF）で提供されています。ホットフィックス名はRapid7の解説の整理にもとづきます。

21.1.0：Hotfix-BIGIP-21.1.0.2.0.30.22-ENG
17.5.0〜17.5.1：Hotfix-BIGIP-17.5.1.9.0.160.12-ENG
17.1.0〜17.1.3：Hotfix-BIGIP-17.1.3.5.0.41.14-ENG

適用前には、F5のアドバイザリK000162605で最新の対象範囲と修正版を必ず確かめてください。EHFは追って別番号へ差し替えられることがあります。NVDの記述どおり、技術サポートが終了した版（EoTS）は評価の対象外で、表に載っていないことは「影響なし」を意味しません。

OAuthクライアントやリソースサーバー用途のAPMが対象外になる理由

OAuthには、トークンを発行する認可サーバー、トークンを受け取って使うクライアント、トークンを検証して資源を返すリソースサーバーという役割の分担があります。役割ごとの動きはOAuth 2.0の仕組みと認可フローで詳しく説明しています。

欠陥のあるUserInfoエンドポイントは、認可サーバーとして振る舞うAPMが公開するものです。APMを社外のIdPにつなぐクライアントとして使う構成や、他社発行のトークンを検証するリソースサーバーとしてのみ使う構成では、このエンドポイント自体が公開されません。NVDの説明もこの区別を明記しています。

逆に言えば、「APMはSSL-VPNにしか使っていない」と思い込んでいる環境でも、過去の案件で認可サーバー用のOAuthプロファイルを作り、別の仮想サーバーに割り当てたまま残っている例は疑う価値があります。記憶ではなく設定で確かめます。

tmshで自社のBIG-IPが対象構成かを判定するコマンドと結果の読み方

判定はBIG-IPのシェルでtmshを実行すれば数分で終わります。ここでは読み取り専用のコマンドだけを使います。

稼働バージョンとOAuthプロファイルの同居を調べるtmshコマンド

次の順に実行し、稼働中のソフトウェア、認可サーバー用OAuthプロファイルの有無、そのプロファイルを割り当てた仮想サーバーを確認します。

# 1. 稼働中のボリュームとバージョン・適用済みホットフィックスを確認する
tmsh show sys software

# 2. 認可サーバー用のOAuthプロファイルが定義されているかを確認する
tmsh list apm profile oauth one-line

# 3. OAuthプロファイル名ごとに、それを割り当てた仮想サーバーを抜き出す
for p in $(tmsh list apm profile oauth one-line | awk '{print $4}'); do
  echo "== ${p}"
  tmsh list ltm virtual one-line | grep -w "${p}"
done

1で稼働中（Active）のボリュームが21.1.0、17.5.0〜17.5.1、17.1.0〜17.1.3のいずれかで、表の修正ホットフィックスが入っていなければバージョン条件に当たります。2で出てくる apm profile oauth は、APMを認可サーバーとして動かすためのプロファイルです。3で、そのプロファイルとAPMのアクセスプロファイルが同じ仮想サーバーの profiles に並んでいれば、露出条件を満たします。

プロファイル名は任意に付けられるため、名前に「oauth」を含むかどうかで判断しないでください。2の出力に既定の親プロファイルしか無く、3で何も抜き出されなければ、構成条件には当たらないと判断できます。

冗長構成のスタンバイ機と未使用の仮想サーバーを見落とさない範囲

確認はアクティブ機だけでは足りません。スタンバイ機にも同じ構成が同期されており、フェイルオーバーした瞬間に露出側へ回ります。検証環境や災害対策用のBIG-IP、仮想版（VE）も同じコマンドで確認します。

もうひとつの見落としは、無効化していない古い仮想サーバーです。3で見つかった仮想サーバーは、外部から到達できるか（公開IPやNATの有無）まで記録し、次の優先順位付けに使います。

ホットフィックス適用とiRule暫定緩和の手順を分ける判断基準と注意点

結論から言うと、対象構成であれば原則は即時のホットフィックス適用です。iRuleはあくまで、適用までの時間を稼ぐ手段と位置づけます。

即時にホットフィックスを当てる構成と計画停止まで待てる構成の線引き

インターネットから到達できる仮想サーバーに、認可サーバー用のOAuthプロファイルとアクセスプロファイルが同居している構成は、夜間の緊急作業を組んででも当日中に適用する対象です。悪用が確認済みで、発見者の技術解説も公開されています。定例の保守日を待つ理由がありません。

社内ネットワークからのみ到達できる構成でも、緊急度はわずかに下がるだけです。社内端末が1台でも乗っ取られれば、そこから同じリクエストを送れます。数日以内の計画停止で適用し、それまでは後述のiRuleで入口を絞る、という線引きにとどめます。

待ってよいのは、そもそも構成条件に当たらない環境だけです。その場合でも、次の定例でホットフィックスか後続の修正版へ上げておくと、将来OAuth認可サーバー機能を使い始めたときの事故を防げます。複数の拠点や案件でBIG-IPを抱えている場合は、脆弱性診断・セキュリティ診断で機器ごとの構成と外部からの到達性を棚卸しし、適用の順番を決めると抜けが出ません。

iRuleで暫定緩和する場面とEngineering Hotfix適用時の注意点

JPCERT/CCによれば、F5はホットフィックスを当てられない場合の暫定策として、APMの仮想サーバーに割り当てるiRuleを提供しています。Rapid7の整理では、このiRuleはF5サポート経由で入手する形で、公開されたコードはありません。出どころの分からないiRuleを検索して貼るのは避け、F5の案内どおりに入手します。CISAのKEVの記載も、iRuleで時間を稼いで初期調査を済ませ、その後に正式な修正を入れる順序を求めています。

EHFの適用自体にも注意があります。

適用前にUCSアーカイブで設定を退避し、稼働していないボリュームへインストールしてから切り替える。
冗長構成ではスタンバイ機から適用し、フェイルオーバーでサービスを移してからもう一方へ当てる。
適用後に1のtmshコマンドで、アクティブなボリュームにホットフィックスが載っていることを確かめる。
OAuthの認可フロー（トークン発行とUserInfo取得）を実際のクライアントで通しで試す。

侵害調査に使うログやコアファイルは、再起動や切り替えで失われるものがあります。適用作業の前に、次の章のコマンドで痕跡を退避しておく順番を守ってください。

ログID 01990004とTMMコアファイルから侵害の痕跡を調べる調査手順

JPCERT/CCは、F5が示した侵害検出の方法として、APMログ・OAuth統計・監査ログ・TMMコアファイル・起動スクリプトの5点を挙げています。まず広く機械的に拾い、痕跡があれば深く掘る、という順で進めます。

APMログのログID 01990004を送信元IP別に数える調査コマンド

ログID 01990004は、OAuthのUserInfo要求が失敗したイベントです。JPCERT/CCは、これが10回以上繰り返し記録されていないか、特に単一の送信元IPアドレスからでないかを確認するよう求めています。ローテーション済みの圧縮ログも含めて数えるため、zgrepを使います。

# ログID 01990004 の出現回数をファイルごとに数える（圧縮済みのローテーションログも対象）
zgrep -c '01990004' /var/log/apm*

# 01990004 の行からIPv4アドレスを抜き出し、10回以上出たものを多い順に並べる
zgrep -h '01990004' /var/log/apm* \
  | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' \
  | sort | uniq -c | sort -rn | awk '$1 >= 10'

# OAuthの要求数・UserInfo要求数・失敗数の統計（JPCERT/CC注意喚起に記載のコマンド）
tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed

# TMMのコアファイルが生成されていないか（/var/core は /shared/core へのリンク）
ls -l --time-style=full-iso /var/core/

# 起動スクリプト tmm.finish の更新日時を確認する
ls -l --time-style=full-iso /etc/bigstart/scripts/tmm.finish

IPアドレスの抜き出しはログ行に含まれる値をすべて拾うため、BIG-IP自身や仮想サーバーのアドレスも混ざります。上位に出たアドレスが外部のものか、社内の監視系か、を見分けてから判断してください。tmctlの統計は再起動で初期化されるため、説明できない失敗数の急増があれば、その時点の出力をファイルに保存しておきます。

TMMのコアファイルは、TMMがループ状態に陥ったときにSODデーモンがSIGABRTを送って生成されるとJPCERT/CCは説明しています。watchTowr Labsの解説でも、ヒープ破壊の結果としてtmm64が異常終了する挙動が示されました。公表以前の日付のコアファイルでも、原因が説明できないものは調査対象です。ログを長期で集めて相関を見るなら、SIEMの仕組みで解説している転送と保管の設計が前提になります。

痕跡が見つかった場合に監査ログとtmm.finishで追う次の調査の順序

01990004が短時間に集中していた場合は、同じ時間帯の /var/log/audit を確認し、身に覚えのないtmsh操作や設定変更がないかを見るのが先です。あわせて、/f5-oauth2/v1/userinfo に異常に長いAuthorizationヘッダを持つリクエストが届いていないかを、前段のWAFやプロキシのログで探します。JPCERT/CCは、このパス以外にも細工したリクエストが送られうると注記しています。

tmm.finish は改ざんされていないことの確認を求められているファイルです。更新日時がホットフィックスや保守作業の履歴と合わない、あるいは内容に見慣れないコマンドが追記されている場合は、侵害を前提に切り替えます。

痕跡が1つでも確認できたら、その機器での自己調査を続けるより、ログとディスクの保全を優先します。証拠を壊さずに調べる手順や外部への依頼の考え方はデジタルフォレンジックの流れで整理しています。F5サポートへ連絡するときは、診断ファイル（qkview）と上記コマンドの出力を添えるのが近道です。

BIG-IPを認可サーバーにしている業務システム側で必要になる後処理と判断

ここからは、BIG-IPの運用担当ではなく、BIG-IPが発行したトークンで動く業務システムやWebシステムを作る側の話です。認可サーバーが侵害された可能性があるなら、その下流のアプリにも影響が及びます。

認可サーバーの署名鍵とクライアントシークレットを入れ替える範囲の判断

リモートコード実行が成立したBIG-IPでは、そこに置かれた秘密情報をすべて漏れたものとして扱うのが安全側の判断です。OAuth認可サーバーとして使っていた場合、対象は少なくとも次の3種類になります。

トークンに署名する鍵（JWTで発行していればその署名鍵）
各クライアントアプリに発行したクライアントIDとシークレット
発行済みのアクセストークンとリフレッシュトークン

侵害の痕跡が見つかった、または露出期間中のログが残っておらず否定できない場合は、3種類とも入れ替えます。署名鍵を替えれば旧鍵で署名されたトークンは検証に通らなくなるため、下流のリソースサーバーで公開鍵（JWKS）の再取得が走るか、キャッシュ期間はどれだけかを先に確認しておきます。

逆に、構成条件に当たらなかった場合や、露出期間の全ログを確認して痕跡が無かった場合まで、全鍵を入れ替える必要はありません。作業の重さと停止の影響を考えると、そこは過剰対応です。

BIG-IP依存の認可基盤を見直すべき条件と、使い続けてよい条件

今回の件を機に、認可サーバーをBIG-IPから外すべきかという相談が出てきます。判断は次の条件で分けられます。

見直しを勧めるのは、BIG-IPのOAuth認可サーバー機能を1〜2本の社内アプリのためだけに使っていて、APMの保守契約やEHFの適用体制が手薄な場合です。認可サーバーはIDaaSや専用の認可サーバーに寄せ、BIG-IPはネットワークの入口に専念させたほうが、脆弱性が出たときの影響範囲を小さく保てます。

使い続けてよいのは、F5の保守契約があり、今回のEHFを数日以内に当てられる体制が現に動いている場合です。この条件を満たしているなら、移行作業のリスクのほうが大きくなります。どちらを選ぶにしても、BIG-IPを含む入口の機器と、その下流のアプリを一続きで点検する前提は変わりません。同じ週に悪用が確認されたNetScalerの件はNetScalerの脆弱性CVE-2026-88771の確認コマンドと侵害調査で整理しています。診断の範囲の決め方や費用の目安は脆弱性診断の進め方と外注時の判断基準で解説しています。

BIG-IPの脆弱性CVE-2026-94127対応でよく受ける質問と実務的な回答

CVE-2026-94127の対応を進める際に出てきやすい疑問を、公開されている一次情報の範囲で答えます。

BIG-IP APMを使っていなければ影響はありませんか？

影響はありません。CVE-2026-94127はAPMのOAuth認可サーバー機能の欠陥で、LTMなど他のモジュールだけを使う構成は対象外です。ただしAPMのライセンスが有効で、過去に検証目的でOAuthプロファイルを作っていたという例もあります。記事中の tmsh list apm profile oauth one-line で、プロファイルが実在しないことまで確認しておくと確実です。

管理画面を外部に公開していなければ安全ですか？

安全とはいえません。NVDの記述では、これはデータプレーンの問題で、管理用のコントロールプレーンには露出がありません。攻撃は利用者向けの仮想サーバーに届くHTTPリクエストで成立します。管理インターフェースを閉じていても、OAuthのエンドポイントを公開している仮想サーバーが到達可能なら対象になります。

ホットフィックスを当てれば侵害調査は不要ですか？

不要にはなりません。ホットフィックスは今後の悪用を止めるもので、適用前に仕込まれた改ざんや持ち出された鍵は元に戻りません。CISAのKEVも初期調査の実施を求めています。ログとコアファイルを退避し、01990004の集計を済ませてから適用に入る順番を勧めます。

ログID 01990004が数回だけ出ている場合も侵害を疑うべきですか？

数回程度なら、クライアントの設定誤りや期限切れトークンによる通常の失敗である可能性が高いといえます。JPCERT/CCが目安として示しているのは、10回以上の繰り返しと、単一の送信元IPアドレスからの集中です。回数が少なくても、同じ時間帯にTMMのコアファイルが生成されている場合は、組み合わせとして調査を進めてください。

サポート終了済みのBIG-IPを使っている場合はどうすればよいですか？

NVDの記述では、技術サポートが終了した版は評価の対象外とされており、影響の有無も修正の提供も示されていません。対象外と読むのではなく、評価されていないと読むべきです。OAuth認可サーバー機能を使っているなら、その機能を別の仮想サーバーや別の認可基盤へ移すか、サポート対象のブランチへ更新したうえでホットフィックスを当てる計画を立てます。