Amazon Corretto 2026年9月版の内容とバージョンの見分け方を確認してみた
はじめに
2026-10-01 に AWS の What's New で「Amazon Corretto 8 September 2026 Patch Updates」が投稿されました。
7月の四半期アップデートと8月の初回 CSPU（Critical Security Patch Updates）は、それぞれ次の記事で扱っています。
この記事では、9月のパッチの中身、手元のランタイムが9月版かどうかの見分け方、tzdata の更新で時刻が変わる地域と日本への影響を確認しました。
9月のパッチの内容
What's New が取り上げているのは、Corretto 8（8u504）だけです。本文には、tzdata 2026d の更新が含まれると書かれています。9月のタイトルは「Patch Updates」で、6バージョンを対象として挙げた8月の「Critical Security Patch Updates」とは位置づけが異なります。
CHANGELOG を見ると、9月は 8 のほかに 11 / 17 / 21 / 25 / 27 もリリースされています。
| バージョン | ビルド | 日付 | 内容 |
|---|---|---|---|
| 8 | 8.504.04.1 | 9/29 | tzdata 2026c / 2026d、AL2023 向け GUI 修正2件 |
| 11 | 11.0.32.12.1 | 9/29 | tzdata 2026c / 2026d、macOS の Info.plist、AL2023 向け GUI 修正 |
| 17 | 17.0.20.12.1 | 9/25 | tzdata 2026c / 2026d、macOS の Info.plist |
| 21 | 21.0.12.12.1 | 9/25 | tzdata 2026c / 2026d、macOS の java_home の表示 |
| 25 | 25.0.4.10.1 | 9/29 | tzdata 2026c / 2026d、JDK-8390874（メモリリーク、全プラットフォーム）、macOS の Info.plist |
| 27 | 27.0.0.35.1 | 9/15 | jdk-27+35、tzdata 2026c、JDK-8390874（メモリリーク、全プラットフォーム） |
9月分は、どのバージョンにも CVE の記載がありませんでした。中心は tzdata の取り込みです。CVE 対応に伴うセキュリティ設定の変更がないことを確認するため、21 と 25 について、8月版と9月版の java -XshowSettings:security -version を比較しました。差分は、Runtime Environment と Server VM のビルド表記の2行だけでした。
9月版かどうかの見分け方
java -version のビルド番号で見分ける
java -version の1行目は、8月版と9月版で同じです。public.ecr.aws/amazoncorretto/amazoncorretto:21（2026-10-01 作成、arm64）の9月版では、次のように出ました。
openjdk version "21.0.12.1" 2026-08-18 LTS
OpenJDK Runtime Environment Corretto-21.0.12.12.1 (build 21.0.12.1+12-LTS)
OpenJDK 64-Bit Server VM Corretto-21.0.12.12.1 (build 21.0.12.1+12-LTS, mixed mode, sharing)
日付が 2026-08-18 のままなので、確認するのは2行目のビルド番号です。8 は、1行目が "1.8.0_504" で日付は表示されず、8月版と9月版のどちらも 8u504 なので、同じく2行目のビルド番号で区別します。
tar.gz を展開して実行したときの java -version の2行目と、ZoneRulesProvider が返した tzdata のバージョンは次のとおりです。
| バージョン | 8月版 | 9月版 | 8月版の tzdata | 9月版の tzdata |
|---|---|---|---|---|
| 8 | 8.504.01.1（b01） | 8.504.04.1（b04） | 2026b | 2026d |
| 11 | 11.0.32.10.1 | 11.0.32.12.1 | 2026b | 2026d |
| 17 | 17.0.20.10.1 | 17.0.20.12.1 | 2026b | 2026d |
| 21 | 21.0.12.9.1 | 21.0.12.12.1 | 2026b | 2026d |
| 25 | 25.0.4.8.1 | 25.0.4.10.1 | 2026b | 2026d |
27 の9月版は、1行目が "27" 2026-09-15、ビルドは 27.0.0.35.1（build 27+35-FR）、tzdata は 2026c です。
11 / 17 / 21 / 25 / 27 では、$JAVA_HOME/release の IMPLEMENTOR_VERSION にも同じビルド番号が出ます。21 の9月版は IMPLEMENTOR_VERSION="Corretto-21.0.12.12.1"、8月版は Corretto-21.0.12.9.1 でした。8 の release には JAVA_VERSION="1.8.0_504" と JAVA_HOME がありますが、IMPLEMENTOR_VERSION はありません。8 は java -version で確認します。
ビルド番号の対応表が手元にない場合は、実行中の JVM が持つ tzdata のバージョンを直接読む方法もあります。次のコードを TzVersion.java として保存し、javac TzVersion.java でコンパイルして java TzVersion で実行します。8 を含む全バージョンで動作しました。
import java.time.zone.ZoneRulesProvider;
public class TzVersion {
public static void main(String[] args) {
System.out.println("tzdb versions (Asia/Tokyo): " + ZoneRulesProvider.getVersions("Asia/Tokyo").keySet());
System.out.println("zone id count: " + ZoneRulesProvider.getAvailableZoneIds().size());
}
}
21 の9月版の出力です。
tzdb versions (Asia/Tokyo): [2026d]
zone id count: 604
取得経路ごとの違い
取得経路によっては、まだ9月版になっていません。次の表は、2026-10-04 07:14〜07:17 に取得した結果です。動作確認は aarch64 の Linux で行いました。
| 取得経路 | 8 | 11 | 17 | 21 | 25 | 27 |
|---|---|---|---|---|---|---|
downloads/latest の tar.gz |
9月版（8.504.04.1） | 9月版（11.0.32.12.1） | 9月版（17.0.20.12.1） | 9月版（21.0.12.12.1） | 9月版（25.0.4.10.1） | 27.0.0.35.1 |
| ECR Public のタグ（8、11 など） | 8月版（8.504.01.1、tzdata 2026b） | 9月版 | 9月版 | 9月版 | 9月版 | 27.0.0.35.1 |
| AL2023 標準リポジトリの最新 rpm（ECR Public の 21 のイメージ内で dnf で問い合わせ） | 8月版（1.8.0_504.b01-1.amzn2023） | 8月版（11.0.32+10-1.amzn2023） | 8月版（17.0.20+10-1.amzn2023.1） | 8月版（21.0.12+9-1.amzn2023.1） | 8月版（25.0.4+8-1.amzn2023.1） | 未確認 |
| Corretto の yum リポジトリ（yum.corretto.aws）の最新 rpm | 9月版（1.8.0_504.b04-1） | 9月版（11.0.32.12-1） | 9月版（17.0.20.12-1） | 9月版（21.0.12.12-1） | 9月版（25.0.4.10-1） | 27.0.0.35-1 |
ECR Public の 8 タグが指す Corretto 8 は、What's New が唯一取り上げたバージョンですが、2026-10-01T09:54:23Z 作成のイメージの中身は8月版でした。
openjdk version "1.8.0_504"
OpenJDK Runtime Environment Corretto-8.504.01.1 (build 1.8.0_504-b01)
OpenJDK 64-Bit Server VM Corretto-8.504.01.1 (build 25.504-b01, mixed mode)
11 / 17 / 21 / 25 / 27 のイメージも 2026-10-01 に作成されたものです。
ECR Public の 21 のイメージ内では、AL2023 標準リポジトリの最新は、8 / 11 / 17 / 21 / 25 のいずれも8月版でした。同じイメージにインストール済みの 21 の rpm は、9月版の 21.0.12+12-1.amzn2023.1 でした。Corretto の yum リポジトリでは、同じ9月版が 21.0.12.12-1 と表記されていました。経路によって rpm のバージョン表記が異なります。
Corretto の yum リポジトリを追加した使い捨てコンテナでは、8 の java-1.8.0-amazon-corretto-devel パッケージ（1.8.0_504.b04-1）をインストールできました。java -version は Corretto-8.504.04.1 (build 1.8.0_504-b04) と出ました。
What's New には、Linux では Corretto の Apt / Yum / Apk リポジトリからも更新を取得できると書かれています。Corretto の yum リポジトリからは9月版を取得できましたが、現時点では、ECR Public の 8 タグと、上記の AL2023 標準リポジトリからは取得できません。
tzdata の更新による影響
時刻が変わる地域
IANA tz の変更内容は、次の一次ソースで確認できます。
- モロッコ（2026c、2026-07-08 公開）: 2026-09-20 から恒久的に +00 です。
- アルバータ（2026c）: 2026-06-18 から恒久的に -06（CST）になり、2026-11-01 に予定されていた時計の巻き戻しは行われません。
- ノースウェスト準州（2026d、2026-09-11 公開）: 2026-08-21 から恒久的に -06（CST）になり、2026-11-01 の巻き戻しも行われません。影響する zone は America/Inuvik です。準州内のその他の地域は America/Edmonton の規則に従うため、2026c で反映済みです。
2026d には、コロンビア（1992-05-02）とイラン（1979-05-26）の過去の遷移時刻の変更と、EST5EDT 系の互換名の変更も含まれます。
後述の ZoneCheck.java を、8月版の 21（tzdata 2026b）、9月版の 21（2026d）、9月版の 27（2026c）のそれぞれで実行しました。オフセットは次のとおりです。各値は、表の日付の UTC 12:00 時点のオフセットです。Z は +00:00 です。
| zone | 日付 | 8月版 21（2026b） | 9月版 21（2026d） | 9月版 27（2026c） |
|---|---|---|---|---|
| Africa/Casablanca | 2026-10-01 | +01:00 | Z | Z |
| America/Edmonton | 2026-11-02 | -07:00 | -06:00 | -06:00 |
| America/Inuvik | 2026-11-02 | -07:00 | -06:00 | -07:00 |
| America/Winnipeg | 2026-11-02 | -06:00 | -06:00 | -06:00 |
Africa/Casablanca は、2027-01-15 でも、8月版の 21 が +01:00、9月版の 21 と 27 が Z でした。
America/Inuvik だけは、9月版の 21 と 27 で結果が分かれています。27 の tzdata は 2026c なので、2026d で入ったノースウェスト準州の変更は、9月版の 27 にはまだ反映されていません。
2026e（2026-09-29 公開）には、マニトバが 2026-10-31 に恒久的に -05 へ移る変更が入っています。Winnipeg は、9月版の 21 と 27 のどちらも 2026-11-02 に -06:00 のままでした。2026e は9月版に入っていません。
ZoneCheck.java
ZoneCheck.java として保存し、javac ZoneCheck.java でコンパイルして java ZoneCheck で実行します。
import java.time.Instant;
import java.time.ZoneId;
import java.time.ZoneOffset;
import java.time.format.TextStyle;
import java.util.Locale;
import java.time.zone.ZoneRulesProvider;
public class ZoneCheck {
static final String[] ZONES = {
"Asia/Tokyo", "Africa/Casablanca", "America/Edmonton", "America/Inuvik", "America/Winnipeg"
};
static final String[] INSTANTS = {
"2026-10-01T12:00:00Z", "2026-11-02T12:00:00Z", "2027-01-15T12:00:00Z"
};
public static void main(String[] args) {
System.out.println("tzdb " + ZoneRulesProvider.getVersions("Asia/Tokyo").keySet());
for (String z : ZONES) {
ZoneId id = ZoneId.of(z);
StringBuilder sb = new StringBuilder(String.format("%-18s", z));
for (String s : INSTANTS) {
ZoneOffset off = id.getRules().getOffset(Instant.parse(s));
sb.append(String.format(" %s=%s", s.substring(0, 10), off));
}
System.out.println(sb);
}
}
}
日本は変わらない
ZoneCheck.java の3つの日付（2026-10-01、2026-11-02、2027-01-15）で、Asia/Tokyo のオフセットはすべて +09:00 でした。8月版の 21、9月版の 21、9月版の 27 で、同じ結果でした。
8月版の 21（tzdata 2026b）と9月版の 21（2026d）について、全 604 zone id の getTransitions() と getTransitionRules() を出力して突き合わせました。Asia/Tokyo の行は同一でした。差分が出たのは次の 13 zone で、日本の zone は含まれません。
Africa/Casablanca、Africa/El_Aaiun、America/Bogota、America/Edmonton、America/Inuvik、America/Yellowknife、Asia/Tehran、CST6CDT、Canada/Mountain、EST5EDT、Iran、MST7MDT、PST8PDT
まとめ
Amazon Corretto の2026年9月のパッチ（8・11・17・21・25）は、CHANGELOG に CVE の記載がなく、tzdata 2026c / 2026d の取り込みが中心でした。
java -version の1行目は8月版と同じでしたが、2行目のビルド番号で9月版かどうかを確認できました。
日本の時刻だけを扱うアプリには、tzdata の差分による影響はありません。21 で比較した範囲では、Asia/Tokyo の規則が8月版と9月版で同一だったためです。
変更が入った地域に拠点やユーザーがある場合は、影響を確認いただくことをおすすめします。
CVE の記載はありませんでしたが、25 と 27 には、全プラットフォーム対象のメモリリーク修正（JDK-8390874）が入っています。
9月版を導入するかどうかは、まず java -version のビルド番号で現在の版を確認し、8月版以前であれば修正内容を見て判断することをおすすめします。
