Ενημέρωση ασφαλείας Java: 19 διορθώσεις και νέες εκδόσεις JDK

Η ενημέρωση ασφαλείας Java του Ιουλίου 2026 είναι διαθέσιμη από τις 21 Ιουλίου και αφορά όλες τις ενεργές οικογένειες του Oracle JDK, από την Java 8 έως την Java 26. Η Oracle καταγράφει 19 νέες διορθώσεις ασφαλείας για το Java SE, μαζί με πρόσθετα patches τρίτων βιβλιοθηκών. Από τις 19 ευπάθειες, οι 17 χαρακτηρίζονται ως δυνητικά εκμεταλλεύσιμες απομακρυσμένα χωρίς authentication. Αυτό δεν σημαίνει ότι κάθε συνηθισμένος Java server είναι αυτομάτως εκτεθειμένος με τον ίδιο τρόπο· σημαίνει όμως ότι οι ομάδες πρέπει να χαρτογραφήσουν άμεσα ποια runtimes εκτελούν και να περάσουν στις νέες security baselines μετά από στοχευμένες δοκιμές.

Οι νέες εκδόσεις είναι οι JDK 26.0.2, 25.0.4, 21.0.12, 17.0.20, 11.0.32 και 8u501. Η Oracle συστήνει αναβάθμιση σε κάθε Critical Patch Update και επισημαίνει ότι το JDK 26.0.2 δεν θα πρέπει να χρησιμοποιείται μετά το επόμενο προγραμματισμένο security update της 18ης Αυγούστου 2026. Η μικρότερη απόσταση μέχρι το επόμενο patch window κάνει σημαντικό έναν επαναλήψιμο μηχανισμό rollout, όχι μια χειροκίνητη αλλαγή της τελευταίας στιγμής.

Τι διορθώνει το Java Critical Patch Update

Το risk matrix της Oracle καλύπτει διαφορετικά υποσυστήματα: scripting, 2D και ImageIO, γενικές libraries, JavaFX, JSSE/TLS, installation και τον πυρήνα security. Η υψηλότερη βαθμολογία που εμφανίζεται στον πίνακα για αυτή την οικογένεια είναι CVSS 7.8 σε τοπικό σενάριο εγκατάστασης, ενώ αρκετές δικτυακές ευπάθειες έχουν βαθμολογία έως 7.5. Η σοβαρότητα από μόνη της δεν αρκεί για προτεραιοποίηση. Μετρά επίσης αν η εφαρμογή δέχεται μη έμπιστα δεδομένα που φτάνουν σε επηρεαζόμενα APIs, αν χρησιμοποιεί desktop ή JavaFX λειτουργίες και αν εκτελεί παλαιότερο runtime σε internet-facing υπηρεσία.

Η ίδια η Oracle διευκρινίζει ότι ο όρος «remote exploit without authentication» εξαρτάται από το component και το σενάριο. Σε ορισμένες περιπτώσεις, η εκμετάλλευση μπορεί να περάσει μέσα από web service που τροφοδοτεί δεδομένα σε ένα ευάλωτο API. Άλλες εγγραφές σχετίζονται περισσότερο με Java Web Start ή applet deployments που φορτώνουν μη έμπιστο κώδικα. Επομένως, μια ομάδα backend δεν πρέπει ούτε να αγνοήσει ολόκληρο το update ως «client-only» ούτε να παρουσιάσει κάθε CVE ως άμεσο remote code execution στον δικό της server.

Ποιες εκδόσεις πρέπει να αντικατασταθούν

Ως πρακτικός κανόνας, οι προηγούμενες baselines 26.0.1, 25.0.3, 21.0.11, 17.0.19, 11.0.31 και 8u491 πρέπει να θεωρηθούν παλιές για το τρέχον patch cycle. Οι νέες πλήρεις baselines που δημοσιεύει η Oracle είναι 26.0.2+10, 25.0.4+7, 21.0.12+7, 17.0.20+7, 11.0.32+7 και 1.8.0_501-b08. Ο έλεγχος δεν πρέπει να περιοριστεί στο JDK του laptop ενός developer. Χρειάζεται απογραφή των JRE/JDK σε CI runners, container base images, application servers, batch workers, desktop clients και εργαλεία build που μπορεί να κουβαλούν δικό τους runtime.

Ξεκινήστε με την έξοδο του java -version σε κάθε περιβάλλον και συγκρίνετέ την με τη baseline της αντίστοιχης οικογένειας. Σε containers, ελέγξτε το πραγματικό image digest που τρέχει και όχι μόνο το tag στο repository. Σε managed πλατφόρμες ή vendor products, επιβεβαιώστε αν το runtime διαχειρίζεται από τον προμηθευτή πριν αντικαταστήσετε αρχεία χειροκίνητα. Η έκδοση του application framework δεν αποδεικνύει ποια Java εκτελείται στο production.

Ένα ασφαλές rollout σε τέσσερα βήματα

1. Φτιάξτε απογραφή ανά runtime και ιδιοκτήτη

Καταγράψτε εφαρμογή, Java family, ακριβές build, περιβάλλον, τρόπο εγκατάστασης και υπεύθυνη ομάδα. Δώστε προτεραιότητα σε internet-facing services, workloads που επεξεργάζονται αρχεία ή εικόνες, endpoints που μεταφέρουν μη έμπιστα δεδομένα σε Java APIs και παλιές desktop εγκαταστάσεις. Η Oracle διαθέτει επίσης Java Management Service για εντοπισμό ευάλωτων Java εκδόσεων, αλλά μια απλή, ελεγμένη απογραφή παραμένει η βάση.

2. Αναβαθμίστε πρώτα το CI και το staging

Περάστε το νέο patch release σε reproducible build image και εκτελέστε unit, integration και smoke tests. Ελέγξτε ειδικά TLS handshakes, certificate validation, parsing εικόνων, PDF ή media pipelines, scripting integrations και οτιδήποτε χρησιμοποιεί native libraries. Το JDK 26.0.2 περιλαμβάνει και αλλαγή στην προεπιλεγμένη κωδικοποίηση private keys για ML-KEM και ML-DSA, άρα εφαρμογές που ανταλλάσσουν τέτοια κλειδιά με παλαιότερα JDK χρειάζονται compatibility test.

3. Κάντε canary deployment με παρατηρησιμότητα

Αναπτύξτε τη νέα baseline σε μικρό ποσοστό instances, κρατώντας έτοιμο το προηγούμενο image μόνο για λειτουργικό rollback. Παρακολουθήστε error rate, TLS failures, startup time, memory, garbage collection και ασυνήθιστες εξαιρέσεις. Ένα rollback μπορεί να αποκαταστήσει διαθεσιμότητα, αλλά δεν αποτελεί μόνιμη λύση για γνωστή ευπάθεια· το αποτέλεσμα πρέπει να είναι νέο συμβατό build, όχι παραμονή στην παλιά baseline.

4. Κλείστε τα κενά του επόμενου κύκλου

Μετά το production rollout, αφαιρέστε παλιά images και installers από τα συνήθη deployment paths, ενημερώστε τα build constraints και δημιουργήστε alert για runtimes κάτω από την εγκεκριμένη baseline. Η διαδικασία μπορεί να γίνει ένα μικρό αλλά ουσιαστικό engineering project, όπως και άλλα projects για developer portfolio: ένα inventory script, policy check στο CI και dashboard patch compliance δείχνουν πρακτική κατανόηση λειτουργίας και ασφάλειας.

Τι να προσέξουν οι ομάδες αυτή την εβδομάδα

Το κρίσιμο δεν είναι να αλλάξει απλώς ο αριθμός έκδοσης. Η ομάδα πρέπει να αποδείξει ποια runtime instances αναβαθμίστηκαν, τι δοκιμάστηκε και ποια εξαίρεση παραμένει προσωρινά. Εάν μια εφαρμογή δεν μπορεί να περάσει στη νέα baseline, καταγράψτε τον λόγο, περιορίστε την έκθεσή της και ορίστε συγκεκριμένη ημερομηνία διόρθωσης. Παράλληλα, αποφύγετε ανεπίσημα binaries και χρησιμοποιήστε το υποστηριζόμενο distribution και τη διαδικασία ενημέρωσης που ταιριάζει στην άδεια και στην πλατφόρμα σας.

Για τους περισσότερους οργανισμούς, η σωστή σειρά είναι απλή: inventory σήμερα, δοκιμή στο CI και staging, canary rollout, πλήρης ανάπτυξη και έλεγχος ότι δεν έμειναν ξεχασμένα runtimes. Με 17 από τις 19 ευπάθειες να έχουν πιθανό network path χωρίς credentials, η αναβολή μέχρι τον επόμενο μεγάλο release κύκλο δεν είναι καλή επιλογή. Το July CPU είναι συντήρηση ασφαλείας που πρέπει να αντιμετωπιστεί ως κανονική εργασία παραγωγής.

Επίσημες πηγές

• Oracle Critical Patch Update Advisory — July 2026
• Oracle Java Management release notes για το July CPU
• JDK 26.0.2 release notes και security baselines