MENU

問い合わせ


    F5 BIG-IPの脆弱性、発注者は何を確認する?悪用済みの脆弱性から考える保守契約と機器の棚卸し

    2026年9月24日、JPCERT/CC(=日本のセキュリティ情報を取りまとめて注意喚起する組織)が、F5社のネットワーク機器「BIG-IP」の一機能である「Access Policy Manager(APM)」に深刻な脆弱性(=セキュリティ上の弱点)があり、すでに悪用が確認されているとして注意喚起を出しました。BIG-IPは、社外からのリモートアクセスや大規模なWebサービスの入口で使われることがある製品です。

    「うちのシステムでその機器を使っているのかも分からない。こういう脆弱性のニュースが出たとき、発注者は何をすればいいの?」

    先に結論をお伝えします。発注者が技術的な中身を理解する必要はありません。やるべきことは「自社のシステムに該当製品が使われているかを開発会社・保守会社に確認する」「誰がいつまでに対応するかをはっきりさせる」の2つです。そして今回のニュースを、脆弱性対応が保守契約のどこに書かれているかを見直すきっかけにするのがおすすめです。

    この記事では、ニュースの要点と、システムの発注者にとって何が変わるのか、そのまま使えるチェックリストと開発会社への質問例をまとめます(情報は執筆時点:2026年9月のものです)。

    目次

    F5 BIG-IP APMの脆弱性ニュースの要点

    まずは、公表されている事実を整理します。

    📰 出典:JPCERT/CC「F5 BIG-IP Access Policy Managerのヒープベースのバッファオーバーフローの脆弱性(CVE-2026-94127)に関する注意喚起」

    JPCERT/CCの注意喚起(2026年9月24日公開)によると、ポイントは次のとおりです。

    • 対象はF5社の「BIG-IP Access Policy Manager(APM)」の一部のバージョン(21.1.0、17.5.0〜17.5.1、17.1.0〜17.1.3)
    • APMを「OAuth認可サーバー」(=ログインの許可を発行する役割)として使う特定の設定の場合に影響を受ける
    • 悪用されると、認証なしで外部から任意のコードを実行される(=機器を乗っ取られる)おそれがある
    • F5社は、この脆弱性がすでに悪用されていると公表している
    • 対策として、F5社が提供する修正プログラム(ホットフィックス)の適用が推奨され、すぐに適用できない場合の暫定的な回避策も案内されている

    海外のセキュリティメディアでも、深刻度を示す指標が高く評価されていることや、米国の政府機関(CISA)が「悪用が確認された脆弱性の一覧」に追加したことが報じられています。

    📰 出典:The Hacker News「F5 Patches Critical BIG-IP APM Zero-Day Exploited for Unauthenticated RCE on OAuth Servers」

    同記事(2026年9月23日付)によると、CVSS(=脆弱性の深刻度を0〜10で表す指標)はv3.1で9.8、v4.0で9.3とされ、CISAは9月22日に一覧へ追加しました。一方で、どれくらいの数のシステムが攻撃されたか、どの組織が狙われたかは明らかにされていないとも伝えています。

    ここで大切なのは、「すべてのBIG-IP利用者が危険」ではないという点です。影響を受けるのは、特定のバージョンかつ特定の設定の場合に限られます。ただし、それを判断できるのは機器を設定・管理している担当者であり、発注者が自分で判断する必要はありません。

    発注者にとって何が変わるか・変わらないか(筆者の見解)

    ここからは、ニュースの事実をふまえた筆者の見解です。

    変わらないこと:脆弱性は「いつか必ず出るもの」

    今回の件は特別な出来事ではありません。VPN装置やリモートアクセス機器、CMS、フレームワークなど、広く使われている製品には定期的に脆弱性が見つかります。IPAやJPCERT/CCは毎月のように注意喚起を出しています。

    つまり、発注者が考えるべきなのは「脆弱性が出ないシステム」を求めることではなく、「脆弱性が出たときに、誰がどう動くか決まっているシステム」にしておくことです。この考え方は今回のニュースの前後で変わりません。

    変わること:「悪用済み」の脆弱性は判断のスピードが求められる

    今回のように「公表された時点ですでに悪用が確認されている」脆弱性(いわゆるゼロデイ)では、「次の定期メンテナンスでまとめて対応」という進め方が合わない場合があります。修正プログラムの適用には、機器の再起動やサービスの一時停止が必要になることもあり、発注者側の判断(いつ止めてよいか、費用を誰が持つか)が対応のボトルネックになりがちです。

    また、社外との接続口になる機器は、社内のサーバーやデータへの入口でもあります。システム本体の開発会社と、ネットワーク機器を管理する会社が別々というケースも多く、「どちらの担当か分からない」まま時間が過ぎることがいちばん避けたい状況です。

    開発会社側の事情も知っておく

    保守契約の範囲によっては、ネットワーク機器やミドルウェア(=OSとアプリの間で動く基盤ソフト)の脆弱性対応が含まれていないこともあります。これは開発会社が不誠実なのではなく、契約時に「どこまでを保守の対象にするか」を決めていなかったことが原因である場合がほとんどです。範囲外の対応に追加費用がかかるのは自然なことなので、平時のうちに決めておくのが双方にとって安心です。

    今やるべきこと・まだ様子見でいいこと

    今やるべきこと

    • 該当製品の利用有無を確認する:自社のWebシステム・業務システム、リモートアクセス環境で「F5 BIG-IP(APM)」が使われているか、開発会社・保守会社・情シス担当に確認します
    • 使っていた場合は、対応の担当者と期限を決める:該当バージョン・該当設定かどうかの確認、修正プログラム適用の予定日、サービス停止の有無を報告してもらいます
    • 対応結果を記録してもらう:「確認した」「適用した」を口頭ではなく、メールや報告書で残します

    まだ様子見でいいこと

    • 機器の入れ替えやメーカー変更の検討:脆弱性はどの製品にも出るものです。一度の脆弱性だけで製品を変える判断を急ぐ必要はありません。更改時期が近いなら、そのときの比較材料の一つにする程度で十分です
    • 技術的な詳細の把握:攻撃の仕組みを発注者が理解する必要はありません。「該当するか」「対応済みか」の2点が分かれば判断できます
    • 使っていなかった場合の追加対策:該当製品を使っていなければ、今回の件で急いで何かを追加する必要はありません。ただし、次に同じようなニュースが出たときにすぐ答えられるよう、後述の棚卸しは進めておきましょう

    発注者がやることチェックリスト

    • ☐ 自社システムでF5 BIG-IP(APM)を使っているか、開発会社・保守会社に確認した
    • ☐ 使っている場合、該当バージョン・該当設定かどうかの回答と、対応予定日を受け取った
    • ☐ 修正プログラム適用に伴うサービス停止の可否を、社内の関係部署と調整した
    • ☐ 対応の結果を書面(メール・報告書)で受け取り、保管した
    • ☐ 自社システムで使っている主な製品(ネットワーク機器・OS・CMS・フレームワーク)の一覧があるか確認した
    • ☐ 保守契約に「脆弱性対応」がどこまで含まれるか(対象範囲・対応期限・費用)を確認した
    • ☐ システム本体とネットワーク機器の担当会社が別の場合、窓口と連絡ルートを整理した

    開発会社への質問例

    打ち合わせやメールで、そのまま使える質問です。

    • 「今回のF5 BIG-IP APMの脆弱性について、当社のシステムや接続環境は影響を受けますか?確認結果をメールでいただけますか?」
    • 「影響がある場合、修正の適用はいつ頃になりますか?サービスを止める必要はありますか?」
    • 「当社のシステムで使っている機器やソフトウェアの一覧(バージョン付き)はありますか?なければ作成をお願いできますか?」
    • 「今の保守契約では、ネットワーク機器やミドルウェアの脆弱性対応は範囲に含まれていますか?含まれない場合、どこに頼めばよいですか?」
    • 「緊急度の高い脆弱性が公表されたとき、御社から連絡をいただける仕組みはありますか?」

    まとめ:脆弱性ニュースは「保守の仕組み」を見直すチャンス

    2026年9月24日にJPCERT/CCが注意喚起したF5 BIG-IP APMの脆弱性は、特定の設定で影響を受け、すでに悪用が確認されているものです。発注者がやるべきことは、技術を理解することではなく、次の3つです。

    • 自社システムで該当製品を使っているかを確認する
    • 使っていれば、誰がいつまでに対応するかを決めて記録を残す
    • 機器・ソフトウェアの一覧と、保守契約の脆弱性対応の範囲を平時に整えておく

    脆弱性はどんな製品にもいつか見つかるものです。「出たときに慌てない仕組み」を開発会社と一緒に作っておくことが、結果的にいちばんのリスク対策になります。まずは今回の件を、開発会社へ一本確認のメールを送るきっかけにしてみてください。

    あわせて読みたい関連記事

    システム制作・運用・保守のお問い合わせはこちら


      よかったらシェアしてね!
      • URLをコピーしました!
      • URLをコピーしました!

      この記事を書いた人

      株式会社THIRD HERO代表取締役 朝野貴朗
      Webシステム開発を中心に、toC向けサービスサイトの運営、ツール開発などを行ってまいりました。

      コメント

      コメント一覧 (1件)

      コメントする

      目次