基幹システムの認証を丸ごと迂回｜SAP6月月例のSAML脆弱性CVSS9.9と「塩漬け基幹」のパッチ滞留リスク

結論：SSO構成のSAP環境はSAML修正（CVE-2026-44748）を最優先。そして「当てられない基幹」を抱えている事実そのものを経営課題として扱う

SAPは2026年6月9日のセキュリティパッチデーで、新規セキュリティノート15件（別途、既存ノートの更新5件）を公開した。SAPセキュリティ専門ベンダーSecurityBridgeの集計によれば、最重要区分の HotNewsは6件 に上る。

筆頭は CVE-2026-44748（CVSS 9.9）——SAP NetWeaver AS ABAPおよびABAP PlatformのSAML認証における XML署名ラッピング の脆弱性だ（セキュリティノート3746332）。署名検証の不備（CWE-347）により、通常権限の認証済みユーザーが、正規に署名されたSAMLメッセージのXML構造を改ざんして検証側に受け入れさせ、別人の身元情報で認証を通し得る。シングルサインオン（SSO）やフェデレーション認証を前提に組んだSAP環境では、基幹システムの認証境界そのものが迂回される ことを意味する。影響はSAP_BASISの702から919という広範なバージョンに及び、パッチ対象の裾野が極めて広い。

そしてここに、日本企業特有の構造問題が重なる。SAPを長年使う企業ほど、アドオン・カスタマイズが積み重なり、停止調整と検証のコストが高く、「月例パッチを当てない運用」が常態化 している。脆弱性は毎月公表されるのに適用は年単位で滞留する——この差分こそが、基幹システムの実質的なリスクである。

押さえるべき1点：CVSS9.9という数字より重いのは、「当てたくても当てられない」構造だ。今回のSAML修正に自社が何日で対応できるかを測ってみてほしい。それが自社の基幹システムのリスク許容量の実測値である。

2026年6月パッチデーの全体像：HotNews 6件

オンプレのNetWeaver系（ABAP／Java）とクラウド系（Commerce Cloud）の双方に最重要級が並んだ月であり、「うちはECCだから関係ない」「うちはクラウドだから関係ない」のどちらの逃げ道もない。

SAML署名ラッピングの何が怖いか

SAMLベースのSSOは「署名された認証情報は改ざんできない」という前提の上に成り立つ。XML署名ラッピングはその前提を突く古典的かつ強力な攻撃手法で、署名済みXMLの構造を組み替えることで、署名検証は通るのに中身の身元情報は別人 という状態を作り出す。

CVE-2026-44748の場合、攻撃者に必要なのは通常権限のアカウントだけだ。基幹システムにおいて「一般ユーザーから他者へのなりすまし」が成立すれば、権限昇格、機微データへのアクセス、業務処理の改ざんへと連鎖し得る。会計・購買・人事データを握る基幹システムでこれが起きることの意味は、情シスではなく経営層が評価すべき水準にある。

ワークアラウンドとしてSAML認証の無効化が挙げられているが、SSOを全社展開済みの企業にとって現実的でないことが多い。結局、正攻法のパッチ適用をどれだけ速く回せるか に帰着する。

なぜ「塩漬け基幹」はパッチが滞留するのか

SAP環境のパッチ滞留には、典型的な4つの理由がある。

• カスタマイズの重さ：長年のアドオンが絡み、更新の影響範囲を誰も断言できない
• 停止調整のコスト：月次決算・受発注が依存しており、停止枠の確保に経営調整が要る
• 検証環境の不在・陳腐化：本番同等の検証環境がなく、「当ててみないと分からない」
• 2027年問題による投資凍結：SAP ECC 6.0の保守期限を控え「どうせ移行するから今は触らない」という判断で、現行環境への投資が止まる

とりわけ4つ目は危険だ。移行プロジェクトは年単位でかかる。その間も基幹システムは毎月公表される脆弱性に晒され続ける。「移行するから塩漬け」は、最もリスクの高い期間に最も無防備でいる という選択にほかならない。保守期限と移行コストの全体像はSAP ECC 2027年問題｜S/4HANA移行の費用と進め方で詳しく解説している（本記事の主軸はあくまで月例パッチ運用であり、移行判断はそちらを参照してほしい）。

月例パッチ運用の現実解チェックリスト

SAPに限らず基幹システムの月例対応は、次の6点を仕組みにできているかで決まる。

1. 月例の定例化：SAPパッチデー（毎月第2火曜）を情シスのカレンダーに固定し、当月ノートのトリアージを48時間以内に終える体制があるか。
2. HotNews即応SLA：CVSS 9台のHotNewsについて「何営業日以内に適用判断・何営業日以内に適用」を社内SLAとして定めているか。
3. 構成の把握：自社のSAP_BASISバージョン、SAML/SSOの使用有無、AS Javaの稼働有無を即答できるか（今回のトリアージはこれが分からないと始まらない）。
4. 検証環境の維持：本番に準じた検証環境で、緊急パッチを短期に検証できるか。
5. 停止枠の事前合意：緊急時に使える計画停止枠を、業務部門・経営と年間で合意してあるか。
6. 滞留の可視化：「公表からの経過日数×深刻度」で未適用ノートを一覧化し、経営に定期報告しているか。

チェックの勘所：6が最重要だ。パッチ滞留は現場の怠慢ではなく構造の産物である以上、滞留量を経営が見える状態にしない限り、停止枠も検証環境も予算がつかない。

なお、同じ週にAdobe ColdFusionでも「優先度1」級の修正が出ており、レガシー資産全般の処遇判断という同型の論点をAdobe月例とレガシー放置の代償で扱っている。Windows側の史上最多月例は2026年6月Microsoft月例の解説を参照してほしい。

よくある質問（FAQ）

Q. SAMLによるSSOを使っていなければ、今月は対応不要か？ A. CVE-2026-44748の影響は受けにくいが、今月のHotNewsは6件あり、AS ABAPのメモリ破損（CVE-2026-27671）はカーネル更新を要する別系統の修正だ。Commerce CloudやAS Javaを使っていれば対象はさらに広がる。「SAMLを使っていない」ことの確認自体も、構成把握ができて初めて言える。

Q. すぐに適用できない場合の暫定策は？ A. SAMLについてはワークアラウンドとして無効化が示されているが、SSO運用中の企業には現実的でないことが多い。その場合は、適用までの期間を区切ったうえで、認証ログの監視強化（通常と異なるアサーション・なりすましの兆候）、管理者権限の棚卸し、ネットワーク到達制御で露出を下げる。暫定策は「期限付き」でなければ恒久放置になる。

Q. ECC 6.0で2027年問題を抱えている。移行までパッチは最小限でよいか？ A. 逆である。移行完了までの数年間こそ、現行環境が攻撃に晒され続ける期間であり、パッチ運用を止める判断は移行プロジェクト自体を危険に晒す。移行計画とパッチ運用は別予算・別判断として並走させるべきだ。

いつGXOに相談すべきか

• 基幹システムのパッチ滞留が年単位 になっており、どこから手を付けるべきか整理できていない
• SAML/SSOを含む基幹まわりの認証設計・構成を第三者の目で点検したい
• 2027年問題を見据えて、塩漬け基幹の刷新とパッチ運用の両立 を計画したい

GXOは、セキュリティ診断による基幹システムの構成・露出・滞留パッチの棚卸しと、DX・基幹システム刷新支援による「当てられる基幹」への再設計・移行計画づくりを支援している。パッチが当てられない構造は、放置するほど選択肢が減る。月例のたびに冷や汗をかく状態から抜け出したい企業は相談してほしい。→ 基幹システムのパッチ運用・刷新相談はこちら

関連記事

• SAP ECC 2027年問題｜S/4HANA移行の費用と進め方
• 中堅製造業のERP比較｜NetSuite・SAP B1・Dynamics
• CVSS満点10.0が2件｜Adobe月例とレガシー放置の代償
• Windows月例パッチ史上最多200件｜BitLocker迂回ゼロデイ2件

参考資料

• SAP「SAP Security Patch Day – June 2026」 https://support.sap.com/en/my-support/knowledge-base/security-notes-news/june-2026.html
• SecurityBridge「SAP Security Patch Day – June 2026」（SAPセキュリティ専門ベンダーによる解説・二次情報） https://securitybridge.com/blog/sap-security-patch-day-june-2026/
• SOCRadar「SAP Security Patch Day June 2026: Critical CVE-2026-44748 SAML Flaw」（二次情報） https://socradar.io/blog/sap-security-patch-day-june-2026-cve-2026-44748/

本記事は2026年6月11日時点の公開情報をもとに作成。HotNews件数等の集計は情報源により分類が異なる場合がある。各ノートの適用要否・対象バージョンは、SAPサポートポータルの一次情報（要ログイン）で必ず確認すること。