Εν συντομία: Στο Kubernetes η PHP βρίσκεται μέσα στο image του container και όχι στο cluster. Μετά το PHP2Shell πρέπει να χτίσετε εκ νέου κάθε image PHP για Kubernetes με διορθωμένη έκδοση PHP, να εφαρμόσετε νέο rollout σε όλα τα επηρεαζόμενα workloads και στη συνέχεια να ελέγξετε την κατάσταση σε κάθε pod που εκτελείται. Ένα ενημερωμένο βασικό image στο registry από μόνο του δεν αλλάζει τίποτα στα pods που εκτελούνται.
Γιατί το ίδιο το cluster δεν κάνει patch
Το Kubernetes διαχειρίζεται containers, αλλά δεν φροντίζει το λογισμικό μέσα σε αυτά. Κάθε pod εκτελείται με το image από το οποίο ξεκίνησε, μέχρι να αντικατασταθεί. Όποιος λειτουργεί εφαρμογές PHP στο cluster φέρει γι' αυτό την ευθύνη για τα images, ακόμη και αν το cluster λειτουργεί ως διαχειριζόμενη υπηρεσία σε πάροχο cloud. Ο πάροχος συντηρεί τυπικά το επίπεδο ελέγχου και τους κόμβους, όχι τα images των πελατών.
Το PHP2Shell περιλαμβάνει τα CVE-2026-109618 και CVE-2026-109619, με CVSS v4.0 9,2 το καθένα. Επηρεάζονται, μεταξύ άλλων, το PHP-FPM, ο Apache με mod_php και το FrankenPHP, δηλαδή οι συνήθεις τρόποι λειτουργίας στα images PHP. Διορθωμένες είναι οι PHP 8.5.12, 8.4.27, 8.3.36 και 8.2.35.
Καταγραφή: ποιο image PHP για Kubernetes εκτελείται πού;
Ξεκινήστε με μια λίστα όλων των images στο cluster. Οι παρακάτω εντολές μόνο διαβάζουν. Τα ονόματα namespaces, deployments και containers είναι παραδείγματα.
# Όλα τα images όλων των pods, ομαδοποιημένα
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'
# Πραγματικό digest image που εκτελείται ανά container
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}'
# Έκδοση PHP σε ένα pod που εκτελείται
kubectl exec -n shop deploy/web -c php -- php -v
Σκεφτείτε εκτός από τα Deployments και τα StatefulSets, DaemonSets, CronJobs και init containers. Σε μεγαλύτερα clusters βοηθούν οι σαρωτές images, που ελέγχουν τα images για γνωστά CVE. Στα πακέτα διανομής μέσα στο image ισχύει όπως παντού: ένα backport μπορεί να αφήσει τον αριθμό έκδοσης αμετάβλητο, οπότε μετράει το changelog του πακέτου.
Νέο build των images
Ενημερώστε πρώτα το βασικό image. Αν χρησιμοποιείτε επίσημα images PHP, επιλέξτε μια παραλλαγή με διορθωμένη έκδοση PHP. Στη συνέχεια χτίστε εκ νέου το δικό σας image, χωρίς να παραλάβετε το παλιό βασικό επίπεδο από την cache.
# Παράδειγμα: νέο build του image, ενεργή νέα λήψη του βασικού image
docker build --pull --no-cache -t registry.example.com/shop/web:2026-10-25 .
# Έλεγχος της έκδοσης PHP στο νέο image πριν από το rollout
docker run --rm registry.example.com/shop/web:2026-10-25 php -v
Μη βασίζεστε σε tags όπως το latest ή σε μια απλή κύρια έκδοση. Αναφέρετε στο manifest, όπου είναι δυνατό, το digest του νέου image, ώστε να είναι σαφές ποια κατάσταση εφαρμόζεται. Αν η διάθεση γίνεται μέσω GitOps ή Helm, αλλάξτε το image εκεί, ώστε η κατάσταση να μην επανέλθει στον επόμενο συγχρονισμό.
Rollout και έλεγχος
Ένα νέο rollout αντικαθιστά σταδιακά όλα τα pods ενός workload. Στη συνέχεια ελέγχετε την κατάσταση στα pods που εκτελούνται. Μόνο τότε το patch είναι ενεργό, επειδή τα νέα αρχεία βοηθούν μόνο όταν δεν εκτελούνται πλέον παλιές διεργασίες PHP.
# Rollout με νέο image (τα ονόματα είναι παραδείγματα)
kubectl -n shop set image deploy/web php=registry.example.com/shop/web@sha256:<digest>
kubectl -n shop rollout status deploy/web
# Έλεγχος: επανεκκινήθηκαν όλα τα pods, είναι ενεργό το νέο digest;
kubectl -n shop get pods -o wide
kubectl -n shop exec deploy/web -c php -- php -v
Αν το image στάλθηκε εκ νέου με το ίδιο tag, το kubectl rollout restart προκαλεί επανεκκίνηση· τα pods όμως κατεβάζουν εκ νέου το image μόνο αν το προβλέπει το imagePullPolicy. Ασφαλέστερη είναι η μετάβαση σε νέο digest.
Διασώστε τα logs προτού αντικαταστήσετε pods. Με το παλιό pod εξαφανίζονται και τα τοπικά αρχεία καταγραφής του. Διατηρήστε τα logs του διακομιστή ιστού και της εφαρμογής από τις 20/10/2026, ιδανικά σε μια κεντρική πλατφόρμα logs.
Προσωρινά μέτρα στο cluster
Αν για την έκδοση PHP σας δεν είναι ακόμη διαθέσιμο διορθωμένο image, το php.net συνιστά προσωρινά μέτρα χωρίς πλήρη προστασία. Στο cluster ορίζετε όρια μνήμης μέσω των ορίων πόρων των containers, που βασίζονται σε cgroups. Αυτό αντιστοιχεί στη σύσταση να περιορίζεται η μνήμη μέσω container ή cgroups και όχι μέσω RLIMIT_AS ή RLIMIT_DATA.
; php.ini ή pool FPM στο image, π.χ. ενσωματωμένο μέσω ConfigMap
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Με λειτουργία upload το php.net αναφέρει post_max_size = 32M. Στην PHP 8.5 προστίθεται το fatal_error_backtraces=0. Μετά από αλλαγή της διαμόρφωσης απαιτείται νέο rollout. Συμπληρωματικά, τα NetworkPolicies περιορίζουν τις εξερχόμενες συνδέσεις των pods PHP και ένα Ingress με κανόνες προστασίας μπορεί να δυσκολέψει τις απόπειρες επίθεσης. Κανόνες που βασίζονται μόνο στα δεδομένα του αιτήματος δεν αρκούν όμως σύμφωνα με την Cloudflare.
Πιο στέρεη βάση μακροπρόθεσμα
Προγραμματίστε τακτικά αυτόματα rebuilds όλων των images PHP, έλεγχο images στην αλυσίδα build και πολιτικές που επιτρέπουν μόνο υπογεγραμμένα ή ελεγμένα images. Αν τα containers PHP εκτελούνται με χρήστη χωρίς δικαιώματα root και σύστημα αρχείων μόνο για ανάγνωση, μειώνεται η ζημιά μιας επιτυχημένης επίθεσης. Υποδείξεις για μεμονωμένα containers υπάρχουν στη σελίδα Patch της PHP σε containers Docker, για το FrankenPHP στη σελίδα Ασφάλεια του FrankenPHP.
Σε πολλά clusters οι εφαρμογές PHP δεν εκτελούνται μόνες. Συχνά υπάρχουν sidecar containers για logging ή μετρικές, βοηθητικά images για μεταφορές βάσεων δεδομένων και jobs που ξεκινούν μόνο τη νύχτα. Και images τρίτων, για παράδειγμα για ένα wiki, μια διεπαφή παρακολούθησης ή ένα σύστημα εισιτηρίων, μπορεί να περιέχουν PHP, χωρίς αυτό να φαίνεται από το όνομα. Ελέγξτε γι' αυτό όχι μόνο τις δικές σας εφαρμογές, αλλά κάθε image στο cluster. Για ξένα images ισχύει: περιμένετε μια ενημερωμένη έκδοση του κατασκευαστή, ελέγξτε τα στοιχεία του για την ενσωματωμένη έκδοση PHP και περιορίστε την προσβασιμότητα μέχρι να υπάρξει. Αν ένα τέτοιο σύστημα λειτουργεί μόνο εσωτερικά, αυτό μειώνει τον κίνδυνο, δεν αντικαθιστά όμως την ενημέρωση.
Πώς βοηθά συγκεκριμένα το PHP SOS;
- Καταγράφουμε όλα τα workloads με PHP, τα images και τα digests τους και ελέγχουμε την έκδοση PHP στα pods που εκτελούνται.
- Μέσω της υπηρεσίας PHP-Patch χτίζουμε εκ νέου images, τα εφαρμόζουμε με rollout και τεκμηριώνουμε την κατάσταση ανά workload.
- Διασώζουμε logs πριν από την αντικατάσταση και ελέγχουμε για ίχνη επίθεσης.
- Με παρακολούθηση ασφάλειας και αυτοματοποιημένα rebuilds φροντίζουμε το επόμενο patch να φτάνει ταχύτερα στο cluster.
Συχνές ερωτήσεις
Αρκεί να ενημερώσω το βασικό image στο registry;
Όχι. Τα pods που εκτελούνται συνεχίζουν να χρησιμοποιούν το image με το οποίο ξεκίνησαν. Μόνο ένα νέο rollout με το image που χτίστηκε εκ νέου αντικαθιστά τα pods. Ελέγξτε στη συνέχεια την έκδοση PHP σε κάθε pod που εκτελείται.
Γιατί να αναφέρονται τα images με digest;
Ένα tag μπορεί να δείχνει σε διαφορετικές καταστάσεις του image, ανάλογα με το πότε λήφθηκε. Ένα digest ορίζει ακριβώς μία κατάσταση. Έτσι γνωρίζετε με βεβαιότητα ποιος κώδικας εκτελείται σε ποιο pod και τα rollouts γίνονται ανιχνεύσιμα.
Τι ισχύει για τα CronJobs και τα init containers;
Και αυτά μπορεί να περιέχουν PHP και ανήκουν στην καταγραφή. Τα CronJobs ξεκινούν σε κάθε εκτέλεση νέα pods από το πρότυπό τους· ενημερώστε γι' αυτό το image στο πρότυπο. Τα init containers εκτελούνται στην εκκίνηση κάθε pod.
Προστατεύει ένα NetworkPolicy από το PHP2Shell;
Δεν κλείνει την ευπάθεια, μπορεί όμως να περιορίσει τη ζημιά. Όποιος περιορίζει τις εξερχόμενες συνδέσεις των pods PHP δυσκολεύει τη λήψη κακόβουλου κώδικα και τις πλευρικές κινήσεις μέσα στο cluster.