Εν ολίγοις: Πολλές συμβουλές για το PHP2Shell που κυκλοφορούν αυτή την περίοδο σε φόρουμ και κοινωνικά δίκτυα δεν προστατεύουν ή και βλάπτουν: αποκλεισμός αιτημάτων με cookie συνεδρίας, απόκρυψη μηνυμάτων σφάλματος, ρύθμιση μέσω .user.ini ή ενημέρωση μόνο του CMS. Το php.net είναι σαφές: δεν υπάρχουν πλήρη προσωρινά μέτρα, η ενημέρωση της PHP με επανεκκίνηση όλων των διεργασιών είναι ο μόνος ασφαλής δρόμος.
Γιατί οι λανθασμένες συμβουλές είναι επικίνδυνες σε αυτή την κατάσταση
Σε μια κρίσιμη ευπάθεια με μεγάλη προσοχή δημιουργείται αγορά για γρήγορες λύσεις. Οι συμβουλές μοιράζονται, συντομεύονται και προωθούνται, συχνά χωρίς τους περιορισμούς της αρχικής πηγής. Στο PHP2Shell προστίθεται ότι λεπτομέρειες έγιναν, σύμφωνα με αναφορές, γνωστές πριν από την επίσημη ημερομηνία και η κατάσταση τις πρώτες ημέρες ήταν συγκεχυμένη.
Μια λανθασμένη συμβουλή βλάπτει διπλά. Αφήνει την ευπάθεια ανοιχτή και δημιουργεί την αίσθηση ότι κάτι έγινε. Ακριβώς αυτή η αίσθηση οδηγεί στο να μένει η πραγματική ενημέρωση στην άκρη. Ορισμένες συμβουλές παραλύουν επιπλέον τον ίδιο τον ιστότοπό σας.
Εννέα συμβουλές υπό έλεγχο
Ο παρακάτω πίνακας συνοψίζει όσα διαβάσαμε συχνά τις τελευταίες ημέρες και τα αντιπαραβάλλει με τις δηλώσεις των πρωτογενών πηγών.
| Συμβουλή που κυκλοφορεί | Γιατί δεν στέκει | Τι ισχύει αντί γι' αυτό |
|---|---|---|
Αποκλεισμός όλων των αιτημάτων με PHPSESSID |
Απορρίπτεται ρητά από ειδικούς συντάκτες· παραλύει συνδέσεις και καλάθια αγορών | Ενημέρωση της PHP |
Το session.upload_progress.enabled=0 αρκεί |
Σύμφωνα με εξειδικευμένες αναφορές δεν κλείνει και τις δύο ευπάθειες | Λογικό προσωρινό μέτρο, η ενημέρωση παραμένει υποχρέωση |
Ορισμός τιμών μέσω ini_set() ή .user.ini |
Το php.net το αποτρέπει ρητά | Στον διακομιστή, σε php.ini, pool FPM ή διαμόρφωση διακομιστή |
| Απόκρυψη μηνυμάτων σφάλματος | Σύμφωνα με το php.net δεν βοηθούν τα error_reporting, display_errors ή @ |
Ενημέρωση· η έξοδος σφαλμάτων δεν πρέπει πάντως να εμφανίζεται δημόσια |
Περιορισμός μνήμης μέσω RLIMIT_AS ή RLIMIT_DATA |
Το php.net προειδοποιεί ότι ακριβώς αυτό μπορεί να προκαλέσει την ευάλωτη κατάσταση | Όριο μέσω container ή cgroup |
| Ενημέρωση του WordPress ή των plugin | Η ευπάθεια βρίσκεται στον διερμηνέα PHP και όχι στο CMS | Ενημέρωση του περιβάλλοντος εκτέλεσης PHP |
| Η Cloudflare ή άλλο WAF αρκεί | Προστασία μόνο για κίνηση μέσω της υπηρεσίας· άμεσα προσβάσιμοι διακομιστές μένουν ανοιχτοί | WAF ως πρόσθετο επίπεδο και όχι ως υποκατάστατο |
| Επαναφόρτωση αντί για επανεκκίνηση της υπηρεσίας | Σύμφωνα με την Red Hat μια επαναφόρτωση δεν αρκεί, οι υπάρχοντες workers μπορεί να κρατούν την παλιά κατάσταση | Πλήρης επανεκκίνηση όλων των workers |
| Με patch σημαίνει καθαρός | Ένα patch δεν αφαιρεί κακόβουλο λογισμικό που εισήχθη νωρίτερα | Διάσωση logs από τις 20/10 και έλεγχος για ίχνη |
Οι τρεις συχνότερες παρανοήσεις με περισσότερη εξήγηση
Η απαγόρευση cookie
Η συμβουλή να απορρίπτονται όλα τα αιτήματα με το cookie συνεδρίας PHPSESSID ακούγεται τεχνική και αποφασιστική. Ειδικοί συντάκτες την απορρίπτουν ρητά. Στην πράξη χαλά ό,τι χρειάζεται συνεδρία: λογαριασμούς πελατών, καλάθια αγορών, περιοχές διαχείρισης, φόρμες με προστασία από πλαστογράφηση. Προστασία από την ευπάθεια δεν είναι.
Η μία ρύθμιση που τα λύνει όλα
Το session.upload_progress.enabled=0 περιλαμβάνεται στις συστάσεις του php.net και είναι η αναφερόμενη αντιμετώπιση για την CVE-2026-115560. Σε ορισμένα άρθρα έγινε από αυτό «το PHP2Shell απενεργοποιήθηκε». Σύμφωνα με εξειδικευμένες αναφορές, αυτή η ρύθμιση μόνη της δεν κλείνει όμως και τις δύο ευπάθειες. Και το memory_limit=-1 αφαιρεί, σύμφωνα με το php.net, μόνο τον ελεγχόμενο μηχανισμό ενεργοποίησης· ένα σφάλμα μνήμης σε βαθύτερο επίπεδο μπορεί να φτάσει παρ' όλα αυτά στην ευάλωτη διαδρομή. Στην PHP 8.5 το fatal_error_backtraces=0 αποκλείει, σύμφωνα με το php.net, μόνο την επιβεβαιωμένη διαδρομή μέσω backtraces.
Πώς ορίζετε παρ' όλα αυτά τη ρύθμιση σωστά και μόνιμα, περιγράφει το άρθρο Απενεργοποίηση του session.upload_progress. Την πλήρη λίστα των προσωρινών μέτρων θα βρείτε στα Άμεσα μέτρα χωρίς patch.
Η ασπίδα μπροστά
Η Cloudflare έχει, σύμφωνα με δικές της δηλώσεις, ενεργούς κανόνες προστασίας από τις 21 Οκτωβρίου, και για πελάτες του δωρεάν πακέτου. Η ίδια η Cloudflare επισημαίνει όμως όρια: η προστασία ισχύει μόνο για κίνηση που περνά μέσω Cloudflare. Αν ο διακομιστής προέλευσης είναι άμεσα προσβάσιμος, παρακάμπτεται. Επιπλέον η Cloudflare ελέγχει και την απάντηση του διακομιστή, επειδή το αίτημα μόνο του δεν αρκεί πάντα. Γιατί ένα WAF δεν αντικαθιστά την ενημέρωση, εξηγεί το άρθρο WAF ή ενημέρωση.
Μια συμβουλή με ρίσκο: φιλτράρισμα αιτημάτων μεταφόρτωσης στα όρια
Δεν είναι λανθασμένη κάθε άβολη συμβουλή. Ειδικοί συντάκτες προτείνουν ως προσωρινό, ανεπίσημο μέτρο τον αποκλεισμό αιτημάτων multipart/form-data εκτός πραγματικών διαδρομών μεταφόρτωσης στο proxy ή στο WAF. Αυτό μπορεί να μικρύνει την επιφάνεια επίθεσης, χαλά όμως φόρμες και μεταφορτώσεις αν η λίστα των επιτρεπόμενων διαδρομών είναι ελλιπής.
Όποιος ακολουθήσει αυτόν τον δρόμο, πρέπει να τον ελέγξει προηγουμένως σε περιβάλλον δοκιμών, να τον συνεννοηθεί με τα επιχειρησιακά τμήματα και να τον τεκμηριώσει ως χρονικά περιορισμένο μέτρο. Ούτε αυτός αντικαθιστά την ενημέρωση.
Πολλές λύσεις WAF προσφέρουν γι' αυτό λειτουργία παρατήρησης, όπου οι κανόνες αρχικά μόνο καταγράφουν αντί να αποκλείουν. Αφήστε έναν νέο κανόνα να λειτουργήσει έτσι για μερικές ημέρες και αξιολογήστε ποια νόμιμα αιτήματα θα επηρεάζονταν. Μόνο μετά περάστε σε αποκλεισμό. Έτσι αποφεύγετε να αχρηστευτούν απαρατήρητα φόρμες αιτήσεων, πύλες πελατών ή η μεταφόρτωση εικόνων στο κατάστημα.
Πώς ελέγχετε μια συμβουλή προτού την εφαρμόσετε
Τέσσερα ερωτήματα ξεχωρίζουν τις χρήσιμες από τις επικίνδυνες συμβουλές:
- Πηγή: Προέρχεται η σύσταση από το php.net, τη διανομή σας, τη BSI (Ομοσπονδιακή Υπηρεσία Ασφάλειας Πληροφορικής της Γερμανίας) ή από ειδικό συντάκτη που κατονομάζεται;
- Αξίωση: Περιγράφεται το μέτρο ως προσωρινό ή ως λύση; Στο PHP2Shell μόνο η ενημέρωση είναι λύση.
- Παρενέργεια: Τι χαλά όταν το μέτρο ισχύει; Μια συμβουλή χωρίς υπόδειξη παρενεργειών είναι ελλιπής.
- Τόπος υλοποίησης: Ορίζεται η ρύθμιση στον διακομιστή και με τρόπο που δεν αντικαθίσταται, ακολουθούμενη από επανεκκίνηση όλων των workers;
Καταγράψτε ποια προσωρινά μέτρα εφαρμόσατε και πότε. Έτσι μπορείτε αργότερα να τα ελέγξετε στοχευμένα και να διαπιστώσετε αν μια υποτιθέμενη προστασία καθυστέρησε την πραγματική ενημέρωση.
Πώς βοηθά συγκεκριμένα η PHP SOS;
- Ελέγχουμε τα μέτρα που έχουν ήδη υλοποιηθεί σε εσάς και ξεχωρίζουμε τα αποτελεσματικά από τα αναποτελεσματικά.
- Εγκαθιστούμε την ενημέρωση της PHP, επανεκκινούμε όλες τις διεργασίες και τεκμηριώνουμε την κατάσταση.
- Όπου η ενημέρωση δεν είναι ακόμη δυνατή, ορίζουμε προσωρινά μέτρα σύμφωνα με το php.net στον διακομιστή και τεκμηριωμένα.
- Με το WAF και εικονικό patching συμπληρώνουμε την προστασία στα όρια, χωρίς να αντικαθιστούμε την ενημέρωση.
Συχνές ερωτήσεις
Προστατεύει ο αποκλεισμός αιτημάτων με PHPSESSID;
Όχι. Ειδικοί συντάκτες απορρίπτουν ρητά αυτή τη συμβουλή που κυκλοφορεί. Παραλύει συνδέσεις, καλάθια αγορών και φόρμες, χωρίς να κλείνει την ευπάθεια στον διερμηνέα.
Αρκεί το session.upload_progress.enabled=0 ενάντια στο PHP2Shell;
Όχι. Η ρύθμιση είναι ένα από αρκετά προσωρινά μέτρα και, σύμφωνα με εξειδικευμένες αναφορές, δεν κλείνει και τις δύο ευπάθειες. Έχει νόημα, αλλά δεν αντικαθιστά την ενημέρωση της PHP.
Βοηθά η απενεργοποίηση του display_errors;
Για το PHP2Shell όχι. Το php.net επισημαίνει ότι η απόκρυψη διαγνωστικών μέσω error_reporting, display_errors ή του τελεστή @ δεν βοηθά. Στην παραγωγή το display_errors πρέπει παρ' όλα αυτά να είναι απενεργοποιημένο για άλλους λόγους.
Από τι αναγνωρίζω μια σοβαρή συμβουλή;
Μια σοβαρή συμβουλή αναφέρει την πηγή της, περιγράφει όρια και χαρακτηρίζει τα προσωρινά μέτρα ως τέτοια. Όποιος υπόσχεται ότι μία μεμονωμένη ρύθμιση καθιστά περιττή την ενημέρωση, κάνει λάθος στο PHP2Shell.