基幹業務システムで高いシェアを持つSAPが、2026年8月11日の定例セキュリティパッチデーで31件のセキュリティノートを公開した。最上位の脆弱性は、深刻度を数値で示すCVSS（共通脆弱性評価システム）で最高値の10.0に達する。さらにJPCERT/CCは8月19日付のWeekly Reportで、「今回修正された一部の脆弱性の悪用試行を確認している」と伝えている。ERPやEC基盤は止められない業務の中心にあり、パッチ適用の日程調整に時間がかかりがちだ。今回はその「待てる範囲」が例月より狭い。
最高値10.0はCommerce CloudのData Hub Adapter
SAPが公開した8月分の一覧で最も深刻なのは、セキュリティノート3771065（CVE-2026-58231）だ。SAP Commerce CloudのData Hub Adapterにおける不適切な認可（Improper Authorization）に分類され、CVSSスコアは上限の10.0となっている。影響を受けるのはCOM_CLOUD 2211およびCOM_CLOUD 2211-JDK21である。
Data Hub Adapterは、SAP Commerce Cloudと外部システムとの間でデータの交換や取り込みを行うためのコンポーネントだ。報道によれば、この欠陥は認証されていない攻撃者がネットワーク経由で任意のコードを実行し得るものとされ、修正版は2211.55または2211-jdk21.17以降とされている。CVSSが10.0に達するということは、認証不要・利用者操作不要で、機密性・完全性・可用性のすべてに深刻な影響が及ぶ想定だと理解してよい。
パッチ公開から3日で攻撃観測、翌日にはPoCも
今回のパッチが例月と違うのは、公開後の展開の速さである。
JPCERT/CCはWeekly Report 2026-08-19号の【7】「複数のSAP製品に脆弱性」で、脅威情報を扱うDefusedによる悪用試行の確認を紹介している。報道によれば、Defusedのハニーポットが悪用試行を観測し始めたのは8月14日で、SAPのパッチ公開からわずか3日後だった。その時点で公開されたPoC（概念実証）コードや実環境での悪用報告はなかったとされるが、翌8月15日にはPoCが入手可能になったと報じられている。
つまり、パッチの公開そのものが攻撃者に対して脆弱性の存在を知らせる結果になったとみられる。SAPのような大規模製品では、パッチ内容の差分から脆弱点を割り出す解析（パッチ・ディフィング）が攻撃側でも日常的に行われている。「様子を見てから適用する」という判断が、そのまま露出時間の延長になる構図である。
製造業のMII、NetWeaver ABAPにも重大な欠陥
Critical判定は他にもある。
セキュリティノート3765948（CVE-2026-44772、CVSS 9.9）と3758900（CVE-2026-44758、同9.1）は、いずれもSAP Manufacturing Integration and Intelligence（MII）のコードインジェクション脆弱性だ。MIIは製造現場の設備・実行系システムと基幹業務をつなぐ製品であり、OT（制御技術）側とIT側の境界に位置する。ここが侵害された場合の影響範囲は、情報漏えいだけでは終わらない可能性がある。
セキュリティノート3714806（CVE-2026-34265、CVSS 9.8）は、SAP NetWeaver Application Server ABAPおよびABAP Platformのメモリ破損（Memory Corruption）に関するものだ。影響を受けるカーネルのバージョンは7.22系から9.19系まで非常に幅広く、長期運用されている環境ほど該当しやすい。報道によると、これはDIAGプロトコルの解析処理に起因し、認証されていない攻撃者がメモリ破損を引き起こせるものとされる。
このほか、High判定ではSAP ABAP Developer Toolsの権限昇格（3772411、CVE-2026-58243、CVSS 8.8）、公開クラウド構成のSAP Commerce Cloud＋NGINXにおけるバッファオーバーフロー（3773203、CVE-2026-42945、同8.1）、SAP BusinessObjects BI Platformの認証情報漏えい（3756565、CVE-2026-66763、同7.9）などが並ぶ。
基幹システムは「止められない」からこそ手順が要る
ERPやEC基盤へのパッチ適用が遅れる理由は、技術的な難しさだけでなく、組織的な段取りの問題であるケースも少なくない。業務影響の確認、独自開発したアドオン（追加機能）分の回帰テスト、停止時間の調整——どれも一朝一夕には縮まらない。だからこそ、危機のたびに手順を組み立てるのではなく、平時に「緊急時はこの短縮ルートで通す」という合意を作っておく価値がある。
今回のケースで現実的な進め方を挙げるなら、まずSAP Commerce Cloudを使っているかどうかの確認が最優先になる。使っている場合はCOM_CLOUD 2211系のバージョンを特定し、修正版への更新計画を最短で立てる。並行して、Data Hub Adapterのエンドポイントがインターネットから到達可能な状態になっていないかを点検し、不要な公開があれば先に閉じる。パッチ適用までの時間を稼ぐのは、こうしたネットワーク側の措置になる。
そして、悪用試行がすでに観測されている以上、「これから守る」だけでなく「すでに入られていないか」を見る視点も要る。認可不備を突く攻撃は、正規の通信経路を使うため境界での検知が難しく、侵入後にサーバー上で何が実行されたかを追える仕組み——エンドポイントやサーバーの挙動ログ——が残っているかどうかが分かれ目になる。パッチ適用の計画と、侵害有無の確認は、どちらか一方では足りない。
同じ手口に、自社は備えられていますか？