CVE-2026-8037｜LoadMaster RCE の影響確認と更新判断

はじめに

Progress Kemp LoadMaster は、Web サービスの前段に配置されることの多いロードバランサー / ADC です。2026 年 6 月 4 日に公開された CVE-2026-8037 は、その API 処理に存在する OS コマンドインジェクションで、認証なしでアプライアンス上の任意コマンド実行につながるとされています。

公開当初は PoC も悪用も確認されていない脆弱性として扱われていましたが、6 月末に技術解析と PoC 相当のコードが公開され、同時期から悪用試行の観測報告が出ています。さらに 2026 年 8 月 7 日には、CISA の Known Exploited Vulnerabilities（KEV）Catalog に追加されました。約 2 か月のあいだに扱いが段階的に変化しているため、6 月時点の情報だけで対応方針を決めると、優先度の判断を誤る可能性があります。

GA v7.2.63.1 以前、LTSF v7.2.54.17 以前を利用している場合は、影響範囲に含まれます。 CVE-2026-8037 の修正が最初に入ったのは GA 7.2.63.2 / LTSF 7.2.54.18 ですが、その後に別のセキュリティ更新が公開されており、2026 年 8 月時点で更新を計画する場合の現行リリースは GA 7.2.63.3 / LTSF 7.2.54.19 です。KEV への追加は、CISA が悪用の根拠に基づいて登録したことを意味するため、管理プレーンの到達範囲を確認したうえで、優先度を上げて更新を計画することをおすすめします。

CVE-2026-8037 の内容と KEV 追加までの時系列

このセクションでは、脆弱性そのものの内容と、公開から KEV 追加までに何が起きたのかを情報源ごとに分けて整理します。悪用状況については、ベンダーの記述、第三者の観測、CISA の登録がそれぞれ別の事実であり、混同すると誤った安心や過剰な断定につながります。

脆弱性の概要: API 経由の OS コマンドインジェクション

CVE-2026-8037 は、Progress ADC 製品の API における入力値のサニタイズ不備に起因する OS コマンドインジェクションです。CVE レコードでは CWE-77（コマンド実行に使用される特殊要素の不適切な無害化）に分類されており、認証されていない攻撃者による任意コマンド実行が想定される影響として記載されています。

参考: LoadMaster Critical Security Bulletin – June 2026（Progress）
“OS Command Injection Remote Code Execution Vulnerability in API in Progress LoadMaster”
（Progress LoadMaster の API における OS コマンドインジェクションによるリモートコード実行の脆弱性）
https://community.progress.com/s/article/LoadMaster-Critical-Security-Bulletin-June-2026-CVE-2026-8037-CVE-2026-33691

技術的な成立過程については、watchTowr Labs が 2026 年 6 月 29 日に解析を公開しています。同社の解析では、入力値をエスケープする処理で文字列の終端が正しく設定されないため、意図しない領域のデータが後続の処理に取り込まれ、最終的にコマンド実行につながるとされています。watchTowr が実証した攻撃経路は、API の /accessv2 エンドポイントを起点とするものです。

一方、Progress は影響を受けるモジュールを API/UI としており、公開情報から確認できる影響範囲は API だけに限定されていません。watchTowr が実証した攻撃経路と、Progress が示す影響範囲は一致していないため、API を無効化していれば影響を受けないとは判断できません。 この記事では PoC や攻撃コードの再現は扱わず、影響範囲の判断と対応手順に絞って整理します。

公開から KEV 追加までの経緯を時系列で整理する

公開情報から確認できる範囲を時系列にまとめると、次のようになります。

日付（2026 年）	出来事	情報源
6 月 4 日	Progress が Security Bulletin を公開。CVE レコードも同日公開	Progress / CVE Program
6 月 29 日	watchTowr Labs が技術解析を公開。同日に機能する PoC コードが公開され、eSentire TRU が悪用試行の観測を開始（Advisory は 6 月 30 日公開）	watchTowr Labs / eSentire
7 月 13 日	NVD が初回分析を実施し、CVSS を付与	NVD
7 月 31 日	Progress Bulletin の最終更新日	Progress
8 月 7 日	CISA が KEV Catalog に追加（対応期限は 8 月 10 日）	CISA / NVD

ここで区別が必要なのは、6 月 29 日以降に観測されているのは「悪用試行」であり、侵害の成立が確認されたという報告ではない点です。eSentire は自社の観測範囲について、悪用は成功しておらず、侵害後の活動も観測されていないと記載しています。

参考: Progress Kemp LoadMaster Vulnerability Targeted (CVE-2026-8037)（eSentire）
“In cases observed by eSentire, exploitation was not successful”
（eSentire が観測したケースでは、悪用は成功していない）
https://www.esentire.com/security-advisories/progress-kemp-loadmaster-vulnerability-targeted-cve-2026-8037

一方、8 月 7 日の KEV 追加は、CISA が悪用の事実を根拠に登録したことを示します。CISA-ADP が CVE レコードに付与している SSVC の Exploitation 値も、6 月 5 日時点の none から 6 月 30 日に poc、8 月 7 日に active へと更新されています。ただし、どの攻撃者が、どの組織を、どのような手法で攻撃したのかは公開情報から確認できません。KEV 掲載を根拠にそこまで推測することは避けるのが妥当です。

Progress の Bulletin は 7 月 31 日が最終更新日となっていますが、本文には悪用の報告を受けていない旨の記述が残っています。この記述が 6 月 4 日の公開時点のものなのか、7 月 31 日に改めて確認された内容なのかは、公開情報からは判断できません。ベンダーの記述と第三者の観測結果は、それぞれ観測範囲が異なる別の情報として扱うことを推奨します。

なお、KEV エントリーに設定された 2026 年 8 月 10 日という期限は、CISA の BOD 26-04 に基づくもので、対象は米国連邦政府の民間機関です。日本の一般企業に同じ期限が義務として適用されるわけではありません。ただし、悪用が確認された脆弱性であるという事実は、社内の優先度判断の材料として有効です。

NVD と Progress で異なる CVSS 評価の読み方

この脆弱性は、評価主体によって CVSS の値とベクターが異なります。2026 年 8 月時点で確認できる内容は次のとおりです。

評価元	CVSS v3.1 スコア	ベクター
NVD（NIST）	9.8	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Progress（CNA）	9.6	CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

差は主に Attack Vector（AV）と Scope（S）の評価にあります。NVD は AV:N（ネットワーク）、Progress は AV:A（隣接ネットワーク）として評価しています。なぜ評価が分かれたのかについて、各機関の公開情報に説明は見当たらないため、この記事では理由の推測は行いません。

実務上の注意点は、CVSS のベクターから自環境の到達条件を読み取らないことです。AV の値は評価主体の前提に基づくもので、個々の環境で WUI や API がどこから到達できるかを示すものではありません。対応方針の材料になるのは、自環境の WUI / REST API が実際にどのネットワークから到達できるかを個別に確認した結果です。確認の観点は後述します。

影響を受けるバージョンと対象製品を確認する

最初に確認するのは、自環境の LoadMaster が対象バージョンに該当するかどうかです。ここで注意が必要なのは、Progress の Bulletin、CVE レコード、NVD の CPE で対象範囲の表現が異なる点です。特に古いブランチを運用している場合、Bulletin の表だけを見ると判断を誤る可能性があります。

GA / LTSF の対象範囲と自機のバージョン確認方法

Progress の Bulletin で示されている対象と修正版は次のとおりです。

対象	対象バージョン	修正版
Progress Kemp LoadMaster（GA）	v7.2.63.1 およびそれ以前	v7.2.63.2
Progress Kemp LoadMaster（LTSF）	v7.2.54.17 およびそれ以前	v7.2.54.18
Progress ECS Connection Manager	v7.2.63.1 およびそれ以前	v7.2.63.2
Progress Connection Manager for ObjectScale	v7.2.63.1 およびそれ以前	v7.2.63.2

一方、CVE レコード（CNA: Progress Software）の affected では、GA 側が 7.2.60.0 以上 7.2.63.2 未満、LTSF 側が 7.2.45.12 以上 7.2.54.18 未満と、下限のあるバージョン範囲で記載されています。さらに NVD の CPE では 7.2.54.18 未満と 7.2.55.0 以上 7.2.63.2 未満の 2 つの範囲が設定されており、結果として 7.2.63.2 未満のほぼすべてが対象として扱われる形になっています。同じ脆弱性でも、参照する情報源によって「対象」と判定される範囲が変わるため、スキャナーの結果だけで対象外と判断しないことをおすすめします。

自機のバージョンは、WUI にログインして画面右上に表示されるバージョン文字列を確認するか、アプライアンスの起動後にコンソールに表示される情報を確認する方法が Bulletin に案内されています。HA 構成の場合は、Active 側と Standby 側の双方でバージョンを確認しておくと、後の更新計画が立てやすくなります。

なお、CVE レコードの affected には LoadMaster 以外に ECS Connection Manager、Object Scale Connection Manager、MOVEit WAF が含まれています。MOVEit WAF は NVD の CPE にも 2026 年 8 月 10 日の再分析で追加されました。LoadMaster 以外にこれらの製品を運用している場合は、あわせて確認しておくとよいと考えられます。

LTS 7.2.48.x を利用している場合の注意点

LTS ブランチ（7.2.48.x）の扱いは、公開情報のあいだで整理がついていません。整理すると次のようになります。

• CVE レコードの LTSF 側の範囲は 7.2.45.12 以上 7.2.54.18 未満であり、数値上は現行 LTS の 7.2.48.12 もこの範囲に含まれます
• NVD の CPE も 7.2.54.18 未満をまとめて対象としており、LTS のバージョンが含まれる読み方になります
• 一方、Progress の Bulletin および Vulnerabilities の Fixed Version には、LTS ブランチ向けの修正版が明記されていません

つまり、「LTS は対象外」と読める根拠は公開情報にありません。しかし、LTS ブランチ向けの修正版が示されていない以上、この記事の側で「LTSF または GA へ移行してください」と結論づけることもできません。ブランチの変更は、利用している機能、ライセンス、アップグレードパス、ハードウェアの対応状況によって判断が変わります。

LTS 7.2.48.x を運用している場合は、対応方法を Progress Support またはパートナーに確認することを推奨します。 確認の際は、稼働中のバージョン（7.2.48.x）を明示したうえで、CVE-2026-8037 に対する修正版の有無と推奨される対応を問い合わせる形が、回答を得やすいと考えられます。

管理プレーンの到達性確認と対応優先度の判断

対象バージョンであることが確認できたら、次は攻撃面の広さを確認します。LoadMaster はサービストラフィックを処理する面と、管理のための面を持つ機器であり、この 2 つを分けて考えることが対応優先度の判断につながります。

Virtual Service と管理プレーンを分けて考える

LoadMaster が扱う通信は、大きく次の 2 系統に分かれます。

Virtual Service（サービスプレーン）

クライアントからの要求を受け、Real Server へ振り分ける通信。インターネット向けサービスの前段に置かれることが多い

管理プレーン

WUI（管理用 Web インターフェース）、REST API、SSH、コンソール。設定変更や監視のために使用する

CVE-2026-8037 で問題になるのは管理プレーンの側です。LoadMaster がインターネット向けサービスの前段にあることと、脆弱な管理面へ攻撃者が到達できることは別の話です。 Virtual Service が公開されていても、管理プレーンが管理セグメントからしか到達できない構成であれば、攻撃面の広さは変わります。逆に、Virtual Service が内部向けであっても、管理プレーンの許可範囲が広ければ攻撃面は広くなります。

ただし、管理プレーンの到達範囲が狭いことは、脆弱性の有無を変えるものではありません。到達範囲の確認は、あくまで対応の優先順位と、更新までのあいだのリスクを見積もるための材料として扱うことをおすすめします。

Administrator Access と API 設定を確認する

管理アクセスの設定は、WUI の Certificates & Security > Remote Access で確認できます。CVE-2026-8037 の文脈で確認しておきたい項目は次のとおりです。

項目	確認する内容
Allow Web Administrative Access	管理用 Web アクセスの有効 / 無効
Using	管理 Web アクセスを許可するアドレス
Port（Web 管理アクセス）	管理 Web インターフェースのポート
Allow Multi Interface Access	複数インターフェースからの WUI アクセスの有効 / 無効
Allow Administrative WUI Access	インターフェースごとの WUI アクセス許可（System Configuration > eth）
Enable API Interface	RESTful API の有効 / 無効と API ポート

Allow Multi Interface Access を有効にしている場合は、各インターフェースの設定画面（System Configuration > eth）にある Allow Administrative WUI Access もあわせて確認する必要があります。両方が有効なインターフェースでは、そのインターフェースの IP アドレスおよび追加アドレスから WUI にアクセスできる構成になります。

Enable API Interface については、仕様上の注意点があります。API ポートを設定していない場合、API は WUI のポートでアクセスできる状態になります。つまり、API 用として別のポートを開けていないことは、API に到達できないことを意味しません。 管理 Web インターフェースに到達できるかどうかを起点に確認することをおすすめします。

参考: Configuration Guide Web User Interface (WUI) – Administrator Access（Progress）
“use a dedicated network interface for management traffic”
（管理トラフィックには専用のネットワークインターフェースを使用する）
https://docs.progress.com/bundle/loadmaster-configuration-guide-web-user-interface-wui-ltsf/page/Administrator-Access.html

ここで改めて確認しておきたいのは、API の設定状態から影響の有無を判断しないという点です。Progress は影響を受けるモジュールを API/UI としており、API を無効化した状態で影響を受けないことは公開情報から確認できません。

RESTful API は Progress のドキュメントでデフォルト無効と説明されており、業務で利用していないのであれば有効化しない、という運用は一般的なハードニングとして成り立ちます。ただし、これは攻撃面を狭める措置であって、CVE-2026-8037 に対する公式な暫定対策として示されているものではなく、アップデートの代替にもなりません。 管理アクセスの制限も同様に、更新までのあいだのリスクを下げる措置として位置づけることをおすすめします。

また、LoadMaster 側の設定だけで到達範囲が決まるわけではありません。上流のファイアウォールのポリシー、クラウド上で稼働している場合はセキュリティグループやネットワーク ACL の設定もあわせて確認することで、実際にどのネットワークから管理面へ到達できるかが把握できます。

対応優先度の判断フロー

ここまでの確認結果を、次の流れで整理すると判断しやすくなります。

1. LoadMaster（または ECS Connection Manager 等の関連製品）を利用しているか
2. 対象バージョンに該当するか（GA / LTSF / LTS のブランチと現行バージョンを確認）
3. Administrator Access と API の設定を確認する
4. どのインターフェース・どのネットワークから管理面へ到達できるかを、上流のフィルタリングも含めて確認する
5. 現在のブランチとアップグレードパスを確認する
6. バックアップを取得する
7. 現行のセキュリティ更新へアップグレードする
8. 更新後にバージョン、HA、Virtual Service、管理アクセスを確認する

1 〜 4 の結果から、対応の優先度は次のように整理できます。

管理面の到達範囲	対応の目安
インターネットから到達可能	最優先で対応を計画する。更新までのあいだ、到達範囲の縮小をあわせて検討する
業務セグメント等、広い内部ネットワークから到達可能	優先度を上げて対応を計画する。内部からの侵入を前提とした場合の影響を考慮する
管理セグメントからのみ到達可能	早期の更新を計画する。到達範囲が限定されていることは対応の要否ではなく、他の作業との優先順位を決める材料として扱う

いずれの場合も、更新そのものを見送る判断にはならない点に注意が必要です。KEV に登録されている脆弱性であり、到達範囲が狭いことは対応を不要にする理由にはなりません。 5 〜 8 の手順については、次のセクションで整理します。

アップグレード先の選定: 最低修正版と現行リリースの違い

対応方針を決めるうえで判断が分かれやすいのが、更新先バージョンの選定です。Security Bulletin に記載された修正版と、現時点で選択できる現行リリースは同じではありません。この差を把握しておかないと、更新作業を実施したあとで別のセキュリティ更新が未適用のまま残る状況になります。

7.2.63.2 / 7.2.54.18 は GA / LTSF で Progress が修正版として示した最初のリリース

Progress の Bulletin で修正版として示されているのは、GA が 7.2.63.2、LTSF が 7.2.54.18 です。いずれも 2026 年 6 月 4 日のリリースで、CVE-2026-8037 と CVE-2026-33691 の 2 件が修正対象として記載されています。

つまりこの 2 つのバージョンは、GA と LTSF の各ブランチについて、Progress が CVE-2026-8037 の修正版として示した最初のリリースという位置づけです。この記事の主題である CVE-2026-8037 だけを見れば、ここまで上げれば修正は入ります。前述のとおり、LTS ブランチについては修正版が示されていないため、この 2 つのバージョンを製品全体の最低ラインとして読むことはできません。

2026 年 8 月時点の現行リリースと CVE-2026-33691 の位置づけ

一方、Progress は 2026 年 7 月 27 日に GA 7.2.63.3 と LTSF 7.2.54.19 をリリースしています。この 2 つのリリースでは、CVE-2026-59686 から CVE-2026-59690 までの 5 件が修正対象として記載されています。さらに、Progress の Guidance for Selecting LoadMaster Releases では、本番環境向けの現行リリースが次のように示されています。

ブランチ	現行リリース	位置づけ
LTSF	7.2.54.19	特定の機能や修正を GA に求める場合を除き、本番環境向けとして推奨されるリリース
GA	7.2.63.3	LTSF にない新機能や修正を必要とする場合の推奨リリース
LTS	7.2.48.12	サポート対象として最も古い本番向けリリース。7.2.48.0 より前のレガシー版からのゲートウェイ

参考: Guidance for Selecting LoadMaster Releases – Recommended Production Releases（Progress）
“This is the recommended release for production deployments for all customers”
（これがすべてのお客様にとって本番環境向けに推奨されるリリースです）
https://docs.progress.com/bundle/guidance_for_selecting_loadmaster_releases/page/Recommended-Production-Releases.html

整理すると次のようになります。

区分	GA	LTSF
Progress が示した CVE-2026-8037 の修正版	7.2.63.2	7.2.54.18
2026 年 8 月時点の現行リリース	7.2.63.3	7.2.54.19

6 月の Bulletin の表だけを見て更新先を 7.2.63.2 / 7.2.54.18 に決めると、7 月に公開された 5 件のセキュリティ修正が未適用のまま残ります。 今から更新作業を計画するのであれば、Bulletin の修正版ではなく、Guidance for Selecting LoadMaster Releases に記載された現行リリースを起点に検討することをおすすめします。この情報は更新される前提のものであるため、作業の直前に公式ページで最新の記載を確認しておくと確実です。

CVE-2026-33691 についても、ここで整理しておきます。これは Bulletin で CVE-2026-8037 と同時に扱われている高深刻度の脆弱性で、OWASP Core Rule Set がファイル名に含まれる空白文字を正規化しないまま拡張子チェックの正規表現を適用していたため、細工したリクエストで検査を回避できるという内容です。修正は同じ 7.2.63.2 / 7.2.54.18 に含まれているため、CVE-2026-8037 への対応として更新すれば、あわせて解消されます。LoadMaster の WAF 機能を利用している場合は、CRS ベースの検査がどこまでを対象としているかを踏まえておくと判断しやすくなります。WAF の検知の考え方については、関連記事『WAF とは｜仕組みと種類、選定のポイント』もあわせて参照ください。

現在のブランチとアップグレードパスの確認

更新先を決めたら、現在のバージョンからそのバージョンへ直接上げられるかを確認します。LoadMaster にはゲートウェイリリースという考え方があり、特定のバージョンを経由しないと更新できない場合があります。

Progress の技術ノートによると、7.2.60 より前のバージョン（7.2.60 GA 未満、または 7.2.54.7 LTSF 未満）から 7.2.60 を超えるバージョンへ更新する場合は、先に 7.2.60 へ更新する手順が必要とされています。また、7.2.61.1 はダウングレード時のゲートウェイリリースとされており、7.2.61.1 より新しいバージョンから古いバージョンへ戻す場合は、いったん 7.2.61.1 を経由する形になります。

古いバージョンから更新する場合、あわせて確認しておきたい点が 3 つあります。1 つは、7.2.61 でレガシー版の WAF 機能が削除されている点です。7.2.61 より前のバージョンから更新すると、レガシー WAF を有効にしていた Virtual Service は既定値の OWASP WAF に変換されるとされているため、移行を前提に計画を立てる必要があります。2 つ目はハードウェアのブート方式で、7.2.54.5 以降、ハードウェア LoadMaster はそのハードウェアのブート方式に対応したイメージでのみ更新できるとされています。2023 年に登場した NG モデルは UEFI ブート、それ以前のモデルは BIOS ブートという区分です。3 つ目はアドオンパッケージで、ECS アドオンが導入されていない機器に ECS の更新イメージを適用するとライセンスが無効になるとされています。詳細は次のページで確認できます。

• Gateway Releases
• Update the Software

ブランチをまたぐ変更、たとえば GA から LTSF への移行は、この記事では推奨も非推奨も判断しません。 利用している機能、ライセンス、アップグレードパス、ハードウェアの対応状況によって適切な選択が変わるためです。前述のとおり LTS 7.2.48.x を運用している場合は、対応方法を Progress Support またはパートナーに確認することを推奨します。

更新手順と適用後の確認

ここからは、実際の更新作業と適用後の確認について整理します。手順はいずれも Progress の公式ドキュメントで確認できる範囲に限定しています。環境ごとに構成が異なるため、作業前に対象バージョンのリリースノートと技術ノートを確認しておくことをおすすめします。

バックアップの取得

更新前に取得しておく内容は、大きく 3 つに分かれます。

1. システム構成のバックアップ

WUI の System Configuration > System Administration > Backup/Restore で Create Backup File をクリックすると、システムの既定値と各 Virtual Service の設定を含むバックアップファイルがダウンロードされます。HA ペアの場合、このバックアップはどちらか一方のユニットから取得すれば足りるとされています。なお、LoadMaster のアカウント情報はバックアップに含まれません

2. 証明書と秘密鍵のバックアップ

Certificates & Security > Backup/Restore Certs から取得します。パスフレーズを設定する形式で、パスフレーズがないとバックアップファイルを開けないため、保管方法を決めたうえで実施します

3. 使用中の Cipher Set の控え

公式の更新手順にも独立した項目として記載されています。カスタムの Cipher Set を作成している環境では、内容を控えておくと復旧時に役立ちます

バージョンの確認は Active 側と Standby 側の双方で行い、バックアップは上記の 3 種類を分けて整理しておくと、切り戻しの判断がしやすくなります。

Update Software での適用と HA 構成での注意点

適用の流れは次のとおりです。

1. Progress の Download Hub からファームウェアをダウンロードし、zip を展開する
2. 展開後の 7.x.x.RELEASE.PATCH-64-MULTICORE ファイルを、WUI の System Configuration > System Administration > Update Software でアップロードする
3. Update Machine をクリックすると、ファイルの検証が実行される
4. 検証完了後に OK をクリックし、インストールを実行する
5. インストール後、新しいバージョンを有効にするために再起動する

検証ファイルの扱いは、System Configuration > Miscellaneous Options > WUI Settings の Update Verification Options で設定されています。FIPS モードが有効な環境ではこの項目が表示されず、更新時に検証ファイルのアップロードが求められる仕様とされています。

HA 構成の場合は、Progress の High Availability (HA) Feature Description に手順が示されています。作業前に System Configuration > HA Parameters の Switch to Preferred Server が No Preferred Host になっていることを確認し、以降の操作は共有 IP アドレスから実施します。

1. Passive 側のユニット（ここでは B とします）を先に更新する
2. 更新が完了したら B を再起動する
3. B が復帰したら、Active 側のユニット（ここでは A とします）を更新する
4. 更新が完了したら A を再起動する。これにより B が Active になる
5. B がトラフィックを処理していることを確認する

参考: Feature Description High Availability (HA) – Performing a Firmware Update on HA Pairs（Progress）
“We recommend updating the passive unit first and then updating the active unit”
（Passive 側のユニットを先に更新し、その後 Active 側のユニットを更新することを推奨します）
https://docs.progress.com/bundle/loadmaster-feature-description-high-availability-ha-ga/page/Performing-a-Firmware-Update-on-HA-Pairs.html

この方法ではフェイルオーバーが 1 回で済むとされていますが、切り替えに伴う通信への影響を考慮し、業務時間外の実施か、メンテナンスウィンドウの確保を検討することをおすすめします。この手順では作業後に元の Passive 側が Active として動作し続けるため、運用上の役割を戻したい場合は、あらためて切り替えの計画が必要です。クラスター構成の場合は、共有 IP アドレスから Update Cluster を使用してクラスター全体を更新する方法が用意されています。

更新後に確認する項目と、侵害有無を考慮する理由

再起動が完了したら、次の項目を確認します。

バージョン

WUI 右上のバージョン文字列が目的のバージョンになっているか。HA 構成では両系を確認する

HA ステータス

WUI ヘッダーに表示される 2 つのインジケーターが、いずれも正常な状態を示しているか。片系が Active、もう片系が Standby になっているか

Virtual Service と Real Server

各サービスの状態と、ヘルスチェックの結果が更新前と同じ状態に戻っているか

管理アクセスの設定

Certificates & Security > Remote Access の設定値が意図したとおりに維持されているか。API を利用している場合は、API の有効状態とポートも確認する

そのうえで、パッチ適用だけで対応を完了とせず、既存の侵害の有無も検討することをおすすめします。 ここで扱う情報は、情報源によって内容が異なるため、分けて整理します。

• Progress: Bulletin には、現時点で既知の侵害の指標（Indicators of Compromise）はないと記載されています
• eSentire: 2026 年 6 月 30 日公開の Advisory で、悪用試行の送信元として観測した IP アドレス 3 件を公開しています

また、CISA の KEV エントリーに記載された対応内容は、ベンダーの指示に沿った緩和策の適用に加えて、フォレンジックのトリアージに関するガイダンスを参照する形になっています。これは米国連邦政府の民間機関を対象とした要求ですが、認証なしで任意コマンド実行につながる脆弱性が悪用された可能性を考えるとき、パッチ適用のみで完結させないという考え方自体は、一般企業でも参考になります。

LoadMaster 側で確認できる材料としては、Audit LogFile があります。これは System Configuration > Logging Options > System Log Files から参照でき、WUI または API を通じてユーザーが実行した操作が記録されます。ただし、この機能が動作するのは Session Management が有効な場合に限られるとされています。Audit LogFile は管理操作の確認材料にはなりますが、このログだけで CVE-2026-8037 の悪用有無を判定できるわけではありません。 未認証の状態で成立する脆弱性であるため、ユーザー操作として記録されない可能性を考慮する必要があります。

公式に検知シグネチャや詳細な IoC が提示されていない状況では、確認できる範囲も限られます。この記事の側で存在しないログや検知条件を提示することはしません。現実的に着手できるのは、Audit LogFile や認証ログに想定外の記録がないかの確認、設定変更履歴の確認、外部から管理面へ到達できる経路が存在していなかったかの確認といった、一般的な観点までです。悪用の可能性が疑われる場合は、Progress Technical Support への連絡と、社内のインシデント対応プロセスに沿った調査を検討することになります。

まとめ

CVE-2026-8037 は、Progress Kemp LoadMaster の API における OS コマンドインジェクションで、公開から約 2 か月を経て CISA の KEV Catalog に追加されました。対応の判断で分かれやすいのは、対象バージョンの読み方と、更新先を最低修正版にするか現行リリースにするかという点です。管理プレーンの到達範囲は、対応の要否ではなく優先順位を決める材料として扱うことになります。

• GA v7.2.63.1 以前と LTSF v7.2.54.17 以前が Bulletin 上の対象範囲
• 6 月 29 日以降に観測されたのは悪用試行、8 月 7 日に KEV へ追加
• NVD の 9.8 と Progress の 9.6 で Attack Vector の評価が相違
• 修正の最低ラインは 7.2.63.2 / 7.2.54.18、現行は 7.2.63.3 / 7.2.54.19
• LTS 7.2.48.x は修正版が未提示のため Progress Support へ確認
• 管理プレーンの到達範囲は優先順位を決めるための判断材料
• IoC は情報源ごとに異なり、IP の不一致では侵害なしと断定できない

以上、最後までお読みいただきありがとうございました。