LoadMaster脆弱性が悪用中、KEV登録は39日後

【更新 2026-08-12】本記事を見直し、修正しました。主な修正点：NVDの影響範囲について「ベンダーの修正版を影響対象に含めてしまっている」としていた説明を、一次情報（NVDのCPEおよびCVEレコード）に基づき「修正版は影響範囲に含まれていない。情報源で異なるのは範囲の下限の書き方」に訂正しました。

結論から。ロードバランサ／ADC製品「Progress LoadMaster」（旧Kemp LoadMaster）の認証不要でOSコマンドを実行できる脆弱性（CVE-2026-8037）が、実際に攻撃に使われていることが確認されました。米CISAは2026年8月7日、これを「悪用が確認された脆弱性カタログ（KEV）」に追加し、米連邦政府機関に8月10日までという3日間の是正期限を課しています。

ただし本記事で最も伝えたいのは、そこではありません。攻撃の試みが観測され始めたのは、KEV登録の39日前にあたる6月29日です。KEVへの登録を起点に動く脆弱性管理をしていた組織は、その約6週間、狙われていることを知らないまま無防備でした。該当製品を使っている情シスの方は、まずバージョン確認を。使っていない方も、この39日という空白は自社の運用にそのまま当てはまる話です。

この記事でわかること

• CVE-2026-8037 で何ができてしまうのか（種類・深刻度・攻撃の前提）
• 影響を受ける製品とバージョン、そして情報源によって版の範囲の書き方が異なる点
• 公表 → PoC公開 → 攻撃開始 → KEV登録の時系列と、そこから読み取れる運用の限界
• 深刻度が 9.6 と 9.8 に割れている理由と、その差が実務で持つ意味
• 情シスが今週打つべき手（パッチだけでは終わらない理由）

何が起きたのか

CVE-2026-8037 は、LoadMaster の管理APIに渡される入力の検証が不十分なために、認証されていない攻撃者が装置上で任意のOSコマンドを実行できる脆弱性です。脆弱性の分類は CWE-77（コマンドインジェクション）。Progress社が2026年6月4日にセキュリティ情報を公開しました。

技術的には単純なコマンドインジェクションではありません。調査を公開した watchTowr Labs によれば、/accessv2 エンドポイントで apiuser パラメータを処理する際、確保したヒープ領域が初期化されずヌル終端も付かないため、隣接する解放済み領域の内容まで読み込んでしまいます。攻撃者はここに JSON のキーと値を大量に送り込んで（ヒープスプレー）任意の文字列を配置し、それがシェルコマンドの一部として実行される、という流れです。修正は、確保時に領域をゼロで初期化し、明示的にヌル終端を付けるというものでした。

ADC／ロードバランサは、Webアプリケーションの前段に置かれ、通信を振り分け、多くの場合TLSを終端する中核機器です。ここを取られるということは、背後のサーバ群への足がかりを与えるだけでなく、復号された状態の通信そのものに手が届くことを意味します。

自社は影響を受けるのか（該当判定）

まず対象バージョンです。LoadMaster には通常提供（GA）と長期サポート（LTSF）の2系統があり、それぞれ別の修正版が出ています。

対象は「LoadMaster」という名前の製品だけではない

見落としやすいのがここです。NVDに登録された影響範囲（CPE）には、LoadMaster 本体のほかに次の製品が含まれています。いずれも 7.2.63.2 より前が対象です。

• MOVEit Web Application Firewall（MOVEitに同梱されるWAF製品）
• ECS Connection Manager
• Connection Manager for ObjectScale

同じコードベースを別の製品名で提供しているためです。「うちはLoadMasterは入れていない」で終わらせず、MOVEitの周辺やストレージ基盤の接続管理コンポーネントまで棚卸しの範囲に入れてください。なお、MOVEitは2023年の大規模悪用で名前が知られていますが、そのとき問題になったのは MOVEit Transfer であり、今回対象なのは同梱WAFのほうです。別件として整理する必要があります。

NVDとベンダーで、版の範囲の書き方が異なる

注意点をひとつ。NVDに登録された影響範囲は LoadMaster について「7.2.54.18 未満」「7.2.55.0 以上 7.2.63.2 未満」で、ベンダーが修正版としている 7.2.54.18 と 7.2.63.2 は、影響を受ける側に含まれていません（CPEの版指定が、その版を含まないことを示す versionEndExcluding になっています）。修正版へ更新済みの機器が、NVD由来のデータで「未対応」と判定されることはありません。

ただし、範囲の下限の書き方は情報源でずれています。ベンダーのセキュリティ情報が「7.2.63.1 とそれ以前のすべてのバージョン」としているのに対し、Progress社が登録したCVEレコードは「7.2.60.0 以上 7.2.63.2 未満」「7.2.45.12 以上 7.2.54.18 未満」と下限を設けており、NVDのCPEはGA系の下限を 7.2.55.0 としています。該当判定はベンダーのセキュリティ情報に記載された修正版の番号を基準に行ってください。バージョン範囲の記載が情報源によってずれるのは珍しいことではなく、機械的な照合だけに頼らない理由がここにあります。

同時に修正されたもう1件は、実はOWASPの規則側の問題

Progress社の同じセキュリティ情報では CVE-2026-33691 も併せて修正されています。これは LoadMaster 固有の欠陥ではなく、WAFの検知規則として広く使われている OWASP Core Rule Set（CRS）の問題です。ファイル名に空白を混ぜると拡張子の判定をすり抜け、.php や .jsp などの危険な拡張子のファイルをアップロードできてしまうというもので、CRS 3.3.9 および 4.25.0 で修正されています。自前で ModSecurity と CRS を運用している組織は、LoadMaster の有無にかかわらずCRSのバージョンを確認する価値があります。

攻撃が始まったのは、PoC公開の当日だった

本件で最も実務的に重い事実が、この時系列です。

読み取れることは2つあります。

ひとつめ。実質的な猶予は、公表からPoCが世に出るまでの25日間しかありませんでした。そしてPoCが出た日には、もう攻撃が来ています。「重大な脆弱性が出たら、まず様子を見る」という運用は、この25日を消費するための運用です。境界に置かれた機器については、その余裕はないと考えたほうが現実的です。

ふたつめ。KEV登録は、攻撃観測の開始から39日後、最初の公表からは64日後でした。KEVは非常に有用なカタログですが、「悪用が公的に確認され、カタログに載る」までには時間がかかります。KEVへの登録をトリガーに緊急対応を発動する運用（多くの組織がそうしています）は、この39日間、何も発火しません。

これはCISAの怠慢という話ではなく、公的な確認プロセスには必ず遅延が伴うという構造の話です。だからこそ、KEVは「対応の開始点」ではなく「遅れていないかを検証する答え合わせ」として使うほうが実態に合います。優先順位の判断はKEV登録を待たず、（1）認証が不要か（2）インターネットから到達しうるか（3）その機器が何を守っているか、の3点で行う。今回はこの3つすべてが最悪の側に振れていました。

なお、eSentireは観測した範囲では攻撃は成功しておらず、侵害後の活動は確認されなかったと明記しています。「大量の被害が出ている」という話ではありません。ただし同社が観測できたのは同社の監視下にある環境だけであり、成功例がないことの証明にはならない点は押さえておく必要があります。

ログで確認すべきこと

eSentireが公開した攻撃元IPアドレスは以下の3つです。管理インターフェースのアクセスログが残っていれば、6月下旬以降の記録を検索する価値があります。

• 192.42.116.58
• 192.42.116.105
• 146.70.139.154

ただし、これらは6月末時点の観測に基づくもので、現在も同じ経路が使われている保証はありません。IPアドレスでの照合は「見つかれば黒に近い」が「見つからなくても白ではない」情報として扱ってください。より確実なのは、/accessv2 への認証前アクセスや、管理インターフェースに対する想定外の送信元からのリクエストがないかを確認することです。

深刻度が9.6と9.8に割れている──この差が示すもの

CVSSの基本値が、評価主体によって割れています。

どちらも Critical なので優先度の結論は変わりませんが、差が出ている項目に意味があります。ベンダーは攻撃元を AV:A（隣接ネットワーク）と評価しています。つまり「管理インターフェースは内部ネットワークからしか触れない前提」です。一方NVDは AV:N（ネットワーク）、つまりインターネット越しに到達しうるという評価です。

そして実際に攻撃が観測されたという事実は、ベンダーが前提としたネットワーク設計になっていない機器が現実に存在することを示しています。ベンダーのスコアは「正しく設計されていれば」という条件付きの評価であり、自社の実装がその条件を満たしているかは自分で確認するしかありません。

逆に、ベンダー側だけが厳しく評価している項目もあります。S:C（スコープ変更あり）は「侵害が装置の外へ波及する」という評価で、ロードバランサという製品の性質を踏まえればベンダー側のほうが実態に近いと言えます。スコアの数字ではなく、ベクタの各項目を自社の構成と突き合わせる——結局はこれに尽きます。CVSSの読み方そのものについてはCVSSとは？脆弱性の深刻度を評価する仕組みと使い方もあわせてご覧ください。深刻度が情報源によって割れる事例はQNAP NASのCSRF脆弱性の記事でも扱っています。

LoadMasterがKEVに載るのは、これが2度目

もうひとつ押さえておきたい事実があります。この製品がKEVに登録されるのは初めてではありません。

約1年9か月の間隔で、同じ製品の、同じ管理インターフェース周りで、同じ「未認証のコマンドインジェクション」が2度悪用されています。個別のCVEを都度つぶす対応だけでは、この繰り返しに追いつけません。この製品の管理インターフェースをどこまで露出させるか、という設計側の判断が問われています。

視野を広げると、この構図は特定ベンダーの問題ではありません。KEVカタログ（2026年8月10日版・全1,662件）を筆者が集計したところ、ADC・ロードバランサ・SSL-VPNアプライアンス製品に絞っただけで38件が登録されており、うち14件はランサムウェア攻撃での使用が確認済みでした（内訳はCitrix 16件、SonicWall 9件、F5 7件、Progress・Array Networks・Aviatrix 各2件）。境界に置かれる機器は、攻撃者にとって定番の入口です。SonicOSの管理画面を狙う脆弱性やCiscoのSD-WAN・IOS XEの脆弱性も同じ系統の話です。

現場目線：ロードバランサは「誰の担当か」が曖昧になりやすい

率直なところ、この手の機器がいちばん危ないのは、技術的な理由よりも所管の曖昧さだと感じています。

ロードバランサは、ネットワーク機器としてインフラ担当が見ているようでいて、アプリケーションの前段にあるためWeb担当の管轄にも見える。仮想アプライアンスとして導入されていれば、サーバ仮想化基盤の担当が「入れ物」だけ管理していて中身のファームウェアは誰も見ていない、ということも起こります。導入時にベンダーやSIerが構築してそのまま、というケースも少なくありません。

結果として、脆弱性情報が流れてきても「うちの機器かどうか」を即答できる人がいないという状態になりがちです。今回のように25日で猶予が尽きる案件では、この「誰に聞けばいいか分からない時間」がそのまま露出時間になります。

限られた人員で全機器の細部まで把握するのは現実的ではありません。だからこそ、せめてインターネットに接している機器だけは、製品名・バージョン・管理者・保守契約の有無を1枚の表にしておくことをおすすめします。網羅的な資産管理台帳を整えるより、境界に絞った小さな一覧のほうが、実際には回ります。

情シスは何をすべきか

優先順に整理します。

1. バージョンを確認し、修正版へ更新する。GA系は 7.2.63.2、LTSF系は 7.2.54.18 が基準です。MOVEit WAF・ECS Connection Manager・Connection Manager for ObjectScale も対象に含めます。
2. 管理インターフェースの露出を確認する。これは更新と並行して進めてください。攻撃前提が AV:A か AV:N かの分かれ目であり、次の脆弱性が出たときの被害の大きさを決めます。管理アクセスは接続元IPで制限し、可能なら管理用セグメントに閉じます。
3. 更新して終わりにしない。CISAは今回、単なるパッチ適用ではなく、リスクに基づく更新の優先付けを求める指令「BOD 26-04」と、フォレンジック・トリアージ（侵害有無の調査）の要件への準拠を求めています。すでに悪用されている脆弱性では、「塞いだ」と「侵害されていない」は別の話です。ログが残っていれば6月下旬以降を確認し、装置上の管理者アカウントや証明書・鍵の扱いも点検対象に入れてください。

なお、8月10日という期限は米連邦政府機関に対するものであり、日本の民間企業に法的拘束力はありません。ただし「その期限で対応すべきと当局が判断した」という優先度のシグナルとして読む価値は十分にあります。KEVの3日期限は例外的な扱いではなく、2026年に追加された178件のうち73件（41.0%）が3日以内、8月の追加6件はすべて3日以内でした。短い期限自体が異常事態を意味するわけではない、という点も併せて押さえておくと、社内説明の温度感を誤らずに済みます。

より一般的な脆弱性対応の体制づくりについては、IPAの公的な資料が実用的です。中小規模の組織であれば中小企業の情報セキュリティ対策ガイドラインが体制と優先順位の考え方を示しています。侵害の可能性を想定した対応手順を事前に確認しておくなら、セキュリティインシデント対応 机上演習教材が無償で利用できます。今回のように「境界機器が乗っ取られたかもしれない」というシナリオは、演習の題材としても現実的です。実際に侵害が疑われる場合の届出・相談先はJPCERT/CCのインシデント報告窓口です。

すでに悪用されている脆弱性について、パッチ適用後に痕跡を確認する具体的な考え方はTeamCityの脆弱性が悪用された事例の記事でも詳しく扱っています。

まとめ

• Progress LoadMaster の未認証RCE（CVE-2026-8037）は実際に悪用されており、CISAが8月7日にKEVへ登録した。GA系は 7.2.63.2、LTSF系は 7.2.54.18 が修正版。MOVEit WAF など別名の製品も同じコードベースで対象に含まれる。
• 攻撃の試みはPoC公開当日の6月29日から観測されており、KEV登録はその39日後。KEVを起点にする運用では、この期間は発火しない。優先順位は「未認証か・外から届くか・何を守る機器か」で自分で判断する。
• 深刻度は9.6と9.8に割れており、差は攻撃元の想定（隣接ネットワークかインターネットか）。現に攻撃が観測された以上、ベンダーの前提どおりの構成になっているかは自社で確認するしかない。

出典

• Progress: LoadMaster Critical Security Bulletin June 2026 (CVE-2026-8037, CVE-2026-33691)
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: BOD 26-04 Prioritizing Security Updates Based on Risk
• NVD: CVE-2026-8037
• NVD: CVE-2026-33691（OWASP CRS）
• eSentire: Progress Kemp LoadMaster Vulnerability Targeted (CVE-2026-8037)
• watchTowr Labs: Progress Kemp LoadMaster — Uninitialized Heap to Pre-Auth RCE (CVE-2026-8037)
• Security NEXT: 「Progress Kemp LoadMaster」の脆弱性が標的に – 米当局が注意喚起

補足：本文中のKEVカタログの集計値（全1,662件、2026年追加178件のうち3日以内期限73件、ADC・ロードバランサ・SSL-VPNアプライアンス関連38件など）は、CISAが公開している既知悪用脆弱性カタログのJSONデータ（2026年8月10日版）を筆者が集計したものであり、CISAが公表している統計ではありません。製品分類は筆者の判断によります。