On this page · 10 sections
Summary. On 18 August 2026 Amazon published a critical security patch update (CSPU) for Amazon Corretto covering six lines at once: 26.0.2.11.1, 25.0.4.8.1, 21.0.12.9.1, 17.0.20.10.1, 11.0.32.10.1 and 8u504. That is 27 days after the quarterly release of 21 July 2026, and the three quarterly drops before it landed on 20 January and 22 April 2026, so this one sits outside the cycle. Three CVEs are common to every line: CVE-2026-61308 (CVSS 6.8, core-libs/java.net), CVE-2026-70907 (5.3, security-libs/javax.net.ssl) and CVE-2026-60589 (3.7, security-libs/javax.xml.crypto). Two things the announcement does not say matter more than the announcement. First, on Java 11, 17, 21, 25 and 26 the OpenJDK update digits do not move at all, so anything that inventories your fleet by update version will report the unpatched build as current. Second, the CVE set is not uniform: Corretto 25 and 26 also fix CVE-2026-70906 (7.5, client-libs/2d), and Corretto 8, 11, 17 and 21 do not.
What actually shipped
The AWS announcement is a single paragraph listing six version strings and a download link. The per-line CHANGELOG.md files in the Corretto repositories carry the detail, and reading them side by side is where the operational problem shows up.
| Corretto line | 21 July 2026 build | 18 August 2026 build | OpenJDK baseline, before then after |
|---|---|---|---|
| Corretto 26 (feature release) | 26.0.2.10.1 | 26.0.2.11.1 | 26.0.2+10 then 26.0.2.1+1 |
| Corretto 25 | 25.0.4.7.1 | 25.0.4.8.1 | 25.0.4+7 then 25.0.4.1+1 |
| Corretto 21 | 21.0.12.8.1 | 21.0.12.9.1 | 21.0.12+8 then 21.0.12.1+1 |
| Corretto 17 | 17.0.20.8.1 | 17.0.20.10.1 | 17.0.20+8 then 17.0.20.1+1 |
| Corretto 11 | 11.0.32.9.1 | 11.0.32.10.1 | 11.0.32+x then 11.0.32.1+1 |
| Corretto 8 | 8.502.07.1 | 8.504.01.1 | 8u502-b07 then 8u504-b01 |
Read the last column again. On five of the six lines, the OpenJDK baseline moved from an update build such as 21.0.12+8 to an interim patch build, 21.0.12.1+1. The update digits, 21.0.12, are identical either side of the fix. Java 8 is the exception: its baseline went from jdk8u502-b07 to jdk8u504-b01, so the update number visibly jumps by two.
What breaks
The failure is in detection, not in the runtime. A large number of teams answer "are we patched?" with some variant of "what does the update version say?" That question works on Java 8 this month and fails on everything else.
Concretely, these checks cannot separate a patched from an unpatched build after 18 August 2026:
- Any inventory rule that matches on
11.0.32,17.0.20,21.0.12,25.0.4or26.0.2. Both the July and the August builds satisfy it.
- Any container policy expressed as a minimum OpenJDK update, for example "must be at least 17.0.20". The July build already met that bar.
- Any dashboard that truncates the Java version to three components for display. The fourth digit is where the whole change lives.
- Any CVE feed correlation that maps a CVE to "fixed in OpenJDK 17.0.20" without carrying the
.1interim patch. The mapping resolves to a build you already had in July.
The check that does work is the full Corretto version string, all four fields. java -version on a patched Corretto 17 reports the Corretto build, and the fourth field is the one that moved from 8 to 10. Package managers hold the same information: the Debian package for the August Corretto 25 build is java-25-amazon-corretto-jdk_25.0.4.8-1_amd64.deb and the RPM is java-25-amazon-corretto-devel-25.0.4.8-1.x86_64.rpm, against 25.0.4.7-1 in July.
The CVE set is not uniform, and the gap is the highest-severity fix
The second thing worth knowing is that the six lines did not get the same patch.
| CVE | CVSS | Component | Lines that fix it |
|---|---|---|---|
| CVE-2026-70906 | 7.5 | client-libs/2d | Corretto 25 and 26 only |
| CVE-2026-61308 | 6.8 | core-libs/java.net | 8, 11, 17, 21, 25, 26 |
| CVE-2026-70907 | 5.3 | security-libs/javax.net.ssl | 8, 11, 17, 21, 25, 26 |
| CVE-2026-60589 | 3.7 | security-libs/javax.xml.crypto | 8, 11, 17, 21, 25, 26 |
CVE-2026-70906 is the highest-scoring item in this release at 7.5, and it appears only in the Corretto 25 and Corretto 26 changelogs. The Corretto 8, 11, 17 and 21 changelogs each list exactly three CVEs and 70906 is not among them.
There are two readings of that, and the changelogs do not tell you which is correct. Either the older lines are not affected, most plausibly because the 2d code path in question does not exist there, or the fix for those lines is still pending. If you run Corretto 17 or 21 and your risk register tracks CVE-2026-70906, do not record it as remediated by this release. It is not mentioned there at all, which is a different state from "fixed".
How to tell whether this is you
You are exposed to the detection gap if any of the following is true:
- You run Corretto 11, 17, 21, 25 or 26 anywhere, and your patch evidence is a version report rather than a build fingerprint.
- Your base images are pinned by major version, for example
amazoncorretto:21, and rebuilt on a schedule rather than on a release event. Tag-based pins pull the fix only when you rebuild.
- Your compliance evidence is a screenshot or export of a version column. Nothing in that column changed for five of six lines.
- You suppressed a scanner finding earlier in August on the grounds that the update version already matched the fixed version.
You are comparatively safe if your inventory records the full four-field Corretto version or the package NEVRA, or if you rebuild base images on upstream release rather than on a calendar.
What to do
- Fingerprint on the full version, not the update digits. Record all four fields. For the August builds that means 26.0.2.11.1, 25.0.4.8.1, 21.0.12.9.1, 17.0.20.10.1, 11.0.32.10.1 and 8.504.01.1.
- Rebuild, do not just re-pull. A floating major-version tag gives you the fix at the next rebuild, not at the moment of release. If the rebuild is monthly, the exposure window is measured in weeks.
- Treat Java 8 differently in reporting. It is the one line where update-number logic still holds this month, going from 8u502 to 8u504. That will make your Java 8 estate look like the well-managed one on any version-based dashboard, for reasons that have nothing to do with how it is managed.
- Re-open anything closed on a version match. Findings dismissed between 21 July and 18 August 2026 on the basis that the update version matched a fixed version should be re-evaluated against the four-field build.
- Record CVE-2026-70906 as not-addressed on 8, 11, 17 and 21 rather than as fixed, until Amazon states otherwise for those lines.
The wider point is about cadence. Three of the 2026 Corretto drops landed on 20 January, 22 April and 21 or 22 July, which is a rhythm you can staff around. An 18 August release is not on that rhythm, and a patch process keyed to quarterly dates will pick this one up in October. Six weeks is a long time to carry a 6.8 in java.net.
India-specific considerations
Indian engineering organisations running large Java estates for banking, insurance and logistics clients tend to have the Java 8 and Java 11 concentration where this matters most, usually under a contractual patch SLA measured in days from vendor release. Those SLAs are almost always written against a version number. Where the contract or the DPDP-driven security programme requires evidence of patching, the evidence artefact needs to be the four-field build string or the package version, because on Corretto 11 the update digits are identical before and after the 18 August 2026 fix and a version report alone will not demonstrate compliance.
What is still unknown
The changelogs give CVE identifiers, CVSS scores and component names, and nothing else. They do not describe the vulnerabilities, state whether any is remotely reachable in a default configuration, or say whether CVE-2026-70906 is absent from the older lines because they are unaffected or because a fix is still to come. The AWS announcement does not explain why the release is off-cycle. Until that detail is published, severity triage has to run on the CVSS scores and the component names alone.
FAQ
How eCorpIT can help
Teams that maintain long-lived Java services usually find that the patching problem is an inventory problem first. If you are working through what your estate actually runs and how patch evidence is recorded, our offshore software development teams do this work alongside client platform groups. Ask us about a Java estate review if the version-detection gap above describes your fleet.
References
Last updated: 22 August 2026.
