脆弱性対応の議論は「何件出たか」に集まりがちだが、事業のリスクを決めているのは件数ではない。修正版が出てから、自社が当てるまでの日数である。
米CISAは2026年8月7日、Progress LoadMasterのコマンドインジェクション脆弱性 CVE-2026-8037 をKnown Exploited Vulnerabilities（KEV）カタログへ追加した。是正期限は2026年8月10日である。
ここで注目したいのは、修正版が公開されたのはKEV収載の2か月以上前だったという点である。Progressが公開しているリリースノートによれば、同社は2026年6月4日にこの脆弱性に関する情報を公開し、修正版を提供している。そして、セキュリティ事業者eSentireの報告では、2026年6月29日から悪用の試行が観測され始めたとされる。
時系列を並べるとこうなる。
横にスクロールして確認できます
| 日付 | 出来事 |
|---|---|
| 2026年6月4日 | ベンダーが情報と修正版を公開（Progress公式リリースノート） |
| 2026年6月29日 | 悪用の試行が観測され始める（セキュリティ事業者の報告による） |
| 2026年8月7日 | CISAがKEVカタログへ追加 |
| 2026年8月10日 | KEVの是正期限 |
**修正版の公開から悪用試行の観測まで25日。KEV収載までは64日。**その間、修正版を適用していない機器は、公開された情報をもとに攻撃を受け得る状態にあった。
⚠️ **ただし「未適用の期間＝無防備な期間」ではない。**該当する機能を有効にしているか、管理インタフェースが外部から到達できるか、接続元を絞っているか、監視が入っているかによって、実際のリスクは大きく変わる。未適用期間は「脆弱な状態が継続し得る期間」であり、実効的な防御状況は別途評価する必要がある。
本稿は、この「修正版が出てから当てるまでの期間」を自社で測り、短くするための整理である。
この記事を読むべき人
- ロードバランサ、VPN装置、ファイアウォールなど、インターネットに面した機器を運用している会社
- 機器の管理インタフェースやAPIを、社外から使えるようにしている会社
- 脆弱性が公表されたとき、自社が何日で適用できているか測ったことがない会社
- 「ベンダーから緊急の連絡が来たら対応する」という運用になっている会社
- 情報システムの担当が少人数で、機器の棚卸しが数年更新されていない会社
EMERGENCY RESPONSE
この脆弱性、貴社システムは影響を受けますか？
影響範囲の一次評価を無料で実施。致命的脆弱性は24時間以内にアラートし、パッチ適用・恒久対応まで伴走します。
何が起きるのか
CISAのKEVカタログでの登録名は「Progress LoadMaster Command Injection Vulnerability」である。分類はOSコマンドインジェクション（CWE-77）にあたる。
報道および技術解析の記事によれば、入力値を処理する内部の関数が利用者から与えられた文字列を適切に扱えず、複数のAPIエンドポイントを通じて、認証を経ていない攻撃者が任意のシェルコマンドを注入できる状態になっていたとされる。第三者のセキュリティ事業者による評価では、CVSS基本値は9.6とされている。
**これらの技術的な詳細と評価値は、ベンダー以外の情報源による記載を含む。**対象となるバージョンと修正版の番号は、Progress の公開情報と突き合わせて確認すること。本稿の記述をバージョン判断の材料にしてはならない。
実務上押さえるべき点は次の3つである。
**点1：認証が不要である。**攻撃に有効な資格情報が要らない。管理者のパスワードを強固にしていても防げない。
**点2：管理用のAPIが到達できることが前提になる。**逆に言えば、管理インタフェースをインターネットから到達できないようにしていれば、攻撃面は大きく狭まる。
**点3：ロードバランサは通信の経路上にある。**Webサービスへのアクセスがこの機器を経由している場合、機器を取られることは、その先の通信に影響が及び得ることを意味する。
「適用リードタイム」を1つの数字にする
多くの会社が脆弱性対応の状況を説明できないのは、指標を持っていないからである。最も単純で、最も実態を表す指標が「適用リードタイム」である。
定義は単純にできる。ベンダーが修正版を公開した日から、自社の対象機器すべてに適用が完了した日までの日数。
これを直近の数件について測ると、自社の実力が数字で出る。測り方は次のとおりである。
手順1：直近3〜5件の、自社に該当した脆弱性を挙げる。該当したものが思い出せない場合、それ自体が結果である。「該当を判定する仕組みがない」ということになる。
**手順2：それぞれについて、ベンダーの公開日を調べる。**アドバイザリに記載がある。
**手順3：自社が適用を完了した日を調べる。**作業記録、変更管理の記録、あるいは機器のバージョン更新履歴から拾う。記録がなければ、これも結果である。
**手順4：日数を出し、最も長かったものを見る。**平均ではなく最大値を見る。リスクを決めているのは、最も遅れた1台だからである。
今回のLoadMasterの件で言えば、6月4日を起点として、自社が何日で当て終わったか。8月10日を過ぎてまだ当たっていない機器があるなら、リードタイムは67日以上ということになる。
この数字は、経営会議で説明できる形になっている。「今月は790件の脆弱性が出ました」より、「当社の適用リードタイムは最大67日です。目標を14日に置くには、これとこれが必要です」のほうが、判断につながる。
リードタイムが長くなる箇所は、だいたい決まっている
測った結果が長かった場合、どこで時間を失っているかを分解する。実務上、詰まるのは次の4か所である。
**箇所1：公開に気づくまで。**ベンダーの告知を誰も見ていない。メーリングリストに登録されていない、あるいは登録先が退職者のアドレスになっている。ここは最も安く直せる。
**箇所2：自社に該当するか判定するまで。**機器の一覧とバージョンが分からず、ベンダーや委託先に問い合わせて回答を待つ。一覧があれば数分、なければ数日かかる。
**箇所3：作業の承認を得るまで。**本番機器の停止を伴うため、業務部門との調整が必要になる。調整のルールが決まっていないと、毎回ゼロから交渉することになる。
**箇所4：作業を実施するまで。**作業できる人の空きを待つ。委託している場合は見積もりと発注の手続きが挟まる。
**この4か所のうち、箇所1と箇所2は、体制を変えなくても短縮できる。**告知の受け取り先を整理し、機器の一覧を作るだけである。箇所3と箇所4は体制と契約の話になるため、時間と費用がかかる。先に箇所1と2を潰すのが順序として合理的である。
管理インタフェースの露出を確認する
今回のように、管理用のAPIやWeb画面が攻撃の入口になる案件は繰り返し起きている。そして、これは適用リードタイムとは別の軸で対処できる。
確認すべきは次の3点である。
確認1：機器の管理画面・APIが、インターネットから到達できるか。運用の都合で開けていることがある。開けている場合、その必要性が現在も残っているかを確認したい。「以前は必要だったが、今は使っていない」という経路は珍しくない。
**確認2：到達できる場合、接続元を限定できるか。**特定のIPアドレス範囲や、社内ネットワーク経由に限定できれば、攻撃面は大幅に狭まる。脆弱性そのものは残るが、到達できる相手がいなくなる。
**確認3：管理インタフェースへのアクセスログを見ているか。**認証を必要としない攻撃は、ログイン失敗の記録には残らない。API呼び出しの記録を見ているかが分かれ目になる。
**この3点は、脆弱性が出るたびに対応するのではなく、平時に1回整理すれば、以後の複数の案件に効く。**個別対応より投資効率が高い。
境界機器の棚卸しは、1枚の表で足りる
大がかりな資産管理システムを導入する前に、次の項目を持つ1枚の表を作れば、実務の大半は回る。
- 機器の名称と設置場所
- 製品名とバージョン
- インターネットから到達できるか（はい／いいえ）
- 管理インタフェースが外部から到達できるか（はい／いいえ）
- この機器が停止すると、何が止まるか
- 保守の委託先と、契約上の対応範囲
- ベンダーの告知を受け取っている担当者
**7列である。**機器の台数が10台程度の会社であれば、半日で埋まる。
**この表があると、脆弱性の情報が流れてきたときの判定が、問い合わせなしで完結する。**それが箇所1と箇所2の短縮に直結する。逆にこの表がない状態では、どれだけ情報収集を強化しても、リードタイムは縮まらない。
この種の機器が棚卸しから漏れる3つの理由
ロードバランサやADC（アプリケーション配信コントローラ）は、サーバやPCに比べて棚卸しから漏れやすい。理由は明確である。
理由1：導入時に設定したら、以後ほとんど触らない。 正常に動いている限り、誰も画面を開かない。**触らない機器は、担当者の記憶からも、日常の運用手順からも消える。**サーバであれば定期的なログイン機会があるが、この種の機器にはそれがない。
理由2：担当の境界に落ちる。 サーバ担当は「ネットワーク機器だから自分の範囲ではない」と考え、ネットワーク担当は「アプリケーションの前段だからサーバ側だろう」と考える。両者の間に落ちた機器は、どちらの一覧にも載らない。
理由3：導入した会社と、現在の保守委託先が違うことがある。 システム構築時に導入され、その後の保守は別の会社に移っている場合、引き継ぎの一覧に載っていなければ、現在の委託先も存在を把握していない。
**この3つに当てはまる機器は、脆弱性情報が出ても誰も反応しない。**そして、そういう機器ほどインターネットに面している。**棚卸しをするなら、まず「担当が曖昧な機器」から探すのが効率的である。**サーバやPCは既にどこかの一覧に載っていることが多い。
探し方として実効性が高いのは、保守費用の支払い記録から逆算する方法である。機器が現役で保守契約下にあれば、費用が発生している。**経理の記録には、情報システム部門の台帳にない機器が現れることがある。**逆に、支払いが止まっているのに稼働している機器が見つかることもある。**この場合、脆弱性の修正版が提供される対象ですらない可能性がある。**サポートが終了した機器がインターネットに面したまま動いている状態は、個別の脆弱性より優先度の高い課題になる。
よくある質問
Q. 自社はLoadMasterを使っていない。関係ないか。 A. 個別の製品としては関係ない。**ただし「修正版が出てから当てるまでの間、脆弱な状態が継続し得る」という構造は、どの製品でも同じである。**その期間に実際どれだけ危ないかは、到達性や暫定的な統制の有無で変わるため別途評価が必要になる。本稿の主眼は製品ではなく、その期間を測る方法にある。
Q. 修正版が出てすぐ当てるのは、業務影響があって難しい。 A. その通りで、即日適用が常に正しいわけではない。**重要なのは、遅らせることを意図的に選んでいるかどうかである。**遅らせると決めたなら、その間の代替措置（接続元の限定など）を取る。気づかないまま遅れているのとは意味が違う。
Q. KEVに載ってから対応すれば十分ではないか。 A. KEV収載は「既に悪用されている」という判定であり、**悪用が始まってから収載されるまでには時間差がある。**今回の件では、悪用の観測開始が6月29日、KEV収載が8月7日と報じられている。KEVを待つ運用は、その差の期間を「悪用が始まっているのに社内では優先度が上がらない」状態で過ごすことを意味する。
Q. ベンダーの告知はどう受け取ればよいか。 A. 多くのベンダーがセキュリティ情報の通知登録を用意している。**まず、自社が使っている主要な機器・ソフトについて、誰のアドレスで登録されているかを確認したい。**退職者のアドレスや、廃止された共有アドレスになっている例は実際にある。
Q. 適用リードタイムの目標値は、どのくらいに置くべきか。 A. 一律の正解はない。**現実的なのは、まず実測してから、その数字を半分にすることを当面の目標に置く方法である。**最初から「7日以内」といった外部の基準を置くと、達成不能に見えて誰も動かなくなる。
Q. 機器の一覧を作りたいが、誰も全体像を知らない。 A. **ネットワーク図と、ファイアウォールの設定、そして請求書の3つから拾えることが多い。**特に請求書は、契約が続いている機器を漏れなく示すため、棚卸しの起点として有効である。
Q. 管理インタフェースを閉じると、外部の保守業者が作業できなくなる。 A. その場合、**接続元を保守業者のIPアドレスに限定する、あるいは作業時のみ一時的に開ける運用に切り替える方法がある。**完全に開けたままにする以外の選択肢が取れるかを、委託先と協議したい。
Q. 7列の表は、どこで管理すればよいか。 A. 表計算ソフトで十分である。**専用ツールの選定に時間をかけるより、まず埋めることを優先したい。**運用が定着してから、台数の増加に応じて仕組みを検討すればよい。
境界機器の棚卸しとパッチ運用を整理したいとき
適用リードタイムが長い会社に共通しているのは、対応能力が低いことではなく、そもそも自社に該当するかを判定できる材料が手元にないことである。判定に時間を使っている間に、日数が積み上がっていく。
インターネットに面した機器の棚卸しと、管理インタフェースの露出確認から着手したい場合は、境界機器の棚卸しと露出確認で現状の確認から対応している。脆弱性情報の受け取りと判定を継続的に外部へ持たせたい場合は、脆弱性情報の受け取りと判定の代行が該当する。
保守を任せている会社の対応範囲や緊急時の体制が、自社の抱えるリスクに釣り合っているか。ここを社外の目で点検したい場合は保守体制がリスクに見合うか確認するで受け付けている。ネットワーク構成そのものを見直す段階であれば、ネットワーク構成の見直しで設計から扱っている。
なお、回避策がなく是正期限も本日という条件が重なった案件としては、回避策がないCisco ASA/FTDの案件がある。そちらのほうが差し迫っている。何を先に当てるかの判断軸は期限付きパッチ運用を標準化する方法を、ネットワーク機器の選定基準はL2スイッチ選定ガイドで別途扱っている。本稿は、適用リードタイムの測定と短縮に絞っている。
参照した情報
- CISA Known Exploited Vulnerabilities Catalog（JSON配信）: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
- CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- Progress LoadMaster リリースノート（Security Updates）: https://docs.progress.com/bundle/release-notes_loadmaster-7-2-63-2/page/Security-Updates.html
- eSentire Security Advisory（Progress Kemp LoadMaster）: https://www.esentire.com/security-advisories/progress-kemp-loadmaster-vulnerability-targeted-cve-2026-8037
CVE-2026-8037のKEVカタログへの追加日（2026年8月7日）、是正期限（2026年8月10日）、登録名「Progress LoadMaster Command Injection Vulnerability」、および対象製品は、CISAのKEVカタログJSON配信（カタログバージョン2026.08.11）に収載された内容による。
ベンダーによる情報と修正版の公開日（2026年6月4日）、および修正版が提供されている旨は、上記Progressのリリースノートの記載に基づく。
**一方、悪用の試行が観測され始めた時期（2026年6月29日）、CVSS基本値9.6、および脆弱性の技術的な原因は、いずれもセキュリティ事業者eSentireによる観測・評価に基づくものであり、Progress自身が公表した値ではない。**本稿ではこれらを同社の観測・評価として扱っており、ベンダー一次情報としては未確認である。適用すべきバージョンと手順については、Progress の公開情報を直接あたること。
適用リードタイムという指標、遅延が生じる4か所の分解、管理インタフェースの3つの確認項目、および7列の棚卸し表は、GXOが運用設計の観点で整理した内容であって、ProgressやCISAが示した基準ではない。攻撃コードの内容、観測されている悪用の規模、および個々の環境が影響を受けるかの判断については、本稿では取り上げていない。KEVカタログが示す期日は米国連邦政府機関を対象とした指定であり、日本の企業に法的効力が及ぶものではない。
