Στις 21 Οκτωβρίου 2026 η ομάδα της PHP έβγαλε βιαστικά διορθώσεις για δύο κενά ασφαλείας που έμειναν γνωστά ως PHP2Shell. Δεν ήταν άλλη μια ενημέρωση ρουτίνας. Μιλάμε για σφάλματα που αφήνουν κάποιον να τρέξει δικό του κώδικα σε έναν server χωρίς λογαριασμό και χωρίς κωδικό, και η PHP κινεί τα περισσότερα sites στον κόσμο. Το ζήτημα αφορούσε σχεδόν τους πάντες, μαζί και αρκετά από τα sites που διαχειριζόμαστε.
Τι ήταν το κενό
Δύο κωδικοί, ο CVE-2026-109618 και ο CVE-2026-109619, και οι δύο με βαθμολογία 9.2 στα 10. Η κατηγορία είναι η χειρότερη που υπάρχει: απομακρυσμένη εκτέλεση κώδικα χωρίς πιστοποίηση. Ο επιτιθέμενος μπορούσε είτε να εκτελέσει εντολές στον server, είτε να διαβάσει κομμάτια της μνήμης του, εκεί ακριβώς που περνούν κωδικοί, tokens, κλειδιά και πιστοποιητικά.
Το ενδιαφέρον είναι πού κρύβεται το λάθος. Δεν είναι σε κάποιο plugin ούτε σε κακογραμμένο κώδικα εφαρμογής. Είναι μέσα στην ίδια τη μηχανή της PHP, στον τρόπο που καθαρίζει τα πράγματα όταν ένα αίτημα σκάει στη μέση, συνήθως επειδή ξεμένει από μνήμη. Μένει πίσω μισοφτιαγμένη εσωτερική κατάσταση, και το επόμενο αίτημα που πέφτει στον ίδιο worker τη βρίσκει εκεί και την ακουμπάει. Από εκεί ξεκινά η διαρροή ή η αλλοίωση μνήμης. Στα επιμέρους εμπλέκονται το upload progress, ένα session cookie που διαρρέει μνήμη ακόμη κι όταν το site δεν ανοίγει καν session, και το κοινόχρηστο OPcache.
Το μέγεθος εξηγεί και τον πανικό. Η PHP τρέχει γύρω στο 70% του web, και επηρεάζονται όλοι οι τρόποι που σερβίρεται: Apache mod_php, PHP-FPM, php-cgi, LiteSpeed, FrankenPHP. Ερευνητές το έδειξαν να δουλεύει σε φρέσκα WordPress, Drupal και Joomla. Αφού το πρόβλημα κάθεται κάτω από την εφαρμογή, δεν σε σώζει το πόσο καθαρός είναι ο δικός σου κώδικας.
Το κενό το εντόπισε ομάδα ερευνητών (Wiz Research) με τη βοήθεια μοντέλων AI, το πρώτο κομμάτι ήδη από τον Αύγουστο. Οι λεπτομέρειες διέρρευσαν δύο μέρες νωρίτερα από το σχεδιασμένο, κι έτσι η διόρθωση βγήκε στις 21 Οκτωβρίου αντί για τις 22. Στο μεταξύ οι επιθέσεις είχαν ήδη αρχίσει. Honeypots κατέγραψαν εκμετάλλευση από την πρώτη κιόλας μέρα, ενώ δίκτυο της Amazon είχε πιάσει απόπειρα από τις 17 Οκτωβρίου, πριν καν βγει η ανακοίνωση. Η αμερικανική CISA το χαρακτήρισε ενεργά εκμεταλλευόμενο στις 26 Οκτωβρίου.
Τι έκαναν οι πάροχοι
Η λύση ήταν μία και ξεκάθαρη: αναβάθμιση σε PHP 8.5.12, 8.4.27, 8.3.36 ή 8.2.35 και επανεκκίνηση όλων των PHP workers. Καμία ρύθμιση δεν κάλυπτε πλήρως το πρόβλημα.
Στον κόσμο του cPanel, η CloudLinux κυκλοφόρησε διορθωμένα πακέτα ea-php και alt-php, και το Imunify360 πρόσθεσε κανόνες που έκοβαν κάποιες διαδρομές επίθεσης. Οι κανόνες όμως δεν έπιαναν και τα δύο κενά, οπότε το update παρέμενε η μόνη πραγματική απάντηση. Υπήρξε και μια παγίδα που μπέρδεψε πολλούς: τα EasyApache builds διορθώθηκαν με backport πάνω στο παλιό νούμερο έκδοσης. Ένα ea-php84 μπορεί να έδειχνε ακόμα 8.4.26 ενώ ήταν ήδη patched. Το νούμερο δεν έλεγε την αλήθεια, το changelog και το CVE την έλεγαν.
Το LiteSpeed σε cPanel δουλεύει με τα ίδια πακέτα, άρα κάλυπτε το ίδιο update με μια επανεκκίνηση της υπηρεσίας. Οι διανομές Linux πήραν τα patches πριν ακόμα τη δημόσια κυκλοφορία. Και μια λεπτομέρεια που κόστισε σε αρκετούς: τα αυτόματα security updates κάποιων πλατφορμών δεν αγγίζουν την PHP. Το ξεκαθάρισε και η Laravel Forge. Η ενημέρωση της PHP είναι ξεχωριστή κίνηση, δεν έρχεται μόνη της μαζί με τα υπόλοιπα.
Τι κάναμε εμείς
Το βάλαμε πάνω από όλα τα άλλα της ημέρας. Πρώτα βγάλαμε λίστα: ποιο site τρέχει ποια έκδοση PHP και σε ποιον πάροχο. Μετά επιβεβαιώσαμε για το καθένα ότι το build είχε όντως το patch, κοιτώντας changelog και CVE αντί για το νούμερο έκδοσης. Όπου χρειάστηκε, κάναμε restart τους workers (PHP-FPM, Apache ή LiteSpeed), γιατί αλλιώς οι διεργασίες που ήδη έτρεχαν κρατούσαν το παλιό binary και η διόρθωση απλώς δεν ίσχυε. Σε όσα sites ο πάροχος αργούσε, βάλαμε προσωρινά φρένα, κανόνες WAF και περιορισμό πρόσβασης, μέχρι να έρθει το κανονικό update. Και κρατήσαμε ένα μάτι στα logs για τα σημάδια που είχαν περιγραφεί: αλλόκοτα ή υπερμεγέθη PHPSESSID cookies, σφάλματα ορίου μνήμης, συνεχόμενα 500, workers που έπεφταν και ξανανέβαιναν χωρίς λόγο.
Τι κρατάμε από όλο αυτό
Το νούμερο έκδοσης δεν είναι απόδειξη. Με backport, η έκδοση μένει ίδια και δείχνει παλιά ενώ είναι ασφαλής. Κοιτάμε changelog.
Η PHP και η εφαρμογή ενημερώνονται χωριστά. Ένα update στο WordPress ή στο Laravel δεν πειράζει την PHP, και το ανάποδο.
Χωρίς restart δεν κουνιέται τίποτα. Μέχρι να ξαναξεκινήσουν οι workers, συνεχίζει να τρέχει το παλιό binary.
Κάποια προβλήματα κάθονται κάτω από τον κώδικά σου. Και το πιο προσεγμένο site εκτίθεται αν η μηχανή από κάτω έχει τρύπα.
Ο χρόνος αντίδρασης μίκρυνε. Με AI και στην εύρεση και στην κατασκευή του exploit, οι επιθέσεις αρχίζουν σχεδόν ταυτόχρονα με την ανακοίνωση, μερικές φορές και πριν. Εδώ υπήρχε απόπειρα πριν βγει τίποτα δημόσια.
Το WAF αγοράζει χρόνο, δεν τελειώνει τη δουλειά. Είναι ασπίδα ανάσας μέχρι το update, όχι το ίδιο το update.
Η παλιά PHP δεν έχει δίχτυ. Οι εκδόσεις 7.x και οι πολύ παλιές 8.x δεν πήραν επίσημη διόρθωση. Το να είσαι σε 8.2 και πάνω είναι η βάση, όχι η εξαίρεση.
Τέτοια περιστατικά θα ξανασυμβούν. Αυτό που κάνει τη διαφορά είναι να ξέρεις ανά πάσα στιγμή τι τρέχει κάθε site και να έχεις ποιον να πάρεις όταν χτυπήσει το επόμενο. Αν δεν είσαι σίγουρος τι έκδοση PHP έχει το δικό σου και αν είναι ενημερωμένο, το κοιτάμε μαζί.
Πηγές: Wiz Research, watchTowr, Help Net Security, CISA, CloudLinux, Imunify360, Laravel Forge, CERT-EU.
