PHP2Shell: αν το site σας τρέχει σε WordPress, ενημερώστε την PHP, όχι τα plugins

Στις 21 Οκτωβρίου το PHP project έβγαλε έκτακτες διορθώσεις για δύο κενά ασφαλείας που έχουν πια και όνομα, PHP2Shell: τα CVE-2026-109618 και CVE-2026-109619, και τα δύο με βαθμολογία 9,2 στα 10. Η έκδοση ήταν προγραμματισμένη για τις 22 και βγήκε μία μέρα νωρίτερα, γιατί οι αριθμοί CVE διέρρευσαν στις 20. Μέσα σε λίγες ώρες κυκλοφορούσαν δημόσια exploits και είχαν ήδη καταγραφεί απόπειρες επίθεσης σε honeypots.

Αν έχετε site σε WordPress, WooCommerce, Joomla, Drupal, Magento ή PrestaShop, τρέχει σε PHP. Άρα αυτό σας αφορά, ακόμα κι αν δεν έχετε γράψει ποτέ ούτε μία γραμμή κώδικα.

Γιατί αυτό είναι διαφορετικό

Οι περισσότεροι πανικοί με το WordPress αφορούν ένα plugin. Ενημερώνετε το plugin και τελειώσατε. Εδώ δεν ισχύει αυτό.

• Το πρόβλημα είναι στην ίδια την PHP, στη μηχανή κάτω από το site. Ένα αίτημα μπορεί να το ενεργοποιήσει πριν καν τρέξει το WordPress ή ο κώδικας του καταστήματος, χωρίς σύνδεση.
• Τα ενημερωμένα plugins και themes δεν σας προστατεύουν. Μόνο μια διορθωμένη έκδοση της PHP.
• Ερευνητές έχουν επιβεβαιώσει απομακρυσμένη εκτέλεση κώδικα χωρίς σύνδεση σε συγκεκριμένες εκδόσεις των WordPress, Drupal, Joomla και Magento.
• Επηρεάζει κάθε συνηθισμένη εγκατάσταση: Apache με mod_php (ο μεγαλύτερος κίνδυνος), PHP-FPM πίσω από nginx, php-cgi, FrankenPHP και LiteSpeed.

Γίνονται όντως επιθέσεις;

Ναι, γίνονται απόπειρες. Πόσες πετυχαίνουν δεν είναι ακόμα σαφές, και προτιμώ να σας το πω έτσι παρά να μαντέψω.

• Η Amazon κατέγραψε απόπειρα PHP2Shell στα honeypots της στις 17 Οκτωβρίου, τέσσερις μέρες πριν από τη διόρθωση, και λέει ότι πλέον γίνεται «ευρεία εκμετάλλευση». Λέει επίσης ότι δεν είναι σαφές αν αυτές οι απόπειρες θα πετύχαιναν σε πραγματικά συστήματα.
• Απόπειρες αναφέρουν και η watchTowr και η Cloudflare.
• Η Sansec θεωρεί πια τη μαζική εκμετάλλευση λιγότερο πιθανή απ' ό,τι φοβόταν αρχικά, γιατί τα δημόσια exploits δεν δουλεύουν σε μια προεπιλεγμένη εγκατάσταση PHP.
• Δεν έχει μπει ακόμα στη λίστα της CISA με τα κενά που αξιοποιούνται ενεργά.

Απόπειρες μέσα σε λίγες ώρες, από περισσότερες από μία ομάδες, μου αρκούν. Αντιμετωπίστε το ως επείγον.

Ποιες εκδόσεις είναι ασφαλείς

• Ασφαλείς: PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 ή νεότερες.
• PHP 7.4 έως 8.1: καμία επίσημη έκδοση, μόνο ελάχιστα patches σε πηγαίο κώδικα από την ομάδα της PHP. Αν ο πάροχός σας τρέχει ακόμα κάποια από αυτές, ρωτήστε τον τι κάνει γι' αυτό, σήμερα.
• PHP 5.4 έως 7.3: καμία διόρθωση.
• Η PHP 8.2 φτάνει στο τέλος υποστήριξης στις 31 Δεκεμβρίου. Αφού θα κάνετε ενημέρωση ούτως ή άλλως, πηγαίνετε σε 8.3 ή νεότερη.

Ο έλεγχος των πέντε λεπτών

1. Ρωτήστε τον πάροχο φιλοξενίας ή κοιτάξτε το panel. Το cPanel, το Plesk και τα περισσότερα panels δείχνουν την έκδοση PHP ανά site. Αν είναι παλαιότερη από τις παραπάνω, ανοίξτε ticket.
2. Αν έχετε δικό σας server, ελέγξτε την έκδοση που σερβίρει πραγματικά η PHP: το php -v δείχνει την PHP της γραμμής εντολών, που δεν είναι πάντα η ίδια με αυτή του site. Μια σελίδα phpinfo() (σβήστε τη μετά) ή το php-fpm8.3 -v δείχνουν την πραγματική.
3. Σε Debian, Ubuntu ή RHEL, η διανομή συχνά διορθώνει την παλιά έκδοση χωρίς να αλλάξει τον αριθμό. Κοιτάξτε την ανακοίνωση ασφαλείας της διανομής για το πακέτο της PHP, όχι μόνο τον αριθμό. Μετά apt upgrade ή dnf upgrade.
4. Κάντε επανεκκίνηση της PHP μετά την ενημέρωση (systemctl restart php8.3-fpm, ή τον Apache για mod_php). Οι παλιοί workers τρέχουν τον παλιό κώδικα μέχρι να το κάνετε.
5. Αν έχετε εταιρεία ή άνθρωπο που φτιάχνει το site, στείλτε του μία γραμμή: «Είναι το site μας σε έκδοση PHP διορθωμένη για το PHP2Shell;» Αν δεν μπορεί να σας απαντήσει σήμερα, αυτή είναι η απάντηση.

Αν δεν μπορείτε να ενημερώσετε σήμερα

Η ομάδα της PHP αναφέρει ρυθμίσεις που δυσκολεύουν την επίθεση (memory_limit=-1 που να μην μπορεί να το αλλάξει η εφαρμογή, session.upload_progress.enabled=0) και λέει καθαρά ότι δεν κάνουν μια εγκατάσταση ασφαλή. Η μόνη πλήρης λύση είναι η ενημέρωση. Η Cloudflare έχει κανόνες firewall για τους γνωστούς τρόπους επίθεσης, που η ίδια τους χαρακτηρίζει προσωρινή λύση.

Τον ίδιο μήνα: nginx

Στις 14 Οκτωβρίου το nginx έβγαλε τις 1.31.7 και 1.30.6 με πέντε διορθώσεις, όλες μεσαίας σοβαρότητας κατά το nginx.org: buffer overflows (alias με rewrite, αποτίμηση script), εισαγωγή δεδομένων στο σώμα αιτήματος μέσω HTTP/3, ένα use-after-free με AIO, και πλαστογράφηση TLS session tickets. Το τελευταίο έχει σημασία μόνο με κοινόχρηστο session cache χωρίς αρχείο κλειδιού για τα tickets, οπότε το αν σας αφορά το κρίνουν οι ρυθμίσεις σας. Δεν έχω δει αναφορές για επιθέσεις. Ελέγξτε με nginx -v και ενημερώστε ούτως ή άλλως.

Και το npm: αυτό που δεν μπορείτε να διορθώσετε εσείς

Το npm είναι από εκεί που οι web developers παίρνουν τα δομικά τους υλικά. Στις 8 Οκτωβρίου δημοσιεύτηκε το tensorlake 0.5.144 με ένα worm που κλέβει npm tokens, κλειδιά SSH, διαπιστευτήρια cloud και αρχεία .env. Το άσχημο: πέρασε από την κανονική διαδικασία έκδοσης του ίδιου του project και είχε έγκυρο build provenance, οπότε ο συνηθισμένος έλεγχος «είναι γνήσιο αυτό το πακέτο;» έλεγε ναι. Κι άλλα κακόβουλα πακέτα εμφανίστηκαν μέσα στον Οκτώβριο.

Αυτό δεν αγγίζει απευθείας τον server σας. Χτυπά όποιον φτιάχνει το site σας, στο laptop του και στο σύστημα build. Τι μπορείτε να τον ρωτήσετε: κλειδώνει τις εκδόσεις των εξαρτήσεων, μπλοκάρει τα install scripts, έχει ενεργό έλεγχο ταυτότητας δύο παραγόντων στους λογαριασμούς του;

Τι μένει ανοιχτό

Πόσες απόπειρες PHP2Shell πετυχαίνουν δεν είναι ακόμα γνωστό, και η εικόνα αλλάζει μέρα με τη μέρα. Θα ενημερώσω το άρθρο αν το PHP project ή η CISA επιβεβαιώσουν κάτι παραπάνω.

Πηγές: ανακοίνωση PHP, Amazon Threat Intelligence, Tenable FAQ, Sansec, ανακοινώσεις ασφαλείας nginx, Endor Labs για το tensorlake.