Τρέχουσα κατάσταση: PHP2Shell. Δύο κρίσιμες ευπάθειες της PHP (CVSS 9.2) επιτρέπουν κακόβουλο κώδικα χωρίς σύνδεση. Patches από τις 21/10/2026.Τι πρέπει να γίνει τώρα →

Κλείστε αμέσως την ευπάθεια ασφαλείας της PHP

Οι διακομιστές PHP σας είναι ακόμη ανοιχτοί και δεν θέλετε να το διακινδυνεύσετε μόνοι σας; Κλείνουμε την ευπάθεια εξ αποστάσεως: ενημέρωση, επανεκκίνηση, έλεγχος και γραπτό τεκμήριο.

Ημερομηνία 5 λεπτά ανάγνωσηςΆμεση βοήθεια

Εν συντομία: Όποιος θέλει να κλείσει σήμερα την ευπάθεια PHP2Shell της PHP χρειάζεται τέσσερα πράγματα: τη σωστή ενημέρωση, την επανεκκίνηση όλων των διεργασιών PHP, τον έλεγχο για κακόβουλο κώδικα που έχει ήδη εισαχθεί και ένα τεκμήριο. Επηρεάζεστε; Καλέστε μας. Σας βοηθάμε. Αναλαμβάνουμε το έργο εξ αποστάσεως, από το πρώτο μήνυμα.

Δράστε άμεσα

Μη διαγράψετε τίποτα και μη στήσετε τίποτα από την αρχή. Και στο patch ισχύει: πρώτα διάσωση, μετά αλλαγή. Αν έχει ήδη εισβάλει κάτι, χρειαζόμαστε την κατάσταση των αρχείων και των logs. Δηλώστε το περιστατικό και θα καθορίσουμε μαζί σας τη σειρά.

Γιατί η ευπάθεια δεν μπορεί να περιμένει

Οι δύο ευπάθειες CVE-2026-109618 και CVE-2026-109619 βρίσκονται στην ίδια την PHP και επιτρέπουν την εξ αποστάσεως εκτέλεση κακόβουλου κώδικα χωρίς σύνδεση. Το BSI (η γερμανική Ομοσπονδιακή Υπηρεσία Ασφάλειας Πληροφοριών) έχει κηρύξει επίπεδο προειδοποίησης 3 (πορτοκαλί) και συνιστά την άμεση ενημέρωση. Αν αυτό δεν είναι άμεσα εφικτό, οι διακομιστές ιστού πρέπει να τεθούν προσωρινά εκτός δικτύου. Σύμφωνα με δημοσιεύματα, οι πρώτες παρατηρημένες απόπειρες επίθεσης υπήρξαν ήδη πριν από τη δημοσίευση των patches στις 21.10.2026. Η Cloudflare παρατήρησε απόπειρες και ενεργοποίησε κανόνες προστασίας, προειδοποιεί όμως ότι κανόνες που βασίζονται μόνο στα δεδομένα των αιτημάτων δεν αρκούν.

Σημαντικό για τους διαχειριστές: μια ενημέρωση του CMS δεν κλείνει την ευπάθεια της PHP. Σύμφωνα με αναφορές, ούτε το WordPress.org σχεδιάζει ενημέρωση γι' αυτήν, επειδή η ευπάθεια βρίσκεται στον διερμηνέα. Κλείνει μόνο στο επίπεδο της PHP, δηλαδή σε ό,τι εκτελεί πραγματικά ο διακομιστής σας.

Τι κάνετε αμέσως τώρα

  1. Γνωρίστε την έκδοση-στόχο. Διορθωμένες είναι οι PHP 8.5.12, 8.4.27, 8.3.36 και 8.2.35. Η PHP 8.2 φτάνει στο τέλος της υποστήριξης στις 31.12.2026· λάβετε το υπόψη στον προγραμματισμό σας.
  2. Καταγράψτε όλα τα συστήματα. Και δοκιμαστικούς διακομιστές, images containers και παλιά συστήματα που είναι προσβάσιμα από το διαδίκτυο.
  3. Διευκρινίστε την αρμοδιότητα. Στα πακέτα φιλοξενίας και στους διαχειριζόμενους διακομιστές ενημερώνει ο πάροχος. Ρωτήστε γραπτά για την έκδοση και την επανεκκίνηση.
  4. Διατηρήστε τα logs. Από τις 20.10.2026, σύμφωνα με τον εξειδικευμένο Τύπο.
  5. Συμφωνήστε ένα χρονικό παράθυρο. Μια επανεκκίνηση διακόπτει για λίγο τα αιτήματα που εκτελούνται. Ορίστε μια χρονική στιγμή όπου κάποιος μπορεί να παίρνει αποφάσεις.
  6. Μην περιμένετε, αν είναι ανοιχτό. Αν δεν μπορεί να γίνει αμέσως patch, εξετάστε μαζί μας την απομόνωση ή τα προσωρινά μέτρα.

Πώς βοηθά συγκεκριμένα η PHP SOS;

  1. Καταγραφή της κατάστασης: Καταγράφουμε συστήματα, εκδόσεις PHP, τρόπους λειτουργίας, παρόχους φιλοξενίας και προσβασιμότητα και καθορίζουμε τη σειρά: πρώτα τα πιο εκτεθειμένα συστήματα.
  2. Διάσωση και κλείσιμο: Διασώζουμε την υπάρχουσα κατάσταση, εφαρμόζουμε την ενημέρωση ή φέρνουμε τη φιλοξενία στην αποδεδειγμένα διορθωμένη κατάσταση και επανεκκινούμε όλες τις διεργασίες. Στα containers χτίζουμε εκ νέου το image και το αναπτύσσουμε.
  3. Έλεγχος και καθαρισμός: Επειδή ένα patch δεν αφαιρεί κακόβουλο κώδικα, ελέγχουμε για σημάδια προηγούμενης εισβολής και καθαρίζουμε αν χρειάζεται.
  4. Σκλήρυνση και αναφορά: Λαμβάνετε γραπτό τεκμήριο ανά σύστημα και συστάσεις, ώστε η επόμενη ενημέρωση να γίνει πιο γρήγορα. Το φάσμα των υπηρεσιών περιγράφει η Υπηρεσία patch PHP.

Ενημέρωση, επανεκκίνηση, τεκμήριο: τι μετράει

Το συχνότερο λάθος είναι μια ενημέρωση χωρίς επανεκκίνηση. Όσο παλιές διεργασίες εκτελούνται στη μνήμη, ο ευάλωτος κώδικας παραμένει ενεργός, ακόμη κι αν τα αρχεία είναι νέα. Οδηγίες υπάρχουν στη σελίδα Επανεκκίνηση του PHP-FPM και όλων των workers. Το δεύτερο λάθος είναι να πιστεύετε την ένδειξη: οι διανομές και οι πάροχοι φιλοξενίας παρέχουν συχνά backports και τότε ο αριθμός έκδοσης μένει ο ίδιος. Αξιόπιστο είναι το changelog του πακέτου με τους αριθμούς CVE, στην οικογένεια Debian με apt-get changelog <paket>.

Επιπλέον, σύμφωνα με το εγχειρίδιο της PHP, από τις εκδόσεις ασφαλείας και μετά ισχύει η νέα οδηγία memory_hard_limit_percent. Αν μια έκδοση PHP δεν την γνωρίζει, επηρεάζεται. Ο έλεγχος είναι σύντομος:

php -r 'var_dump(ini_get("memory_hard_limit_percent"));'

Πρέπει να εκτελεστεί ανά έκδοση και τρόπο λειτουργίας, επειδή η γραμμή εντολών μπορεί να χρησιμοποιεί άλλη έκδοση PHP από τον διακομιστή ιστού. Στο τέλος καταγράφουμε το αποτέλεσμα, ώστε να μπορείτε να το δείξετε στον πάροχο φιλοξενίας, στην ασφαλιστική εταιρεία ή στον εντολέα σας.

Όταν η ενημέρωση δεν γίνεται αμέσως

Υπάρχουν λόγοι για τους οποίους μια ενημέρωση δεν είναι δυνατή σήμερα: μια παλιά εφαρμογή που δεν λειτουργεί σε νεότερες εκδόσεις PHP, ένας πάροχος φιλοξενίας χωρίς έγκριση, ένα image container σε σταθερό pipeline. Για αυτές τις περιπτώσεις το php.net αναφέρει προσωρινά μέτρα, τα οποία ρητά δεν αποτελούν πλήρη προστασία: ορισμός του memory_limit=-1 έτσι ώστε οι εφαρμογές να μην μπορούν να το αντικαταστήσουν, περιορισμός του post_max_size, session.upload_progress.enabled=0 και στην PHP 8.5 fatal_error_backtraces=0, σε κάθε περίπτωση με επανεκκίνηση. Προστίθενται κανόνες προστασίας στην περίμετρο, οι οποίοι δεν αντικαθιστούν μια ενημέρωση. Μια συμβουλή που κυκλοφορεί, να μπλοκάρονται όλα τα αιτήματα με PHPSESSID, απορρίπτεται ρητά από ειδικούς συγγραφείς.

Ποια μέτρα ταιριάζουν στο σύστημά σας και τι μπορεί να χαλάσουν, το συζητάμε εκ των προτέρων. Περισσότερα στη σελίδα Άμεσα μέτρα όταν δεν μπορείτε ακόμη να κάνετε patch και στο θέμα WAF και εικονικό patching. Για την PHP 8.1 και παλαιότερες ισχύει ξεχωριστή κατάσταση, που περιγράφεται στη σελίδα PHP 8.1 και παλαιότερες: τι ισχύει τώρα.

Τι να μας στείλετε

  • Λίστα των διακομιστών και των παρόχων φιλοξενίας, στο μέτρο που υπάρχει
  • Έξοδος του php -v ανά σύστημα και ένδειξη του τρόπου λειτουργίας
  • Ένδειξη αν χρησιμοποιούνται containers, Plesk, cPanel ή διαχειριζόμενη προσφορά
  • επιθυμητό χρονικό παράθυρο και υπεύθυνο πρόσωπο για τις επανεκκινήσεις
  • Ενδείξεις για ύποπτα φαινόμενα από τις 17.10.2026

Γιατί PHP SOS

Εργαζόμαστε Made in Germany και είμαστε εξειδικευμένοι στην ασφάλεια πληροφορικής εδώ και περισσότερα από 25 χρόνια, με το δίκτυο συνεργατών μας από επαγγελματίες κυβερνοασφάλειας. Έχετε έναν υπεύθυνο επικοινωνίας που συνοδεύει την ενημέρωση, ελέγχει την επανεκκίνηση και παραδίδει το τεκμήριο. Εργαζόμαστε εξ αποστάσεως, χωρίς μετακίνηση, και τεκμηριώνουμε κάθε βήμα. Δεν υποσχόμαστε θαύματα: ένα patch κλείνει την ευπάθεια, δεν αποδεικνύει όμως ότι προηγουμένως δεν συνέβη τίποτα, και αυτό σας το λέμε ανοιχτά.

Επηρεάζεστε; Καλέστε μας. Σας βοηθάμε.

Μην αφήνετε την ευπάθεια ανοιχτή άλλο. Τηλεφωνήστε ή γράψτε μας στο WhatsApp. Αναλαμβάνουμε από το πρώτο μήνυμα και μένουμε μέχρι το περιστατικό να κλείσει και να τεκμηριωθεί. Δηλώστε τώρα το περιστατικό.

Συχνές ερωτήσεις

Μπορώ να κλείσω μόνος μου την ευπάθεια ασφαλείας της PHP ή χρειάζομαι βοήθεια;

Μια ενημέρωση είναι εφικτή για διαχειριστές, αλλά επιρρεπής σε λάθη: πρέπει να αφορά την έκδοση που πράγματι εξυπηρετεί και όλες οι διεργασίες πρέπει να επανεκκινηθούν. Όποιος έχει πολλούς διακομιστές, images containers ή πάροχο φιλοξενίας με ιδιαιτερότητες, κερδίζει χρόνο και αποφεύγει λάθη με υποστήριξη.

Πρέπει να επανεκκινηθεί η PHP μετά την ενημέρωση;

Ναι. Τα νέα αρχεία από μόνα τους δεν αρκούν, όσο παλιές διεργασίες PHP εξακολουθούν να εκτελούνται στη μνήμη. Πρέπει να επανεκκινηθούν όλα τα workers ή οι διεργασίες, στο mod_php ο διακομιστής ιστού.

Τι κάνω, αν δεν υπάρχει ακόμη ενημέρωση για την έκδοση PHP μου;

Για την PHP 8.1 και παλαιότερες το έργο PHP δεν παρέχει πλέον επίσημες ενημερώσεις. Τότε χρειάζονται ένα αποδεδειγμένα διορθωμένο backport του παρόχου, μετάβαση σε έκδοση που συντηρείται ή προσωρινά μέτρα, τα οποία όμως δεν προσφέρουν πλήρη προστασία.

Αρκεί να ορίσω το session.upload_progress.enabled στο 0;

Όχι. Σύμφωνα με τεχνικές αναφορές, η ρύθμιση από μόνη της δεν κλείνει και τις δύο ευπάθειες· η ενημέρωση της PHP παραμένει υποχρεωτική. Ορίστε την μόνο στο php.ini, στο pool του FPM ή στη διαμόρφωση του διακομιστή, όχι με ini_set() ή .user.ini.

Πώς ξέρω ότι η ευπάθεια έχει πράγματι κλείσει μετά;

Με τεκμήριο στο ίδιο το σύστημα που λειτουργεί: έκδοση ή changelog του πακέτου, έλεγχος για τη νέα οδηγία memory_hard_limit_percent και επιβεβαίωση ότι όλες οι διεργασίες επανεκκινήθηκαν μετά την ενημέρωση.

Πηγές

Άμεση επικοινωνία

Κάθε ώρα μετράει. Γράψτε μας τώρα.

Περιγράψτε σύντομα το σύστημα, την έκδοση PHP και ό,τι παρατηρείτε. Θα επικοινωνήσουμε μαζί σας, θα διευκρινίσουμε την κατάσταση και θα εργαστούμε εξ αποστάσεως μέχρι το περιστατικό να κλείσει και να τεκμηριωθεί.

Άμεση βοήθεια