SAPが2026年6月のパッチデーで15件の新規セキュリティノートを公開しました。見出しではNetWeaverとCommerce Cloudが並びますが、日本国内のオンプレミス／プライベートクラウド運用者にとって本題は、認証不要・回避策なし・カーネル更新必須という条件を備えたABAPコアの脆弱性です。SAML認証、旧AS Java、npm供給網汚染の続報と合わせて整理します。
SAPは2026年6月9日のセキュリティパッチデーで、15件の新規セキュリティノートを公開しました。このうちCriticalは4件です。中間リリース・更新の5件を含めた計20件で見ると、内訳はHotNews 6件、High 3件、Medium 9件、Low 2件となります（HotNews 6件は更新分を含むベースで、新規分のCriticalは4件です）。
報道の見出しではNetWeaverとCommerce Cloudが並びました。ただし、日本国内のオンプレミス／プライベートクラウドのSAPユーザにとって、今回まず見るべきはCommerce Cloud系よりも、ABAPコア、SAML認証、旧AS Javaスタックに関係するCritical Noteです。理由は単純です。これらはS/4HANAや周辺連携基盤の足元に近く、しかも「回避策なし」「カーネル更新必須」といった、運用者が先送りしにくい条件を含むからです。
本記事では、「認証不要・回避策なし・カーネル更新必須」という、オンプレ運用者が最も嫌がる条件を備えたCritical Noteを軸に、SAML認証・旧AS Java・npm供給網汚染の続報まで整理します。
クラウド製品と違い、オンプレ・プライベート環境では修正の適用を自分たちで計画・実行しなければなりません。SAP環境は、オンプレのS/4HANA、RISE、BTP、周辺連携基盤が混在する構成へと複雑化しており、相互依存するコンポーネントが多いため、パッチ適用は時間とリソースを要します。その結果、重要な修正が見落とされたり、適用が後回しになったりするリスクが高まります。
とりわけ今月のHotNewsは「カーネル更新が必要」「回避策が存在しない」ものを含み、"当てたくても簡単には当てられない"という現実を突きつけます。バージョンアップで直るとはいえ、そのバージョンアップ自体がオンプレでは重いのです。
最も注意すべきはAS ABAPのメモリ破損です。ABAPシステムが30年以上使い続けてきた独自プロトコルであるRFCにおいて、リクエストの不適切な検証がメモリ破損と深刻な二次被害を招くものです。
BleepingComputerは、攻撃者が認証なしで、脆弱なエンドポイントに細工したRFCリクエストを送信し、不適切なカーネル検証を悪用してメモリ破損を引き起こせると報じています。
決定的なのは対処の重さです。修正にはカーネル更新が必要で、回避策（workaround）は存在せず、相応の計画が求められます。RFCは社内システム間で広く開いている前提のプロトコルであり、「認証不要で踏める」「カーネル更新はおいそれと当てられない」という、まさに知らぬ間にやられるリスクとパッチ適用の難しさを同時に体現しています。今月のCVSS最高点は別のNote（後述）ですが、運用上の嫌らしさではこれが筆頭です。
今月の最高スコアは、AS ABAP／ABAP PlatformのSAML認証におけるXML署名ラッピングです。通常権限を持つ認証済み攻撃者が正規の署名済みメッセージを取得し、識別情報を改ざんした署名付きXMLを検証側に送ると、それが受理されてしまいます。結果として機密データへの不正アクセスや、通常運用の妨害につながります。
SAML認証の無効化で一時的に緩和できるとされますが、恒久対処はあくまで該当ABAPシステムへの修正適用です。SSOを止める選択は現実的でないことが多く、なりすましが静かに通過する点が怖いところです。
NetWeaver AS Java（Webコンテナ）のディレクトリトラバーサルです。悪意あるHTTPログオン要求が、本来意図された範囲外のファイルシステムへアクセスし処理できてしまうもので、機密情報へのアクセスやサービス妨害（DoS）につながり得ます。回避策はなくパッチ適用のみが対処となります。旧AS Javaスタックを残している環境に効く話です。
ABAPコアとは別系統ですが、見逃せないのが SAP Cloud Application Programming Model（CAP）と MTA Build Tool に関連する悪意ある npm パッケージ混入です。先月 HotNews として公開された Note 3747787 は、新たな悪性 npm パッケージが特定されたことを受けて更新されています。npm パッケージを利用している場合は、ノートの最新情報に沿って必ず再確認が必要です。
これは、当コミュニティで以前取り上げた「Mini Shai-Hulud SAP CAP」の延長線上にあります。SAP開発であっても、攻撃面はABAPやBasisだけではありません。拡張開発、CI/CD、開発端末、依存パッケージまで含めたサプライチェーンが、引き続き攻撃対象になっています。
こうした領域で効いてくるのが、依存パッケージをインストールする前に悪性挙動を止める仕組みです。たとえば Aikido Safe Chain は OSS で無料、npx @aikidosec/safe-chain install の1コマンドで導入でき、既存の npm install / npx / yarn / pnpm のワークフローを変えずに割り込みます。新規公開から48時間のウィンドウを設け、その間に新規・汚染パッケージのインストールをブロックする設計で、Mini Shai-Hulud のような公開直後の汚染にも有効です。
スコアは中程度ですが、データ連携を行う環境では次の3件も確認しておく価値があります。
OData/SOAP経由でSAPと連携する統合基盤を持つ組織は、自分たちの呼び出し経路に関係しないか一度確認しておくとよいでしょう。
今回のパッチデーで重要なのは、「危ないNoteが出た」こと自体ではなく、自社環境がどれに該当するかを早く切り分けることです。特にオンプレ／プライベートクラウド／RISE環境では、SAP任せにできない領域が残るため、次の観点で棚卸しするのが現実的です。
なお、確認方法は環境によって分かれます。オンプレ／プライベートクラウドのABAP基盤・カーネル・RFC・AS Javaは、SAP GUI、NWA、OS側の確認が中心です。一方、S/4HANA CloudやFiori中心の運用では、Communication Arrangement、Communication System、API連携、Fiori Launchpad／SSO設定など、アプリ側から見える範囲を確認することになります。
つまり、Fioriだけでカーネル脆弱性の該当可否を完全に判定することはできません。Fioriで分かるのは「どの外部連携・API・通信設定を使っているか」であり、最終的なカーネル／Note適用状況はBasisまたは運用ベンダーに確認する必要があります。以下はまず基盤側（SAP GUI／NWA／OS）の確認、続いてFiori／S/4HANA Cloud側の確認の順にまとめます。
CVE-2026-27671はRFCに関係するため、まず確認すべきは「対象カーネルか」「RFCがどこに開いているか」です。SAP GUIまたは管理画面で、各ABAPシステムのカーネルバージョンを確認します。
System > Status > Other Kernel Info
またはOS側で、SAPカーネルのバージョンを確認します。
disp+work -version
あわせて、RFC接続の棚卸しも必要です。SAP GUIでは以下を確認します。
SM59 : RFC Destination
SMGW : Gateway monitor
RZ10/RZ11 : gw/acl_mode, secinfo, reginfo 関連パラメータ
見るべきポイントは、外部システム・ジョブサーバ・周辺アプリからRFCが広く開いていないか、不要なDestinationが残っていないか、Gateway ACLが有効かどうかです。今回のように「認証不要で踏まれ得る」「カーネル更新が必要」「回避策なし」という条件が揃う場合、RFCの露出範囲を狭めることも重要です。
CVE-2026-44748はSAML認証に関係します。まず、自社のABAPシステムでSAML 2.0を使っているか確認します。
SAML2 : SAML 2.0 Configuration
SICF : ICFサービス確認
STRUST : 証明書・Trust設定
IdP連携、SSO、Fiori Launchpad、外部ポータル連携がある環境では、SAMLを使っている可能性があります。暫定回避としてSAML無効化が挙げられていても、実運用ではSSO停止が難しいことが多いため、恒久対処として該当ABAPシステムへの修正適用を優先して確認すべきです。
Fiori LaunchpadをSSOで利用している場合、裏側でSAML連携を使っている可能性があります。Fioriの画面から見える範囲では、利用者・ロール・通信設定の確認に留まるため、SAML2の有効化状況、IdPメタデータ、証明書、Service Provider設定は、Basis担当に SAML2、SICF、STRUST で確認してもらうのが安全です。
CVE-2026-40128はNetWeaver AS Javaに関係します。現在S/4HANA中心の環境でも、古いPI/PO、Portal、Solution Manager、周辺連携基盤などでJavaスタックが残っているケースがあります。確認対象の例です。
NWA : NetWeaver Administrator
http(s)://<host>:<port>/nwa
http(s)://<host>:<port>/irj/portal
http(s)://<host>:<port>/startPage
OSや構成管理上では、以下のようなプロセス・ディレクトリも手掛かりになります。
ps -ef | grep -i jlaunch
ps -ef | grep -i sapjvm
find /usr/sap -maxdepth 3 -type d | grep -Ei 'JC|J[0-9][0-9]|j2ee'
旧AS Javaは「もう使っていないはず」と思われがちですが、実際には連携基盤や管理系で残っていることがあります。今回のNoteは回避策なしのため、存在確認だけでも早めに行う価値があります。
Note 3747787は、SAP CAPやMTA Build Toolに関連するnpm供給網汚染の続報です。ABAP本体ではなく、Side-by-Side開発、BTP開発、CAPアプリ、CI/CDに関係します。まず、リポジトリ内でCAP/MTA関連の依存があるか確認します。
grep -R '"@sap/cds"' .
grep -R '"mbt"' .
grep -R '"@sap"' package.json package-lock.json npm-shrinkwrap.json 2>/dev/null
複数リポジトリをまとめて確認するなら、次のように検索します。
find . -name "package.json" -o -name "package-lock.json" -o -name "npm-shrinkwrap.json" | xargs grep -Ei "@sap/cds|mbt|mta|@sap"
npm依存の実体も確認します。
npm ls --all
npm audit
npm view <package-name> version
ただし、今回のような供給網汚染では「npm auditに出るかどうか」だけでは不十分です。悪性パッケージが短時間で差し替えられる場合や、正規パッケージに見える名前で混入する場合があるため、SAP Noteの最新情報と照合し、lockfileに含まれるバージョンまで確認する必要があります。CI/CDで自動的に npm install や mbt build を実行している場合は、ビルドログも確認してください。
grep -R "npm install" .github .gitlab-ci.yml Jenkinsfile azure-pipelines.yml 2>/dev/null
grep -R "mbt build" .github .gitlab-ci.yml Jenkinsfile azure-pipelines.yml 2>/dev/null
開発者PC、CIランナー、BTP向けビルド環境のどこで依存パッケージが解決されているかを把握することが重要です。前述のとおり、インストール前に止める Safe Chain（無料・1コマンド導入）をこの経路に挟んでおくと、検出と防御を同時に底上げできます。
中位Noteであっても、統合基盤を持つ組織では影響が出ることがあります。特にS/4HANA、ODP、SAP Gateway、OData V4を使っている場合は、どのシステムがどのAPIを呼んでいるかを確認します。SAP側では次のようなトランザクションが手掛かりになります。
/IWFND/MAINT_SERVICE : ODataサービス確認
/IWFND/ERROR_LOG : Gatewayエラーログ
/IWBEP/ERROR_LOG : Backend Gatewayエラーログ
SRT_MONI : SOAPメッセージ監視
SM59 : RFC Destination
OSやリバースプロキシ側では、OData/SOAP/RFCに関係するアクセスログを確認します。
grep -Ei "/sap/opu/odata|/sap/bc/srt|/sap/bc/soap" /var/log/nginx/access.log
grep -Ei "/sap/opu/odata|/sap/bc/srt|/sap/bc/soap" /var/log/httpd/access_log
ここで重要なのは、NoteのCVSSだけで判断しないことです。CVSSが中程度でも、外部連携・データ複製・周辺システム連携に使っている場合、業務影響は大きくなります。
Fiori中心の環境では、カーネルやAS Javaの状態そのものは見えませんが、外部連携やAPI利用の有無は確認できます。特に次のアプリ・設定を確認します。
Communication Arrangements
Communication Systems
Communication Users
Maintain Business Users
Maintain Business Roles
Display Communication Scenarios
見るべきポイントは、外部システムとの通信がどのCommunication Arrangementで定義されているか、どのCommunication Userが使われているか、OData／SOAP／RFC相当の連携がどの業務シナリオで有効になっているかです。
S/4HANA Cloud Public Editionでは、オンプレのようにOSへログインして disp+work -version を確認したり、カーネルを自分で更新したりする運用ではありません。そのため、SAP側の適用状況・対象Note・通信設定の影響範囲を確認することが中心になります。
一方、Private Edition／RISE／オンプレ環境では、Fioriで連携設定を見られても、カーネル、RFC Gateway、SAML2、AS Javaの実体確認はBasis作業になります。Fioriで外部連携の入口を棚卸しし、SAP GUI／NWA／OS側で基盤の該当有無を確認する、という分担で考えるのが現実的です。
最後に整理しておきたいのが「誰が当てるか」です。S/4HANA Cloud（パブリックエディション）のようなマネージド製品ではSAP側が修正を適用しますが、オンプレ／プライベートクラウド／RISE環境では運用者自身が計画して当てる必要があります。
今回の3つのCritical Note（CVE-2026-27671／CVE-2026-44748／CVE-2026-40128）はいずれもコア基盤に直撃する内容であり、適用の難しさを理由に先送りすれば、その分だけ露出期間が延びます。適時のパッチ適用は、既知の脆弱性への露出を減らす最も効果的な手段の一つです。
そして念のため——Destination Service等でSAP認証を守っていても、それは認証・接続管理のレイヤーです。npm依存やビルド環境に入り込む供給網汚染は別レイヤーの問題であり、Safe Chainのようなガードレールはそこで効いてきます。SAP認証、API連携、依存パッケージの防御を分けて考えることが重要です。
Aikido Community Japan
公開日: 2026/6/9
最終更新: 2026/6/9
セキュリティの最新情報をお届けします。