Εν συντομία: Μετά το PHP2Shell, η έκδοση PHP που εμφανίζεται αποδεικνύει από μόνη της λίγα, επειδή οι πάροχοι φιλοξενίας εφαρμόζουν συχνά τις διορθώσεις ως backport. Ζητήστε γι' αυτό γραπτή επιβεβαίωση ενημέρωσης PHP από τον πάροχο: επίπεδο πακέτου ανά κλάδο PHP, χρονική στιγμή της εγκατάστασης και επανεκκίνηση όλων των διεργασιών PHP. Ένα υπόδειγμα προς αντιγραφή θα βρείτε παρακάτω.
Γιατί μετράει τώρα μια γραπτή επιβεβαίωση
Στις 21.10.2026 το έργο PHP δημοσίευσε τα patches για δύο κρίσιμες ευπάθειες, γνωστές με το όνομα PHP2Shell. Και οι δύο επιτρέπουν την απομακρυσμένη εκτέλεση κακόβουλου κώδικα χωρίς σύνδεση. Το BSI (η γερμανική Ομοσπονδιακή Υπηρεσία Ασφάλειας Πληροφοριών) κήρυξε επίπεδο προειδοποίησης 3 / πορτοκαλί και συνιστά την άμεση ενημέρωση.
Όποιος φιλοξενεί τον ιστότοπό του σε πάροχο συχνά δεν μπορεί να εφαρμόσει μόνος του την ενημέρωση. Ταυτόχρονα, ως διαχειριστής φέρετε την ευθύνη για τα δεδομένα των πελατών σας. Μια γραπτή, συγκεκριμένη επιβεβαίωση του παρόχου είναι γι' αυτό κάτι περισσότερο από διατύπωση. Αποτελεί συστατικό της τεκμηρίωσής σας, π.χ. έναντι των υπευθύνων προστασίας δεδομένων, των ασφαλιστών ή της διοίκησης.
Προστίθεται και το εξής: ένα patch δεν αφαιρεί κακόβουλο λογισμικό που εισήχθη νωρίτερα. Σύμφωνα με δημοσιεύματα, υπήρξε ήδη στις 17.10. μια πρώτη παρατηρημένη απόπειρα επίθεσης. Η ακριβής χρονική στιγμή κατά την οποία ο διακομιστής σας προστατεύτηκε είναι γι' αυτό σημαντική για το ερώτημα αν πρέπει να συνεχίσετε τον έλεγχο.
Γιατί δεν αρκεί η έκδοση PHP που εμφανίζεται
Διορθώθηκαν οι PHP 8.5.12, 8.4.27, 8.3.36 και 8.2.35. Πολλές διανομές και πάροχοι ενσωματώνουν όμως τη διόρθωση ως backport στο δικό τους πακέτο. Τότε μια διεπαφή όπως το Plesk εμφανίζει ακόμη 8.2.34, παρόλο που ο διακομιστής είναι ενημερωμένος.
Αντίστροφα, ένας σωστός αριθμός έκδοσης μπορεί να παραπλανήσει. Τα νέα αρχεία μόνα τους δεν προστατεύουν όσο παλιές διεργασίες PHP εκτελούνται στη μνήμη. Μόνο μετά από επανεκκίνηση όλων των workers είναι ενεργή η νέα κατάσταση. Περισσότερα στην ενότητα Σωστός έλεγχος έκδοσης PHP και επιπέδου patch.
| Δήλωση του παρόχου | Τι αποδεικνύει | Τι λείπει ακόμη |
|---|---|---|
| «Όλα τα συστήματα είναι ενημερωμένα.» | λίγα | Έκδοση ή επίπεδο πακέτου, ημερομηνία, επανεκκίνηση |
| «Η PHP 8.3.36 είναι εγκατεστημένη.» | Έκδοση | Ημερομηνία, επανεκκίνηση, επηρεαζόμενοι διακομιστές |
| «Backport στο πακέτο xy, επανεκκίνηση στις …» | Patch και ενεργοποίηση | ενδεχομένως στοιχεία για την PHP 8.1 και παλαιότερες |
Ποια στοιχεία χρειάζεστε από τον πάροχο
Ζητήστε απαντήσεις στα παρακάτω σημεία, κατά το δυνατόν ανά ιστότοπο ή σύμβαση:
- Ποιοι κλάδοι και εκδόσεις PHP είναι ενεργοί για τους ιστοτόπους σας, ακόμη και παλαιότεροι που εκτελούνται μόνο για μεμονωμένους καταλόγους;
- Περιλαμβάνονται οι διορθώσεις για τα CVE-2026-109618 και CVE-2026-109619, ως επίσημη έκδοση ή ως backport;
- Πότε εγκαταστάθηκε η ενημέρωση και πότε επανεκκινήθηκαν όλες οι διεργασίες PHP (pools FPM, Apache, LiteSpeed);
- Είναι απενεργοποιημένο το
session.upload_progress.enabledλόγω του CVE-2026-115560; - Ποιον τρόπο λειτουργίας χρησιμοποιεί το πακέτο σας, π.χ. PHP-FPM ή Apache με mod_php; Στο mod_php η ομάδα της PHP βλέπει τον υψηλότερο κίνδυνο.
- Ποια logs πρόσβασης και σφαλμάτων από τις 20.10.2026 διατηρούνται και πώς μπορείτε να τα λάβετε;
Αν ένας ιστότοπος εκτελείται ακόμη σε PHP 8.1 ή παλαιότερη, ρωτήστε ξεχωριστά. Για αυτούς τους κλάδους δεν υπάρχουν πλέον επίσημες ενημερώσεις, μόνο ελάχιστα backports του πηγαίου κώδικα για τις 7.4, 8.0 και 8.1.
Υπόδειγμα: αίτημα επιβεβαίωσης ενημέρωσης PHP από τον πάροχο
Αντιγράψτε το κείμενο σε ένα αίτημα υποστήριξης (ticket) ή σε ένα email προς τον πάροχό σας. Συμπληρώστε τα στοιχεία σε αγκύλες.
Θέμα: Αίτημα επιβεβαίωσης για την κατάσταση του patch PHP (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)
Καλησπέρα σας,
διατηρούμε σε εσάς τους εξής ιστοτόπους / συμβάσεις:
[Αριθμός πελάτη, σύμβαση, domains]
Σε σχέση με τις ευπάθειες ασφαλείας της PHP CVE-2026-109618 και
CVE-2026-109619 (PHP2Shell, patches της 21.10.2026) καθώς και την
ανακοίνωση για το CVE-2026-115560 της 23.10.2026, παρακαλούμε για
γραπτή επιβεβαίωση των εξής σημείων:
1. Ποιες εκδόσεις PHP ή επίπεδα πακέτων είναι ενεργά για τους ιστοτόπους μας;
2. Περιλαμβάνουν τις διορθώσεις (επίσημη έκδοση ή backport);
3. Ημερομηνία και ώρα της εγκατάστασης.
4. Ημερομηνία και ώρα της επανεκκίνησης όλων των διεργασιών PHP (FPM,
Apache, LiteSpeed ή παρόμοιες).
5. Είναι το session.upload_progress.enabled απενεργοποιημένο σε επίπεδο
διακομιστή;
6. Ποιος τρόπος λειτουργίας PHP χρησιμοποιείται (π.χ. PHP-FPM, mod_php);
7. Διατηρούνται logs πρόσβασης και σφαλμάτων από τις 20.10.2026 και
πώς μπορούμε να τα λάβουμε;
8. Αν κάποιος ιστότοπος χρησιμοποιεί ακόμη PHP 8.1 ή παλαιότερη: Ποια
προστασία υπάρχει εκεί και ποια μετάβαση προτείνετε;
Χρειαζόμαστε τα στοιχεία για την εσωτερική μας τεκμηρίωση.
Ευχαριστούμε εκ των προτέρων και με εκτίμηση
[Όνομα, εταιρεία, ιδιότητα]
Πώς αξιολογείτε σωστά την απάντηση και πώς κάνετε δικό σας έλεγχο
Μια καλή απάντηση αναφέρει συγκεκριμένα επίπεδα, ημερομηνίες και ώρες. Γενικές διατυπώσεις όπως «αντιδράσαμε» δεν αρκούν για τον φάκελό σας. Σε αυτή την περίπτωση ρωτήστε ευγενικά για τα σημεία που λείπουν.
Αν το πακέτο σας το επιτρέπει, ελέγξτε επιπλέον μόνοι σας. Με πρόσβαση SSH συνήθως αρκούν οι εξής εντολές:
# Έκδοση της γραμμής εντολών (μπορεί να διαφέρει από την έκδοση του ιστού)
php -v
# Επίπεδο πακέτων σε Debian/Ubuntu
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Επίπεδο πακέτων σε RHEL, Alma, Rocky
rpm -qa | grep -i php
# Από πότε εκτελούνται οι διεργασίες PHP-FPM;
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Αν η χρονική στιγμή εκκίνησης των διεργασιών PHP είναι πριν από την επιβεβαιωμένη ημερομηνία εγκατάστασης, η επανεκκίνηση δεν ήταν πλήρης.
Όταν ο πάροχος δεν απαντά ή απαντά αόριστα
Αν η απάντηση καθυστερεί ή λείπουν τα καθοριστικά στοιχεία, δεν πρέπει να θεωρήσετε το ζήτημα ξεκαθαρισμένο. Το BSI συνιστά την προσωρινή απομάκρυνση των διακομιστών ιστού από το δίκτυο, όταν η ενημέρωση δεν είναι άμεσα εφικτή. Το αν αυτό είναι αναλογικό για τον ιστότοπό σας, το αποφασίζει η διοίκηση, ιδανικά γραπτώς και με ημερομηνία.
Παράλληλα αξίζει να ελέγξετε για πιθανά ίχνη επίθεσης, επειδή η χρονική στιγμή του patch παραμένει ανοιχτή. Ενδείξεις δίνει το άρθρο Έχω ήδη παραβιαστεί;. Χωρίς πρόσβαση SSH, η γραπτή επιβεβαίωση παραμένει το σημαντικότερο τεκμήριό σας. Ποιες υποχρεώσεις ανήκουν στον πάροχο και ποιες σε εσάς, εξηγεί η σελίδα Shared hosting: τι κάνει ο πάροχος· για διακομιστές με διαχείριση βοηθά η σελίδα Managed server: διευκρίνιση της ευθύνης.
Αποθηκεύστε το αίτημα, την απάντηση και τα δικά σας αποτελέσματα ελέγχου, με ημερομηνία, σε έναν φάκελο. Αυτός ο φάκελος θα βοηθήσει αργότερα σε ερωτήματα ασφαλιστών ή υπευθύνων προστασίας δεδομένων.
Πώς βοηθά συγκεκριμένα η PHP SOS;
- Διατυπώνουμε μαζί σας το αίτημα προς τον πάροχο και αξιολογούμε τεχνικά την απάντηση.
- Όπου υπάρχει πρόσβαση, ελέγχουμε οι ίδιοι το επίπεδο των πακέτων, τον ενεργό τρόπο λειτουργίας και την επανεκκίνηση των διεργασιών PHP.
- Αν παραμένουν κενά, εφαρμόζουμε προσωρινά μέτρα ή σχεδιάζουμε τη μετάβαση σε υποστηριζόμενη έκδοση.
- Καταγράφουμε το αποτέλεσμα και τις χρονικές στιγμές σε μια τεκμηρίωση που μπορείτε να προωθήσετε εσωτερικά.
Πώς εξελίσσεται η ενημέρωση με επανεκκίνηση και τεκμηρίωση, περιγράφει η υπηρεσία PHP patch που προσφέρουμε.
Συχνές ερωτήσεις
Αρκεί να μου γράψει ο πάροχος ότι όλα είναι ενημερωμένα;
Για την τεκμηρίωσή σας μάλλον όχι. Ζητήστε συγκεκριμένα στοιχεία: επίπεδο πακέτου ή έκδοση ανά κλάδο PHP, ημερομηνία εγκατάστασης και ημερομηνία επανεκκίνησης όλων των διεργασιών PHP. Μόνο έτσι μπορείτε να περιορίσετε το χρονικό παράθυρο της ευπάθειας.
Γιατί η διεπαφή φιλοξενίας μου εμφανίζει ακόμη PHP 8.2.34;
Διανομές και πάροχοι φιλοξενίας εφαρμόζουν διορθώσεις ασφαλείας ορισμένες φορές ως backport, χωρίς να αλλάξουν τον αριθμό έκδοσης. Το Plesk μπορεί τότε να εμφανίζει ακόμη 8.2.34, παρόλο που ο διακομιστής είναι ενημερωμένος. Σαφή εικόνα δίνει μόνο η επιβεβαίωση του παρόχου για το επίπεδο των πακέτων.
Τι κάνω αν ο πάροχος δεν απαντά;
Τεκμηριώστε το αίτημά σας με ημερομηνία και ρωτήστε ξανά μετά από εύλογο χρονικό διάστημα. Ελέγξτε παράλληλα αν μπορείτε να εφαρμόσετε μόνοι σας προσωρινά μέτρα και συνεννοηθείτε με τη διοίκηση αν ο ιστότοπος θα αποσυνδεθεί από το δίκτυο μέχρι να ξεκαθαρίσει η κατάσταση, όπως συνιστά το BSI για διακομιστές χωρίς patch.
Κλείνει η ευπάθεια και μια ενημέρωση του WordPress ή του καταστήματος;
Όχι. Το PHP2Shell βρίσκεται στην ίδια την PHP. Μια ενημέρωση του CMS ή του λογισμικού του καταστήματος δεν αλλάζει τίποτα στον διερμηνέα PHP που εκτελείται στον διακομιστή.