Blog
Amazon Corretto: Warum das Java-Sicherheitsupdate vom August 2026 für den Mittelstand dringend ist
Amazon hat am 18. August 2026 außerplanmäßige Sicherheitsupdates für alle aktuellen Corretto-Linien veröffentlicht. Betroffen sind Java-Laufzeiten von Version 8 bis 26 – und damit potenziell zahlreiche ERP-, Web-, Integrations- und Individualanwendungen im Mittelstand. Der richtige Ansatz ist kein blindes Update aller Systeme, sondern eine schnelle Bestandsaufnahme, risikobasierte Priorisierung und ein kontrollierter Rollout.
Die Nachricht ist auch außerhalb von AWS relevant: Corretto ist eine plattformübergreifende OpenJDK-Distribution und kann auf lokalen Servern, Entwicklerrechnern, in anderen Clouds und in Containern laufen. Entscheidend ist die tatsächlich verwendete Runtime – nicht der Standort der Anwendung.
TL;DR:
- AWS stellt neue Corretto-Builds für Java 8, 11, 17, 21, 25 und 26 bereit.
- Die Updates adressieren je nach Java-Linie drei oder vier veröffentlichte Schwachstellen; die höchste CVSS-Bewertung in den Corretto-Changelogs liegt bei 7,5.
- Drei Schwachstellen betreffen HTTP-Netzwerkverarbeitung, TLS sowie Sicherheits- beziehungsweise XML-Kryptografie-Komponenten.
- Java 25 und 26 erhalten zusätzlich eine Korrektur für die 2D-Komponente mit CVSS 7,5.
- Inventarisierung und Tests sind wichtiger als Aktionismus: Host-JDKs, Container-Basisimages, eingebettete Laufzeiten und CI/CD-Images müssen getrennt erfasst werden.
- Internetexponierte Java-Dienste, Gateways und Anwendungen mit TLS- oder HTTP-Verarbeitung sollten zuerst getestet und aktualisiert werden.
Was am 18. August veröffentlicht wurde
AWS bezeichnet die Veröffentlichung ausdrücklich als Critical Security Patch Update für Long-Term-Support- und Feature-Release-Versionen von Amazon Corretto. Neu verfügbar sind Corretto 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 und für Java 8 der Build 8.504.01.1, den die AWS-Ankündigung verkürzt als 8u504 aufführt. Die Pakete stehen direkt zum Download sowie über die Corretto-Repositories für Apt, Yum und Apk bereit.
Corretto ist Amazons kostenfreie, plattformübergreifende und für den Produktionseinsatz vorgesehene OpenJDK-Distribution. Die Aktualisierung ist deshalb nicht nur für Workloads relevant, die direkt auf AWS laufen. Entscheidend ist die Java-Distribution, die der Prozess tatsächlich lädt.
Quellen: AWS: Amazon Corretto August 2026 Critical Security Patch Updates; AWS: Amazon Corretto
Was die Schwachstellen bedeuten
Oracles August-CSPU führt für Java SE fünf neue Sicherheitskorrekturen auf; vier davon können laut Risikomatrix ohne Authentifizierung aus der Ferne ausgenutzt werden. Die Corretto-Changelogs zeigen für die älteren Linien 8, 11, 17 und 21 drei adressierte CVEs. In den Linien 25 und 26 kommt eine vierte Schwachstelle in der 2D-Bibliothek hinzu. Eine weitere von Oracle aufgeführte lokale Installationsschwachstelle ist in den veröffentlichten Corretto-CVE-Listen nicht enthalten. Deshalb sollte die Bewertung distributions- und versionsspezifisch erfolgen.
CVE-2026-61308: HTTP und Vertraulichkeit
CVE-2026-61308 betrifft die Netzwerkkomponente. Oracle bewertet sie mit CVSS 6,8. Ein nicht authentifizierter Angreifer kann die Schwachstelle über HTTP erreichen, wenn eine Anwendung kontrollierte Daten an die betroffenen APIs weitergibt. Ein erfolgreicher Angriff kann Vertraulichkeit beeinträchtigen. Die Ausnutzung gilt als schwierig, ist aber für öffentlich erreichbare Java-Webdienste dennoch relevant.
CVE-2026-70907: TLS und Teil-Ausfälle
CVE-2026-70907 liegt in JSSE, der Java-Implementierung für SSL und TLS. Die Bewertung beträgt CVSS 5,3. Oracle beschreibt eine einfach ausnutzbare, nicht authentifizierte Netzwerkschwachstelle über TLS, die einen partiellen Denial of Service verursachen kann. Das ist kein Beleg für eine vollständige Systemübernahme. Für Dienste mit vielen externen TLS-Verbindungen kann aber bereits eine gezielt ausgelöste Teilstörung geschäftskritisch sein.
CVE-2026-60589 und CVE-2026-70906
CVE-2026-60589 betrifft Sicherheitsfunktionen beziehungsweise in den Corretto-Changelogs die XML-Kryptografie. Die Schwachstelle ist mit CVSS 3,7 niedriger bewertet und kann einen begrenzten unautorisierten Lesezugriff ermöglichen. CVE-2026-70906 betrifft die 2D-Komponente, erreicht CVSS 7,5 und wird in den Corretto-Changelogs nur für Java 25 und 26 genannt. Sie kann die Verfügbarkeit beeinträchtigen. Die reine CVSS-Zahl reicht daher nicht: Erreichbarkeit, Datenfluss und eingesetzte Java-Linie bestimmen die reale Priorität.
Quellen: Oracle: August 2026 CSPU – Java SE Risk Matrix; Amazon Corretto 17 Changelog; Amazon Corretto 25 Changelog; Amazon Corretto 26 Changelog
Wichtig: Der Begriff „Critical Security Patch Update“ bezeichnet Oracles und Amazons Veröffentlichungsformat. Er bedeutet nicht, dass jede enthaltene Java-Schwachstelle den CVSS-Schweregrad „kritisch“ hat. Die höchste in den aktuellen Corretto-Changelogs ausgewiesene Bewertung beträgt 7,5.
Welche Corretto-Versionen das Update erhalten
| Java-Linie | Neuer Corretto-Build | Adressierte CVEs laut Changelog |
|---|---|---|
| 8 | 8.504.01.1 | 3: Netzwerk, TLS, XML-Kryptografie |
| 11 | 11.0.32.10.1 | 3: Netzwerk, TLS, XML-Kryptografie |
| 17 | 17.0.20.10.1 | 3: Netzwerk, TLS, XML-Kryptografie |
| 21 | 21.0.12.9.1 | 3: Netzwerk, TLS, XML-Kryptografie |
| 25 | 25.0.4.8.1 | 4: zusätzlich 2D-Komponente |
| 26 | 26.0.2.11.1 | 4: zusätzlich 2D-Komponente |
AWS stellt signierte Pakete und Prüfsummen für verschiedene Plattformen bereit. Unter Linux können bestehende Corretto-Repositories für Apt, Yum oder Apk genutzt werden. Für Container gibt es offizielle Corretto-Images in der Amazon ECR Public Gallery und auf Docker Hub. Ein aktualisiertes Repository auf dem Host ersetzt jedoch kein Update eines bereits gebauten Container-Images.
Quellen: Amazon Corretto 8 Changelog; Amazon Corretto 11 Release; Amazon Corretto 17 Changelog; Amazon Corretto 21 Release; Amazon Corretto 25 Changelog; Amazon Corretto 26 Changelog
Warum Java-Patching im Mittelstand oft schwieriger ist als gedacht
Die größte Hürde ist häufig nicht das Einspielen eines Pakets, sondern das Auffinden aller Laufzeiten. Java kann als Systempaket installiert, in einem Anwendungsverzeichnis mitgeliefert, in einem Container-Layer eingebettet oder durch ein Build-Werkzeug automatisch heruntergeladen worden sein. Auch kommerzielle Anwendungen bringen gelegentlich eine private Laufzeit mit. Ein Aufruf von java -version auf dem Server zeigt dann nur die Standardinstallation und nicht zwingend die Runtime des laufenden Prozesses.
Zusätzlich ist zwischen JDK und Anwendungsabhängigkeiten zu unterscheiden. Das Corretto-Update korrigiert die Java-Laufzeit. Es aktualisiert nicht automatisch Spring, Log4j, Netty, Tomcat oder andere Bibliotheken in der Anwendung. Umgekehrt ersetzt ein Dependency-Update keine gepatchte JVM. Beide Ebenen gehören in das Schwachstellenmanagement, brauchen aber unterschiedliche Nachweise und Rollout-Verfahren.
Quellen: AWS-Dokumentation: What is Amazon Corretto 17?; AWS-Dokumentation: Corretto 17 auf Docker
Priorisierung: Welche Systeme zuerst dran sind
Nicht jedes Java-System hat dasselbe Risiko. Vorrang sollten Systeme erhalten, die HTTP- oder TLS-Daten aus nicht vertrauenswürdigen Quellen verarbeiten, öffentlich erreichbar sind oder besonders sensible Daten halten. Dazu gehören beispielsweise Kundenportale, API-Gateways, Integrationsplattformen, B2B-Schnittstellen und internetnahe Backend-Dienste. Danach folgen interne geschäftskritische Anwendungen mit vielen externen Verbindungen.
Eine niedrigere Priorität kann für vollständig isolierte Entwicklungsumgebungen gerechtfertigt sein. „Intern“ bedeutet allerdings nicht automatisch „sicher“: Ein interner Dienst kann Daten von kompromittierten Clients, E-Mails, Partner-Schnittstellen oder vorgeschalteten Systemen erhalten. Die Priorisierung sollte deshalb den tatsächlichen Datenpfad und nicht nur die Firewall-Zone betrachten.
Quelle: Oracle: Java SE Risk Matrix und Hinweise zu erreichbaren APIs
Ein praxistauglicher Update-Prozess
1. Bestand erfassen
Ermitteln Sie pro Anwendung die Java-Distribution, die vollständige Build-Version, den Installationspfad, den Betreiber und die Kritikalität. Prüfen Sie laufende Prozesse, Container-Manifeste, Dockerfiles, Kubernetes-Workloads, CI/CD-Images und mitgelieferte Laufzeiten. Dokumentieren Sie auch Systeme, bei denen ein Softwarehersteller das JDK bündelt – dort kann ein eigenmächtiger Austausch den Supportstatus gefährden.
2. Exposition und Dringlichkeit bewerten
Ordnen Sie jeder Laufzeit die erreichbaren Protokolle und Datenquellen zu. Besonders relevant sind HTTP, TLS, XML-Signaturen sowie bei Java 25 und 26 Bild- beziehungsweise 2D-Verarbeitung. Prüfen Sie, ob vorgeschaltete Komponenten das Risiko reduzieren, ohne sie mit einer vollständigen Behebung gleichzusetzen. Eine Web Application Firewall oder ein Load Balancer kann bestimmte Angriffe erschweren, repariert aber nicht die verwundbare Runtime.
3. Reproduzierbar aktualisieren
Ändern Sie deklarative Quellen: Paketversionen, Base-Image-Tags oder besser Image-Digests, Build-Pipelines und Infrastrukturcode. Ein manueller Austausch auf einzelnen Servern erzeugt schnell Abweichungen. Bei Containern müssen Images neu gebaut, gescannt und ausgerollt werden. Prüfen Sie die Herkunft sowie Signatur oder SHA-256-Prüfsumme der Artefakte gegen die offiziellen Veröffentlichungen.
4. Technisch und fachlich testen
Starten Sie mit automatisierten Unit-, Integrations- und Regressionstests. Ergänzen Sie fachliche Tests für Anmeldung, Datenimport, PDF- oder Bildverarbeitung, TLS-Verbindungen, Signaturen und Batchläufe. Beobachten Sie Startzeit, Speicherverbrauch, Fehlerraten und Latenz. Auch fokussierte Sicherheitsupdates können Verhalten in Protokoll- und Kryptografiepfaden verändern; ein kontrollierter Test bleibt deshalb notwendig.
5. Gestaffelt ausrollen und nachweisen
Nutzen Sie Pilotinstanzen, Rolling Updates oder Blue-Green-Deployments. Halten Sie einen technisch getesteten Rückfallplan bereit, aber behandeln Sie ein Rollback auf die verwundbare Version nur als kurzfristige Notmaßnahme. Verifizieren Sie nach dem Rollout die tatsächlich laufende Version in jedem Prozess beziehungsweise Container. Erst dieser Nachweis schließt das Ticket – nicht der erfolgreiche Build der neuen Artefakte.
Quellen: AWS-Dokumentation: Corretto-Installation unter Linux; AWS-Dokumentation: Downloads und Prüfsummen; AWS-Dokumentation: offizielle Container-Images
Typische Fehler, die jetzt vermieden werden sollten
- Nur Serverpakete aktualisieren: Eingebettete JREs und Container bleiben unverändert.
- Nur nach „Java“ im Softwareinventar suchen: Produktnamen und Prozesse verschleiern mitgelieferte Laufzeiten.
- CVSS mit Geschäftsrisiko gleichsetzen: Exposition und Datenfluss können eine mittlere Bewertung hoch priorisieren.
- Unveränderliche Container missverstehen: Sie vereinfachen reproduzierbare Rollouts, patchen sich aber nicht selbst.
- Ungeprüft den Major Release wechseln: Für die Sicherheitskorrektur ist innerhalb der eingesetzten Linie zu aktualisieren; eine Migration von 11 auf 21 ist ein separates Projekt.
- Herstelleranwendungen eigenmächtig umbauen: Zuerst Freigabe, Hotfix oder aktualisiertes Paket des Anbieters anfordern.
- Nach dem Deployment nicht verifizieren: Alte Pods, Batch-Knoten oder Schatteninstallationen können weiterlaufen.
Was Geschäftsführung und IT-Leitung entscheiden sollten
Für die Geschäftsführung ist dies kein Anlass, jede Java-Anwendung sofort abzuschalten. Es ist aber ein guter Test für die operative Reife des Asset- und Patch-Managements. Innerhalb kurzer Zeit sollte die IT beantworten können: Wo läuft Corretto? Welche Systeme sind extern exponiert? Wer verantwortet den Test? Bis wann ist der Rollout abgeschlossen? Und wie wird die laufende Version nachgewiesen?
Wenn diese Antworten fehlen, ist die strukturelle Lücke wichtiger als die einzelne CVE. Ein belastbarer Prozess verbindet Softwareinventar, technische Ownership, Wartungsfenster, automatisierte Tests und revisionsfähige Nachweise. Das senkt nicht nur das aktuelle Java-Risiko, sondern verkürzt auch die Reaktionszeit beim nächsten außerplanmäßigen Update.
Fazit: Schnell handeln, aber kontrolliert
Das Corretto-Update vom 18. August 2026 betrifft eine breite Spanne aktiv genutzter Java-Versionen. Die veröffentlichten Schwachstellen reichen von möglichem Vertraulichkeitsverlust über partielle Dienstunterbrechung bis zu einer zusätzlichen 2D-Lücke in Java 25 und 26. Für mittelständische Unternehmen ist deshalb eine zeitnahe, risikobasierte Aktualisierung sinnvoll.
Handlungsempfehlung: Erfassen Sie zuerst alle laufenden Corretto-Instanzen einschließlich Container und eingebetteter Runtimes. Priorisieren Sie internetnahe HTTP- und TLS-Dienste, testen Sie den neuen Build innerhalb der bestehenden Java-Linie und schließen Sie den Vorgang erst nach Verifikation der tatsächlich laufenden Version ab.
Die pragmatische Reihenfolge lautet: Runtime-Bestand erfassen, exponierte Dienste priorisieren, Artefakte aus offiziellen Quellen beziehen, Anwendungen testen, gestaffelt ausrollen und die laufende Version verifizieren. Wer diesen Ablauf automatisiert und dokumentiert, löst nicht nur das aktuelle Problem, sondern verbessert dauerhaft die Widerstandsfähigkeit seiner Java-Landschaft. EIST Consulting unterstützt bei Inventarisierung, Cloud- und Container-Analyse sowie beim Aufbau reproduzierbarer Patch-Prozesse.