Oracle過去最大の四半期パッチ1,449件・1,235 CVE(2026年7月CPU)とIPAのJava注意喚起｜「パッチは誰の仕事か」を契約書で確認したことはありますか

結論：過去最大のパッチが出た。しかし本当の問題は「自社では誰も適用しない構造」にある

Oracleは2026年7月21日(米国時間)、四半期定例のセキュリティパッチ「Critical Patch Update(CPU)」の2026年7月版を公開しました(Oracle Critical Patch Update Advisory - July 2026)。今回は32製品ファミリーに対して1,449件のセキュリティパッチ、1,235件のCVE(脆弱性識別番号)を修正する、過去最大規模のCPUです。セキュリティ企業Tenableの集計では、CVSS 9.0以上のクリティカル区分のパッチが261件(全体の18%、該当CVEは228件)含まれます。製品別ではE-Business Suiteが410件(28.3%)、Fusion Middlewareが355件(24.5%)と、業務システムの中核製品に修正が集中しました。中でもPeopleSoft PeopleToolsの未認証リモートコード実行(RCE)脆弱性CVE-2026-35278(CVSS 9.8)は、既に100社を超える組織への侵害に使われたと報じられています(この件数は米メディア等の二次報道ベースであり、Oracleの一次発表ではありません。国内の被害状況も公表されていません)。

さらに翌7月22日、IPA(情報処理推進機構)が「Oracle Javaの脆弱性対策について」を公表しました。対象として挙げられているのはJava SE 26.0.1 / 25.0.3 / 21.0.11 / 17.0.19 / 11.0.31 / 8 Update 491(および8u491-perf)で、早期のアップデート適用を呼びかけるとともに、2019年4月16日以降のリリースからJavaのライセンス条件が変更されている点に触れ、商用利用時の条件確認を促しています。つまり今回は「パッチを当てる」だけでなく「そもそも自社のJavaは合法的に更新できる状態か」まで問われる注意喚起です。

経営判断としての結論を先に述べます。1,235件のCVEを自社ですべて評価し適用することは、情シスが0〜1名の中堅・中小企業には現実的に不可能です。だからこそ必要なのは、(1)外部公開・悪用実績・認証不要の3条件で機械的に優先順位を付けるルール、(2)「保守ベンダーに任せているつもり」が契約書のどこで裏切られるかの確認、(3)どの端末・どの業務パッケージに古いJavaが埋まっているかの台帳整備、の3点です。パッチそのものより、「パッチは誰の仕事か」が契約と体制で決まっていないことが、日本の中堅企業の最大のリスクです。

この記事を読むべき人

• Oracle製品(EBS、PeopleSoft、WebLogic、Oracle Database、Java)を業務システムのどこかで使っている、または「使っているかどうか分からない」企業の経営者・役員
• システムの運用保守を外部ベンダーに委託しており、「セキュリティパッチも当ててくれているはず」と思っている決裁者
• 会計・勤怠・帳票などのパッケージ製品を長年使い続けており、同梱ソフトウェアの更新状況を確認したことがない情シス兼任担当者
• 2019年以降、Javaのライセンス条件を確認しないまま社内で使い続けている可能性がある企業
• 四半期ごとに大量に出るパッチ情報を「全部は無理」と感じ、優先順位の付け方を決めたい実務責任者

事実関係：2026年7月CPUとIPA注意喚起で何が公表されたか

過去最大規模となった7月CPUの全体像

CPUはOracleが1月・4月・7月・10月の年4回、定例で公開するセキュリティパッチの一括リリースです。今回の2026年7月版の規模を、Tenableの集計(Oracle July 2026 Critical Patch Update Addresses 1235 CVEs)に基づいて整理します。

製品別の内訳では、E-Business Suite(EBS)が410件で全体の28.3%、Fusion Middlewareが355件で24.5%を占めます。この2つだけで全体の半分を超えており、ERP・ミドルウェアという「止められない業務システム」の層に修正が集中したことが今回の特徴です。Java SEに対するパッチも19件含まれています。

CVE-2026-35278：PeopleSoftの未認証RCE

今回のCPUで特に注目されているのが、PeopleSoft PeopleToolsの脆弱性CVE-2026-35278です。CVSSスコアは9.8で、認証なしにネットワーク経由でコードを実行できる(未認証RCE)と評価されています。米メディアでは、攻撃者がこのCVE-2026-35278を初期侵入の足がかりとし、後述する6月のCVE-2026-35273と組み合わせた攻撃チェーンによって、300を超えるサーバー・100社超の組織が侵害されたと報じられています(TechTimes「PeopleSoft Exploit Behind 100+ Breaches Gets Patched in Oracle's Record July CPU」)。この「100社超」という数字は二次報道ベースです。一方で、セキュリティベンダー各社も本脆弱性の悪用キャンペーンを報告しており、「パッチ公開前から実際に使われていた脆弱性が今回の修正に含まれる」という点は、優先順位判断の上で重い事実です。

なお、PeopleSoftを巡っては2026年6月にも別の脆弱性CVE-2026-35273が悪用され、米CISAのKEVカタログに掲載される事態がありました。その経緯と初動対応は既報のOracle PeopleSoft脆弱性CVE-2026-35273の解説記事で扱っています。本稿はその続報ではなく、7月CPU全体の優先順位付けと、Java注意喚起、そして「パッチ適用は誰の契約責任か」という分界点の問題を扱います。

IPAのJava注意喚起：バージョンとライセンスの二重チェック

IPAは7月22日、今回のCPUに含まれるJava SEの脆弱性について注意喚起を公表しました。対象はJava SE 26.0.1 / 25.0.3 / 21.0.11 / 17.0.19 / 11.0.31 / 8 Update 491(および8u491-perf)で、悪用された場合はアプリケーションの異常終了やシステムの侵害につながるおそれがあるとして、修正版への早期アップデートを呼びかけています。

注目すべきは、IPAが技術的な更新だけでなくライセンスにも言及している点です。Oracleは2019年4月16日以降のリリースからJavaのライセンス条件を変更しており、商用利用には条件確認が必要です。IPA自身は「ライセンスの詳細には回答できない」として、Oracleの公式情報の確認やベンダーからの適切な有償サポートの取得を促しています。「無償で使えるはず」という2019年以前の認識のまま業務利用を続けている企業にとって、今回の注意喚起は脆弱性とライセンスの両方を棚卸しするきっかけになります。

GXOの視点①：「保守ベンダーに任せているつもり」の落とし穴

今回のような大規模パッチが出たとき、多くの経営者はこう考えます。「うちはシステムの保守をベンダーに頼んでいるから、対応してくれているはずだ」。この認識が、実際の契約内容とずれているケースが構造的に多いのです。

理由は保守契約の成り立ちにあります。一般的なシステム保守契約の中心は「障害時の対応」「問い合わせ対応」「軽微な修正」であり、セキュリティパッチの適用は(a)契約範囲外、(b)都度見積もりの別作業、(c)「情報提供まで」が範囲でありパッチ適用の実施と検証は発注者責任、のいずれかになっていることが珍しくありません。ベンダー側が怠慢なのではなく、パッチ適用には検証環境での動作確認・業務停止調整・切り戻し準備というコストがかかるため、月額固定の保守費に含めると採算が合わない、という合理的な理由があります。結果として、どちらも悪意なく「誰もパッチを当てていない」状態が何年も続きます。

自社の保守契約を確認する際は、次の点を見てください。

• 作業範囲(スコープ)条項：「保守業務」の定義に「セキュリティパッチの適用」が明示されているか。「OS・ミドルウェアの更新」が除外事項に入っていないか
• 情報提供と適用の区別：「脆弱性情報の提供」までが範囲で、「適用作業」は別料金・別発注になっていないか
• SLA・対応期限：クリティカル脆弱性の公表から何営業日以内に評価・報告・適用するかの期限が定められているか。定めがなければ、事実上「ベンダーの手が空いたとき」になります
• 検証環境の有無と費用負担：パッチ適用前の動作検証をどの環境で誰の費用で行うか。検証環境がない場合、ベンダーは本番直当てのリスクを避けて適用自体を提案しなくなりがちです
• EOL製品の扱い：サポート終了バージョンを使い続けている場合の免責条項。ここに該当していると、そもそもパッチが提供されず、保守契約自体が空洞化しています

この確認は法務的な作業に見えますが、実際は経営判断の問題です。パッチ適用が範囲外だと分かった場合、選択肢は「範囲に含めて保守費を増額する」「都度発注のルールと予算枠を決める」「適用を内製化する」の3つしかなく、どれもコスト配分の意思決定だからです。

GXOの視点②：1,235件は全部当てられない——優先順位付けの実務フロー

四半期ごとに1,000件超のCVEが公表される時代に、「全部評価して全部当てる」は目標として誤っています。限られた体制で守るための現実的なフローは、次の3条件の掛け算で機械的に絞り込むことです。

第1条件：外部公開されているか。 インターネットから直接アクセスできるシステム(公開Webサーバー、VPN装置、外部公開されたERPポータルなど)が最優先です。社内ネットワークからしか届かないシステムの脆弱性は、深刻度が同じでも優先度を1段下げられます。今回のCVE-2026-35278が危険なのは、PeopleSoftの管理系エンドポイントが外部に露出したまま運用されている組織が実在するためです。まず「自社のOracle製品のうち、外から届くものはどれか」を特定してください。

第2条件：既に悪用されているか。 悪用実績の有無は、米CISAが公開しているKEV(Known Exploited Vulnerabilities)カタログで確認できます。CVE番号でカタログを検索し、掲載されていれば「攻撃者が現に使っている」ことを意味するため、理論上の深刻度に関係なく最優先で対応します。KEVの確認は無料で、専門知識も不要です。四半期CPUの公開日と、その後数週間のKEV追加を定点観測するだけで、優先順位の精度は大きく上がります。

第3条件:認証なしで攻撃できるか。 OracleのアドバイザリやCVE情報には「認証なしでリモートから悪用可能か(Remotely exploitable without authentication)」が記載されます。認証不要の脆弱性は、ID・パスワードの防壁が意味を持たないため、外部公開×認証不要の組み合わせは即応対象です。

この3条件で「外部公開 × 悪用実績あり × 認証不要」に該当するものを72時間以内、「外部公開 × 認証不要(悪用未確認)」を2週間以内、それ以外を次回定期メンテナンス時、のように期限を分けるのが実務的な着地です。重要なのは、この振り分けルールを事前に文書化し、保守ベンダーとの間で「どの区分は誰が何日以内に動くか」を合意しておくことです。ルールがなければ、大規模CPUのたびに「どうしますか」「検討します」の往復で数週間が溶けます。

なお、パッチが即時に当てられない場合の代替策(ワークアラウンド)も選択肢に含めてください。今回のPeopleSoft脆弱性のように管理インターフェースが攻撃面になるケースでは、当該エンドポイントへのアクセスを信頼できるIPアドレスに制限するだけでも、暴露は大きく減らせます。「パッチ適用かゼロか」の二択で考えると、業務停止調整がボトルネックになって何も進まなくなります。

GXOの視点③：「Java台帳がない」問題——古いJREはどこに埋まっているか

IPAの注意喚起に対して「うちはJavaで開発していないから関係ない」と判断するのは早計です。Javaは自社が意識して導入したものだけでなく、購入したパッケージ製品に同梱される形で社内に存在していることが非常に多いためです。典型的には次のような場所です。

• 帳票ツール・レポート生成ソフト:実行環境として特定バージョンのJREを同梱し、製品側の都合で更新が固定されているケース
• 勤怠管理・給与計算・会計パッケージ:クライアント端末にインストールされる接続モジュールが古いJavaを要求するケース
• 複合機・スキャナの管理コンソール、社内設備の管理画面:ブラウザ経由の管理ツールが古いJava実行環境を前提にしているケース
• 銀行・官公庁向けの電子申請クライアント:指定バージョン以外で動作保証されないため、意図的に古いまま残されているケース
• 数年前に開発を委託した社内システム:納品時のJREのまま、更新責任が発注者・受託者のどちらにあるか決まっていないケース

棚卸しの手順はシンプルです。第一段階として、資産管理ツールまたはOS標準の機能で、全端末・全サーバーからJava実行環境のインストール有無とバージョンを収集します。第二段階として、検出された各Javaについて「何の業務アプリが使っているか」「そのアプリの提供元はどこか」「更新すると動作保証はどうなるか」を紐付けます。この第二段階が本丸です。バージョン一覧を作るだけなら数日でできますが、「このJREを更新したら勤怠システムが動かなくなるのではないか」という業務影響の紐付けができていないと、結局誰も更新に踏み切れません。

台帳が完成すると、対応は3分類に整理できます。(1)自社判断で更新できるもの(即時更新)、(2)パッケージ提供元の対応待ちのもの(提供元へ更新予定を問い合わせ、回答を記録)、(3)更新不能で古いまま残るもの(ネットワーク分離・利用端末の限定などの封じ込め)。(3)が多い場合、それは個別のパッチ問題ではなく、レガシーシステムの刷新を経営課題として扱うべきサインです。古いJavaが更新できない構造は、その上に載っている業務システム自体が塩漬けになっていることの症状だからです。

GXOの視点④：Javaライセンス——「無償のはず」のまま商用利用していないか

IPAが今回わざわざライセンスに言及したのは、更新の呼びかけとライセンス確認が表裏一体だからです。2019年4月のライセンス変更以降、Oracle JavaはリリースやバージョンによってNFTC(無償利用可能な条件付きライセンス)とOTN(商用利用に有償サブスクリプションが必要なライセンス)が入り組んでおり、「どのバージョンをどこから入手してどう使っているか」でコンプライアンス状態が変わります。ここで煽るつもりはありません。整理すべき論点は3つだけです。

第一に、現状把握。前節のJava台帳に「入手元(Oracle公式か、OpenJDKディストリビューションか)」「ライセンス種別」の列を追加してください。台帳なしにライセンスの適否は判断できません。第二に、選択肢の整理。Oracle Javaの有償サブスクリプションを契約する、無償で商用利用できるOpenJDK系ディストリビューション(複数の企業が長期サポート付きで提供しています)へ移行する、アプリ側の対応バージョンを確認した上で段階的に統一する、という選択肢を並べ、台帳の分類ごとに割り当てます。第三に、問い合わせの記録。パッケージ製品に同梱されたJavaのライセンス責任は、原則として同梱した製品提供元との契約で決まります。「同梱Javaのライセンスと更新はどちらの責任か」を提供元に文書で確認し、回答を残してください。将来の監査や紛争で効くのは、この記録です。

ライセンスの詳細判断には専門性が要るため、本稿では個別の適否に踏み込みません。重要なのは、脆弱性対応(セキュリティ)とライセンス対応(コンプライアンス)を同じ台帳の上で一度に進めれば、調査コストが二重にならないという実務上の要点です。

GXOの視点⑤：経営者への問い——「パッチは誰の仕事か」を契約書で確認したことがあるか

ここまでの論点を経営の言葉に戻します。今回の7月CPUのような定例イベントは、技術部門の作業ではなく、「自社のリスク対応が誰の責任として設計されているか」を確認する監査の機会です。取締役会や経営会議で確認すべき問いは5つです。

1. 自社で使っているOracle製品(データベース、ERP、ミドルウェア、Java)の一覧は存在するか。「分からない」なら、それ自体が最初の課題です
2. それぞれについて、セキュリティパッチの適用責任は契約書のどの条項で誰に割り当てられているか
3. クリティカル脆弱性の公表から適用までの目標期限(SLA)は合意されているか
4. 直近1年間で、実際にパッチが適用された記録はあるか。「契約上は範囲内だが実績ゼロ」は、範囲外と同じです
5. パッチを当てられない・当てていないシステムのリスクを、経営として受容する意思決定をしたか。それとも誰も決めないまま放置されているか

この5問に答えられない状態は、ベンダーの問題でも担当者の問題でもなく、責任分界の設計がされていないという経営の問題です。逆に言えば、契約と台帳とルールという文書を3点そろえるだけで、大規模CPUのたびに慌てる状態からは脱却できます。1,235件という数字に圧倒される必要はありません。自社に関係する数十件を特定し、その中の即応対象数件を期限内に処理できる体制こそが、現実的なゴールです。

よくある質問(FAQ)

Q1. Oracle製品を使っているか分からない場合、何から始めればよいですか。

A. 業務システムの一覧(なければ主要業務ごとの利用システムの聞き取り)を作り、各システムの提供元ベンダーに「データベース・ミドルウェア・Java実行環境として何を使っているか」を文書で照会するのが最短です。並行して、資産管理ツールで端末・サーバーのインストール済みソフトウェアを機械的に収集します。自社開発した覚えがなくても、パッケージ製品の内部でOracle DatabaseやJavaが使われていることは珍しくありません。

Q2. 今回の1,235件のCVEをすべて確認する必要がありますか。

A. ありません。まず自社で使っている製品ファミリーに絞り込み、その中で「外部公開されているか」「悪用実績があるか(CISAのKEVカタログで確認)」「認証なしで攻撃可能か」の3条件で優先順位を付けます。この絞り込みで、即応が必要な対象は通常ごく少数になります。全件評価を目標にすると、かえって何も進まなくなります。

Q3. 保守ベンダーから今回のCPUについて何の連絡もありません。問題でしょうか。

A. 契約内容によります。脆弱性情報の提供や適用提案が保守範囲に含まれていなければ、連絡がないのは契約通りの動きです。まず契約書の作業範囲条項を確認し、含まれていないなら「情報提供と適用を範囲に含める増額」「クリティカル時のみ都度発注するルール化」のどちらかを協議してください。連絡がないこと自体より、連絡がなくても誰も気づかない体制の方が問題です。

Q4. 「100社超が侵害された」というのは確定情報ですか。

A. いいえ。CVE-2026-35278(PeopleSoft PeopleToolsの未認証RCE、CVSS 9.8)が100社超の侵害に使われたという件数は、米メディア等の二次報道ベースであり、Oracleの一次発表による確定情報ではありません。国内の被害状況も公表されていません。ただし、セキュリティベンダー各社が本脆弱性の悪用を報告しており、「悪用実績のある脆弱性の修正が今回のCPUに含まれる」こと自体は優先対応の根拠として扱うべきです。

Q5. Javaを更新すると業務アプリが動かなくなるのが怖くて放置しています。どうすべきですか。

A. 「更新か放置か」の二択にしないことが重要です。まず台帳でそのJavaを使うアプリと提供元を特定し、提供元に対応バージョンを確認します。即時更新できない場合は、該当端末のネットワーク分離や利用限定などの封じ込めで暴露を減らしつつ、更新可否の回答期限を切って追いかけます。更新不能なまま残る場合は、そのアプリ自体の刷新を中期課題に載せるのが筋です。

Q6. Javaのライセンス違反になっていないか不安です。すぐ確認できますか。

A. 即答は難しく、台帳が前提になります。バージョン・入手元・用途(商用か)の3点を整理すれば、有償サブスクリプションが必要なケースか、無償利用可能な条件に収まるケースか、OpenJDK系への移行で解消できるケースかの当たりが付きます。IPAも公式情報の確認と適切な有償サポートの取得を促しています。パッケージ同梱のJavaについては、製品提供元にライセンス責任の所在を文書で確認してください。

GXOに相談すべきタイミング

今回のような大規模CPUへの対応は、パッチを当てる技術力よりも、「自社の資産と契約の現状を第三者の目で棚卸しできるか」で成否が分かれます。次のような状態に心当たりがあれば、外部の専門家を入れる価値があります。

• 自社のどこにOracle製品や古いJavaがあるか、一覧で答えられない。外部から攻撃可能な箇所が特定できていない——この状態なら、まず現状の暴露を客観的に把握するセキュリティ診断が出発点になります。パッチ優先順位の前提となる「外から何が見えているか」を事実で確認できます
• 保守契約を確認したら、パッチ適用が範囲外だった。しかし社内に適用判断や優先順位付けを担える人がいない——四半期CPUやKEV追加のたびに評価・助言を受けられるセキュリティ顧問(リテイナー)のような継続支援が、情シス0〜1名の体制には現実的です
• Java台帳を作ってみたら、更新不能な古いシステムが想像以上に多かった——それは個別のパッチ問題ではなく構造問題です。レガシーシステムの刷新として、更新できる基盤への移行を中期計画に載せることをおすすめします
• PeopleSoftを含むERPを利用しており、6月からの一連の悪用報道への対応状況を整理したい——初動の考え方は既報のCVE-2026-35273解説も参考にしてください

「うちの契約はどうなっているのか」「何から棚卸しすべきか」という段階のご相談でも構いません。状況の整理からで良ければ、お問い合わせからご連絡ください。パッチは四半期ごとに必ずまた来ます。次の10月CPUを、慌てずに迎えられる体制を今から作りましょう。

参考文献

• Oracle「Oracle Critical Patch Update Advisory - July 2026」
• IPA「Oracle Java の脆弱性対策について(2026年7月)」
• Tenable「Oracle July 2026 Critical Patch Update Addresses 1235 CVEs」
• TechTimes「PeopleSoft Exploit Behind 100+ Breaches Gets Patched in Oracle's Record July CPU」
• CISA「Known Exploited Vulnerabilities Catalog」