Oracle CSPU（Critical Security Patch Update）は、1・4・7・10月の四半期CPU（Critical Patch Update）の間を埋める、月次のセキュリティ更新です。2026年5月28日に始まり、Javaでは8月18日に8u503・21.0.12.1・25.0.4.1といった4桁目の付いた版が初めて出ました。一方で9月のCSPUにOracle JDK本体の版はなく、毎月Javaの更新が出る段階にはまだ入っていません。CPUとの違い、実際に出た版と修正の中身、4桁目の版番号をコマンドとJavaコードで判定する方法、保守運用のパッチ適用サイクルの組み直し方を、Oracle・OpenJDK・各配布元の一次情報で整理します（2026年10月11日時点）。
まとめ：Oracle CSPUでJavaの更新運用を月次へ組み直す要点
CSPUは、四半期の累積型CPUに加えて、優先度の高い修正だけを小さな単位で出す仕組みです。公開日は2・3・5・6・8・9・11・12月の第3火曜で、CPUの月と合わせると、Oracle製品全体では毎月どちらかが出ます。ただしJava向けの修正が入るかどうかは月ごとに違います。2026年の実績では、Oracle JDKの版が出たのは8月だけでした。
運用側で手を打つべきことは3つに絞れます。第3火曜の前週木曜に出る事前告知でJava SEが対象かを確かめること。4桁目（21.0.12.1の末尾の1）まで比較できる版判定に、CIと資産管理の仕組みを直すこと。そして、認証なしでネットワーク越しに突ける修正が自分の使う系列に入っている月だけ、次のCPUを待たずに当てることです。
3桁しか見ない版判定は、CSPUを当てた環境と当てていない環境を同じ版として扱います。月次化への対応は、適用の手間より先に、この判定の穴を塞ぐところから始めてください。
CSPUの定義とCPUとの違いを公式アドバイザリの記載で確認する
まずは用語の位置づけです。CSPUは新しい種類のパッチではなく、同じ種類の修正を、より短い間隔で届けるための公開枠です。
CPUを補う小型の更新としてOracleが2026年5月28日に始めたCSPU
Oracleのセキュリティアラート一覧は、CSPUを「対象を絞った優先度の高いセキュリティ修正を、より小さく焦点を絞った形式で提供し、最小限の中断で適用しやすくするもの」と説明しています。位置づけは、既存の四半期累積型CPUを補完する更新です。初回は2026年5月28日（木曜）で、以降は2・3・5・6・8・9・11・12月の第3火曜に出ます。2026年6月からは、公開日の前週木曜に事前告知が出るようになりました。
次の4回は2026年11月17日、12月15日、2027年2月16日、3月16日です。CPUは2026年10月20日、2027年1月19日、4月20日、7月20日が予定されています。
累積型のCPUと対象を絞ったCSPUの違いを日程・中身・契約で比較
両者の違いを、公式アドバイザリの記載に沿って並べます。
| 観点 | CPU | CSPU |
|---|---|---|
| 公開月 | 1・4・7・10月 | 上記以外の8か月 |
| 公開日 | 第3火曜 | 第3火曜（初回のみ5月28日） |
| 中身 | 累積型の修正一式 | 優先度の高い修正だけ |
| 規模の例 | 2026年1月は337件 | 2026年5月は35件 |
| 事前告知 | 前週木曜 | 前週木曜（2026年6月から） |
規模の差は月によって大きく振れます。5月のCSPUは全製品で35件でしたが、8月は943件、9月は673件でした。「小型」はCPUより必ず件数が少ないという意味ではなく、製品ごとに必要な修正だけを出すという意味で読むのが正確です。CPU側の規模感は2026年1月CPUの337件を製品別に分解した記事で確認できます。なお、どちらも提供は有効なサポート契約を持つ顧客向けと書かれており、Oracle JDKを無償で使っている場合の扱いは版ごとのライセンスで決まります。
2026年のJava向けCSPUで実際に出た版と修正件数を追う
CSPUが始まった5月からJavaの修正が毎月出ているわけではありません。各月のアドバイザリを開いて、Java SEの欄を確かめた結果を順に示します。
5月・6月のCSPUにJava SEが無く8月が最初になった経緯
5月（35件）と6月（245件）のCSPUには、Java SEの製品ファミリーが載っていません。Javaの扱いが決まったのは7月です。2026年7月20日、OpenJDKのjdk-updates-devメーリングリストに「Transitioning Java to CSPU」という告知が投稿され、JDK 26.0.2.1を8月18日に出す計画と、9月のCSPUは計画していないことが示されました。
配布元も同じ時期に追随しています。Azulは7月23日に、Azul CoreとAzul Primeで8月から毎月のCSPUを提供すると発表しました。対象はLTSの8・11・17・21・25と、当時の現行版26です。
8月18日のCSPUで出た8u503・21.0.12.1・25.0.4.1と5件のCVE
2026年8月のCSPUアドバイザリによると、Oracle Java SEの新規修正は5件で、そのうち4件は認証なしでリモートから悪用できるものでした。影響を受ける版は8u501・11.0.32・17.0.20・21.0.12・25.0.4・26.0.2、つまり7月のCPU版です。
| CVE | CVSS | 部位 | 影響する系列 |
|---|---|---|---|
| CVE-2026-62574 | 7.8 | Install（ローカル） | 8〜26の全系列 |
| CVE-2026-70906 | 7.5 | Multiple | 25と26のみ |
| CVE-2026-61308 | 6.8 | Networking（HTTP） | 8〜26の全系列 |
| CVE-2026-70907 | 5.3 | JSSE（TLS） | 8〜26の全系列 |
| CVE-2026-60589 | 3.7 | Security | 8〜26の全系列 |
修正版は同日公開です。JDK 21.0.12.1のリリースノートはフルバージョン文字列を21.0.12.1+1とし、JDK 25.0.4.1も同じ形です。セキュリティベースラインには25.0.4.1+1、21.0.12.1+1、17.0.20.1+1、11.0.32.1+1、1.8.0_503-b01が並びました。
21系だけを使っている現場にとって、最も高い7.8はローカル攻撃の脆弱性で、認証なしリモートの7.5は対象外でした。同じCSPUでも、系列によって急ぎ度が変わります。
9月15日のCSPUはGraalVMのみでOracle JDK本体の版は出ていない
2026年9月のCSPUにも「Oracle Java SE Risk Matrix」の欄はあります。ただし中身の3件はすべてGraalVM for JDK（17向け23.0.13.1、21向け23.1.12.1）とGraalVM Enterprise Edition 21.3.19.1のコンパイラ部分で、最大CVSSは8.1です。Oracle JDK本体の新しい版は出ていません。
見出しだけで「9月もJavaのCSPUがあった」と読むと、存在しない版を探すことになります。同じ9月15日にはJava 27がGAになっており、Java 27の更新日程をまとめた記事で触れたCPUとCSPUの月割りは、Oracle製品全体の枠組みとして読んでください。Javaの修正が入るかどうかは、毎回アドバイザリのJava SE欄で確認するしかありません。
CSPUで付く4桁目の版番号をコマンドとJavaコードで判定する
CSPUで実務に響くのは、版番号の桁が1つ増えることです。ここでは仕様を確認し、手元とCIで判定する方法をコードで示します。
JEP 322のPATCH要素が21.0.12.1の末尾の1にあたる仕組み
JDK 10で入ったJEP 322は、版番号を$FEATURE.$INTERIM.$UPDATE.$PATCHの4要素と定めています。4番目のPATCHは「少数の重大な問題を修正する互換パッチリリースのカウンタ」です。末尾がゼロの要素は表記しない規則なので、CPU版の21.0.12は、厳密には21.0.12.0にあたります。
この4番目の要素は仕様上ずっと存在していましたが、Oracle JDKの定期更新で使われることはほとんどありませんでした。CSPUによって、毎年何度か現れる値になります。Runtime.Versionにはfeature()・interim()・update()・patch()の4つのアクセサがあり、Javaコードからはこの値をそのまま取り出せます。
java -XshowSettingsで稼働中ランタイムの版と配布元を確認する
サーバー上のJavaがCSPU版かどうかは、システムプロパティを出すと一度に分かります。java -versionの表示形式は配布元で少しずつ違うため、プロパティ名で取るほうが確実です。
$ java -XshowSettings:properties -version 2>&1 | grep -E "java\.(runtime\.version|vendor|version) ="
java.runtime.version = 21.0.12.1+1-LTS
java.vendor = Eclipse Adoptium
java.version = 21.0.12.1出力例はEclipse Temurin 21.0.12.1の場合です。java.versionに4桁目が出ていればCSPU版で、21.0.12のように3桁で終わっていれば7月のCPU版のままです。java.vendorも同時に控えてください。後で見るとおり、配布元によって版番号の振り方が違います。
Runtime.Versionで基準版未満を検出してCIを止めるJavaコード
CIのテスト用イメージや本番コンテナのJavaが基準版を下回っていたら、ビルドを止める例です。Java 11以降はソースファイルを直接実行できるので、コンパイル手順は要りません。
// CspuGate.java ― 実行中のJavaが基準版以上かを判定する
public class CspuGate {
public static void main(String[] args) {
Runtime.Version current = Runtime.version();
Runtime.Version baseline = Runtime.Version.parse(args[0]);
System.out.printf("current=%s feature=%d update=%d patch=%d%n",
current, current.feature(), current.update(), current.patch());
if (current.feature() != baseline.feature()) {
System.err.println("系列が基準と違います: baseline=" + baseline);
System.exit(2);
}
if (current.compareToIgnoreOptional(baseline) < 0) {
System.err.println("基準版未満です: baseline=" + baseline);
System.exit(1);
}
System.out.println("OK");
}
}$ java CspuGate.java 21.0.12.1compareToIgnoreOptionalは要素を左から数値で比べるため、21.0.12と21.0.12.1を正しく別物として扱い、前者を基準未満と判定します。基準版の引数は、CSPUやCPUが出るたびにパイプラインの設定側で1か所だけ書き換えます。Java 8はRuntime.Versionを持たないので、この方法は使えません。8系は後述のとおり別の扱いが要ります。
Adoptium APIの最新版取得とsemver比較で起きる取りこぼし
基準版を手で更新するのが面倒なら、配布元のAPIから最新版を取る方法があります。Adoptium APIで21系のLinux向けJREを問い合わせた結果が次のとおりです（2026年10月11日取得）。
$ curl -s "https://api.adoptium.net/v3/assets/latest/21/hotspot?os=linux&architecture=x64&image_type=jre" \
| jq -r '.[0] | .release_name, .version.openjdk_version, .version.semver, .version.patch'
jdk-21.0.12.1+1
21.0.12.1+1-LTS
21.0.12+101.0.LTS
1注目すべきは3行目です。semver表記では4桁目が消え、21.0.12の後ろの「+101」というビルドメタデータへ畳み込まれています。Semantic Versioning 2.0.0では、優先順位の判定でビルドメタデータを無視するという規定です。そのため、semver用のライブラリでこの値と7月のCPU版を比べると、両者は同じ版と判定されます。
比較に使うフィールドはopenjdk_versionか、version.patchを含む数値の組にしてください。資産管理ツールやSBOMの照合でも、どの表記を読んでいるかを一度確かめておくと、CSPU未適用の取りこぼしを防げます。
配布元ごとに異なるCSPUの版番号と提供日の差を把握するための比較
OpenJDKのビルドを配る事業者は、OracleのCSPUと同じ修正を取り込みますが、版番号の付け方と公開日は揃っていません。
Oracle・Temurin・Correttoの8月CSPU版番号を並べた対応表
| 系列 | Oracle JDK | Eclipse Temurin | Amazon Corretto |
|---|---|---|---|
| 8 | 8u503 | 8u504 | 8u504 |
| 11 | 11.0.32.1 | 11.0.32.1 | 11.0.32.10.1 |
| 17 | 17.0.20.1 | 17.0.20.1 | 17.0.20.10.1 |
| 21 | 21.0.12.1 | 21.0.12.1 | 21.0.12.9.1 |
| 25 | 25.0.4.1 | 25.0.4.1 | 25.0.4.8.1 |
| 26 | 26.0.2.1 | 26.0.2.1 | 26.0.2.11.1 |
| 公開 | 8月18日 | 告知は9月2日 | 8月18日 |
CorrettoはAWSの告知のとおりOracleと同じ8月18日に出し、独自の5桁表記を使っています。Temurinの公式告知は9月2日付ですが、前述のAPIでは21系JREのバイナリ更新日時が2026年8月19日でした。告知の日付だけで「まだ出ていない」と判断せず、配布APIやダウンロードページの実物で確認するほうが早く動けます。
Java 8だけ4桁目を使わず8u503と8u504に分かれる点の注意
Java 8はJEP 322より前の版番号体系なので、CSPUでも4桁目は付きません。更新番号そのものが進み、Oracleは8u503（1.8.0_503-b01）、TemurinとCorrettoは8u504になりました。7月のCPUもOracleが8u501、Temurinが8u502で、配布元間の番号は元からずれています。
このため「8u503以上なら修正済み」という1本のしきい値は、配布元が混在する環境では成り立ちません。判定には、java.vendorと更新番号の組で配布元ごとの基準表を持たせます。なお8u503のリリースノートは、10月20日のCPU以降の利用を推奨せず、Oracleのサーバーへ到達できない環境向けのJREの有効期限を2026年11月20日としています。Oracle JDK 8・11・17の更新はOTNライセンスで提供されているため、無償で使える範囲はOpenJDKとOracle JDKのライセンスの違いを整理した記事で先に確かめてください。
保守運用のパッチ適用サイクルを月次CSPU前提で組み直す手順
CPUだけを前提にした四半期の運用は、年4回の検証枠で回っていました。CSPUを受け止めるには、毎月の確認と、当てるかどうかの判定基準が要ります。
第3火曜の公開から適用判定までを1週間で回す月次の確認・検証手順
- 前週木曜：事前告知でJava SE（とGraalVM）が対象製品に入っているかを見る。入っていなければその月は終了。
- 第3火曜：アドバイザリのJava SE Risk Matrixで、影響する系列・CVSS・認証なしリモートの可否を、自社の稼働系列と突き合わせる。
- 翌日以降：使っている配布元の修正版が出たかを、APIやダウンロードページで確認する。
- 検証環境へ入れ、CIの基準版を新しい版へ書き換えて回帰テストを流す。
- 次項の基準で「今月当てる」と判断したものだけ本番へ反映し、判断の記録を残す。
1と2は、版の一覧表と照合するだけなので30分もかかりません。時間を食うのは4の回帰テストです。ここが手作業のままだと、月次の頻度に耐えられなくなります。
CSPUを次のCPUまで待ってよい条件と2週間以内に当てる条件
CSPUを毎回すべて本番へ入れる必要はありません。判断は、Risk Matrixの「Remote Exploit without Auth.」の列と、影響するコンポーネントを自社のシステムが外部入力で使っているかで切ります。
2週間以内に当てるのは、自社の系列に認証なしリモートで悪用できる修正があり、その部位（NetworkingやJSSEなど）がインターネットからの入力を処理している場合です。逆に、自社の系列に該当するのがローカル攻撃だけの修正で、サーバーへのログインを運用者に限っているなら、次のCPUにまとめて構いません。8月のCSPUを21系で見ると、最も高い7.8はローカル攻撃、HTTP経由の6.8は攻撃の難易度が高いと評価されていました。社内向けの業務システムなら、10月20日のCPUに束ねる判断が成り立ちます。
見送りの判断をするときは、CVSSの各指標の意味を誤解しないことが前提です。指標の読み方はCVEとCWEの違いとCVSSの関係を整理した記事にまとめています。一方、公開サービスでTLS終端をJava側で持っている構成では、JSSEの修正が入った月は待たずに当ててください。
保守を外部へ委託しているときに契約で確かめておく月次更新の作業項目
Javaランタイムの更新を保守ベンダーに任せている場合、CSPUで契約の前提が崩れていないかを確かめる必要があります。見るべきは次の4点です。
- パッチ適用の頻度が「四半期ごと」と書かれていないか
- 月次の確認作業と、見送り判断の記録が作業範囲に入っているか
- 緊急適用のときの検証範囲と、追加費用の扱い
- 4桁目まで見る版判定に、資産管理の仕組みが対応しているか
1つ目が四半期のままだと、CSPUの確認は誰の仕事でもなくなります。運用の頻度を変えるなら、作業の定義も同時に書き換えてください。既存システムの保守体制ごと見直す場合は、保守運用・内製化支援の窓口へ、稼働中のJDKの系列・配布元・更新手順を持ち込んでいただくと、月次化に必要な作業量を具体的に見積もれます。
よくある質問
Oracle CSPUについて検索されている質問に、2026年10月11日時点の公開情報で答えます。
CSPUとCPUの違いは何ですか？
CPUは1・4・7・10月の第3火曜に出る四半期の累積型パッチで、CSPUはそれ以外の8か月の第3火曜に出る、優先度の高い修正だけを絞った更新です。Oracleは、CSPUを累積型CPUを補完するものと位置づけています。両方を合わせるとOracle製品全体では毎月どちらかが出ますが、Javaの修正が含まれるかは月ごとに異なります。
JavaのCSPUは毎月出ますか？
2026年10月時点では毎月ではありません。Oracle JDKの版が出たのは8月18日だけで、5月と6月はJava SEの修正なし、9月はGraalVMの修正だけでした。OpenJDKの7月20日の告知でも、9月のCSPUは計画しないと示されていました。次回は11月17日の予定なので、前週木曜の事前告知でJava SEが対象かを確認してください。
21.0.12.1の最後の「.1」は何を意味しますか？
JEP 322が定める4番目の要素PATCHで、少数の重大な問題を直すパッチリリースのカウンタです。21.0.12が7月のCPU版、21.0.12.1がそれにCSPUの修正を足した版にあたります。Runtime.Versionのpatch()で取り出せるほか、java.versionのシステムプロパティにも4桁で表示されます。
CSPUを当てずに次のCPUを待っても大丈夫ですか？
条件次第です。自社の系列に認証なしでリモートから悪用できる修正がなく、該当部位を外部入力で使っていないなら、次のCPUにまとめる判断は成り立ちます。8月のCSPUで認証なしリモートの7.5が影響したのは25系と26系だけでした。CPUの版でCSPUの修正が含まれるかは、CPU公開時のアドバイザリとリリースノートで必ず確認してください。
TemurinやCorrettoなどOracle以外のJDKもCSPUの対象ですか？
対象です。2026年8月の分は、Amazon Correttoが8月18日に21.0.12.9.1などを出し、Eclipse Temurinは9月2日付で21.0.12.1などの提供を告知しました。Azulも8月からの月次提供を発表しています。版番号の付け方と公開日は配布元ごとに違うため、java.vendorと版番号の組で判定してください。
関連記事
- Java 27とは｜非LTSの半年運用とG1・オブジェクトヘッダ既定化の影響：CSPUと同じ9月15日にGAとなったJava 27の既定値変更とサポート期限
- Oracle 2026年1月CPUの337件とは？Java・MySQL・WebLogicの修正版と悪用済みCVE【2026年10月】：四半期CPUの中身を製品別に分解した実例
- OpenJDKは商用利用できる？無料の範囲とOracle JDKとの違い・ライセンス・サポート期限【2026年最新】：CSPU版を無償で使えるかを決めるライセンスの線引き
- CVEとCWEの違いとは？脆弱性管理の基礎をCVSS・相互関係とあわせて解説：Risk MatrixのCVSSを読んで適用の急ぎ度を決めるための基礎
- Java SEとは？JDK・JRE・JVMの違いとOracle Java/OpenJDKのライセンスを最新版で解説：版番号の話に入る前に押さえるJDKとランタイムの用語整理
