# Patch της PHP σε containers Docker

> Ενημέρωση image PHP Docker κατά του PHP2Shell: έλεγχος έκδοσης στο container, νέα κατασκευή image, δημιουργία νέων containers και σωστός ορισμός προσωρινών τιμών.

Πηγή: https://phpsos.de/el/php2shell/docker-container-patchen/  
Ημερομηνία: 25/10/2026  
Πάροχος: PHP SOS, Επείγουσα βοήθεια PHP και ασφάλεια διακομιστών. Άμεση βοήθεια μέσω WhatsApp: https://wa.me/491736494914?text=%CE%93%CE%B5%CE%B9%CE%B1%20%CF%83%CE%B1%CF%82%2C%20PHP%20SOS%2C%20%CF%87%CF%81%CE%B5%CE%B9%CE%B1%CE%B6%CF%8C%CE%BC%CE%B1%CF%83%CF%84%CE%B5%20%CE%B2%CE%BF%CE%AE%CE%B8%CE%B5%CE%B9%CE%B1%20%CE%BC%CE%B5%20%CF%84%CE%BF%CE%BD%20%CE%B4%CE%B9%CE%B1%CE%BA%CE%BF%CE%BC%CE%B9%CF%83%CF%84%CE%AE%20PHP%20%CE%BC%CE%B1%CF%82.%20%CE%95%CF%84%CE%B1%CE%B9%CF%81%CE%B5%CE%AF%CE%B1%3A%20%E2%80%A6%20%CE%99%CF%83%CF%84%CF%8C%CF%84%CE%BF%CF%80%CE%BF%CF%82%3A%20%E2%80%A6

**Εν συντομία:** Η ενημέρωση του image PHP Docker είναι υποχρεωτική κατά του PHP2Shell και δεν γίνεται μόνη της. Πρέπει να χτίσετε ή να κατεβάσετε ξανά το image με διορθωμένη έκδοση PHP, να δημιουργήσετε από αυτό κάθε container και να ελέγξετε ότι στο container που εκτελείται τρέχει η 8.5.12, 8.4.27, 8.3.36 ή 8.2.35. Μια απλή επανεκκίνηση του container δεν αρκεί.

## Γιατί τα containers δεν είναι αυτόματα ασφαλή

Ένα image Docker είναι ένα παγωμένο στιγμιότυπο. Η PHP μέσα του παραμένει στην κατάσταση που είχε κατά το χτίσιμο, ακόμη και αν στον host έχουν εφαρμοστεί εδώ και καιρό ενημερώσεις. Μια ενημέρωση πακέτων στο σύστημα του host δεν αλλάζει τίποτα στην PHP του container.

Προστίθενται τυπικοί σκόπελοι: images που χτίστηκαν πριν από μήνες και από τότε δεν πειράχτηκαν, βασικά images με σταθερό tag όπως `php:8.3.35-fpm`, τοπικές caches που κατά το χτίσιμο επαναχρησιμοποιούν το παλιό βασικό image και containers που επανεκκινήθηκαν μεν, αλλά δεν δημιουργήθηκαν ποτέ ξανά. Επηρεάζονται όλοι οι τρόποι λειτουργίας που είναι συνήθεις στα containers: PHP-FPM, Apache με mod_php και FrankenPHP.

Προστίθεται και ένα ζήτημα αρμοδιότητας. Σε πολλές εταιρείες ένα πρακτορείο ή ένας προγραμματιστής έχει χτίσει το image μία φορά, το λειτουργεί όμως το εσωτερικό IT ή ένας πάροχος φιλοξενίας. Τότε κανείς δεν νιώθει υπεύθυνος για την κατάσταση της PHP στο image. Διευκρινίστε γι' αυτό πρώτα ποιος χτίζει το image, πού βρίσκεται το Dockerfile και ποιος επιτρέπεται να διανέμει νέα images.

## Έλεγχος της έκδοσης PHP στο container

Ελέγξτε το container που εκτελείται, όχι μόνο το Dockerfile. Οι εντολές είναι αποκλειστικά ανάγνωσης.

```bash
docker ps --format "table {{.Names}}\t{{.Image}}\t{{.CreatedAt}}"
docker exec <container> php -v
docker exec <container> php -i | grep -E "^PHP Version|Server API"
docker image inspect <image> --format "{{.Created}}"
```

Αν το image χρησιμοποιεί πακέτα διανομής αντί για επίσημες κατασκευές PHP, ελέγξτε το επίπεδο των πακέτων στο container. Τα ονόματα των πακέτων διαφέρουν ανά βασική διανομή:

```bash
docker exec <container> sh -c "apt policy php8.3-fpm 2>/dev/null || apk info -v 2>/dev/null | grep php"
```

Στα πακέτα διανομής μπορεί να έχει εφαρμοστεί backport, παρότι ο αριθμός έκδοσης παραμένει παλιός. Τότε μετρά το changelog του πακέτου. Τα επίσημα images PHP φέρνουν αντίθετα συνήθως την PHP μεταγλωττισμένη από τα ίδια· εκεί ο αριθμός έκδοσης από το `php -v` είναι η αποφασιστική τιμή. Πώς αναγνωρίζονται τα backports, περιγράφει το [Σωστός έλεγχος έκδοσης PHP και επιπέδου patch](https://phpsos.de/el/php2shell/php-version-pruefen/).

## Ενημέρωση του image PHP Docker: νέα κατασκευή και διανομή

**Ιδιόκτητο image βασισμένο σε image PHP:** κατεβάστε ξανά το βασικό image και χτίστε χωρίς cache.

```bash
docker build --pull --no-cache -t meine-app:2026-10-25 .
docker run --rm meine-app:2026-10-25 php -v      # έλεγχος της έκδοσης πριν από την ανάπτυξη
```

**Με Docker Compose:** κατεβάστε ή χτίστε τα images και δημιουργήστε ξανά τα containers.

```bash
docker compose pull
docker compose build --pull --no-cache
docker compose up -d --force-recreate
```

Ελέγξτε στη συνέχεια ξανά με `docker exec <container> php -v` αν εκτελείται η νέα έκδοση. Αν το container έχει σταθερό tag έκδοσης στο Dockerfile, για παράδειγμα `FROM php:8.3.35-fpm`, πρέπει να ανεβάσετε το tag. Ένα tag στον κλάδο, όπως `php:8.3-fpm`, λαμβάνει νέες καταστάσεις patch, αλλά μόνο αν το κατεβάσετε ξανά.

Κρατήστε έτοιμο το προηγούμενο image μέχρι να δοκιμαστεί η νέα έκδοση. Σε περίπτωση σφάλματος μπορείτε έτσι να γυρίσετε πίσω, χωρίς να αφήσετε την εφαρμογή για πολύ εκτός σύνδεσης. Το παλιό image περιέχει όμως πάλι την ευάλωτη PHP· ένας δρόμος επιστροφής είναι γι' αυτό υποστηρίξιμος μόνο για σύντομο διάστημα και με τα προσωρινά μέτρα.

Όποιος χρησιμοποιεί Kubernetes, διανέμει το νέο image μέσω του deployment. Λεπτομέρειες στο [Patch της PHP στο Kubernetes](https://phpsos.de/el/server/kubernetes/). Για images FrankenPHP ισχύει η ίδια διαδικασία· υποδείξεις για τον τρόπο λειτουργίας θα βρείτε στο [Ασφάλιση του FrankenPHP](https://phpsos.de/el/server/frankenphp/).

> **Σημαντικό:**
> Μην ξεχάσετε τα βοηθητικά containers: οι workers cron και ουράς, τα εργαλεία διαχείρισης ή τα περιβάλλοντα staging χρησιμοποιούν συχνά το ίδιο image PHP, εκτελούνται όμως σε δικά τους containers. Καθένα από αυτά πρέπει να δημιουργηθεί ξανά.

## Προσωρινά μέτρα στο container

Αν η ενημέρωση δεν είναι ακόμη εφικτή, τα προσωρινά μέτρα του php.net ισχύουν και στο container. Δεν αποτελούν πλήρη προστασία. Το όριο μνήμης ανήκει εδώ στο container, επειδή το php.net το συνιστά μέσω container ή cgroup, όχι μέσω `RLIMIT_AS` ή `RLIMIT_DATA`:

```ini
; π.χ. ως αρχείο στο image: /usr/local/etc/php/conf.d/zz-uebergang.ini
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 6M
session.upload_progress.enabled = 0
```

```bash
docker run --memory=1g ...         # ή στο Compose: deploy.resources.limits.memory
```

Την τιμή την προσαρμόζετε στην εφαρμογή σας. Φροντίστε η εφαρμογή να μην μπορεί να αντικαταστήσει μόνη της το `memory_limit`· στο PHP-FPM ορίζετε γι' αυτό τις τιμές στο pool με `php_admin_value`. Η νέα διαμόρφωση ισχύει μόνο όταν το container δημιουργηθεί ξανά ή επανεκκινηθεί· το υπόβαθρο για την επανεκκίνηση βρίσκεται στο [Επανεκκίνηση του PHP-FPM και όλων των workers](https://phpsos.de/el/php2shell/php-fpm-neustart/).

## Για να πάει πιο γρήγορα την επόμενη φορά

- Χτίζετε ξανά τα images τακτικά και αυτόματα, όχι μόνο όταν αλλάζει ο κώδικας.
- Χρησιμοποιείτε βασικά images με tag κλάδου και καταγράφετε την έκδοση του χτισμένου images με ημερομηνία ή digest.
- Αφήνετε τα images να ελέγχονται για γνωστές ευπάθειες πριν από τη διανομή και λειτουργείτε τα containers χωρίς δικαιώματα root.
- Τηρείτε ένα απόθεμα για το ποια containers χρησιμοποιούν ποιο image.

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

- **Καταγραφή του αποθέματος:** Ελέγχουμε όλα τα containers που εκτελούνται, τα images και τις εκδόσεις PHP τους, ακόμη και τα βοηθητικά containers και το staging.
- **Νέα κατασκευή και διανομή:** Μέσω της [υπηρεσίας PHP patch](https://phpsos.de/el/leistungen/php-patch-service/) χτίζουμε τα images με διορθωμένη έκδοση και δημιουργούμε ξανά τα containers με έλεγχο.
- **Θωράκιση της μετάβασης,** όπου η ενημέρωση εξαρτάται από την εφαρμογή: τιμές του php.net, όριο μνήμης στο container.
- **Διαρκής παρακολούθηση:** Με το [security monitoring](https://phpsos.de/el/leistungen/security-monitoring/) έχουμε στο οπτικό μας πεδίο τις καταστάσεις των images και την ύποπτη συμπεριφορά των containers.


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

**Αρκεί το docker restart μετά την ενημέρωση;**  
Όχι. Το docker restart επανεκκινεί το container με το ίδιο, παλιό image. Πρέπει να χτίσετε ή να κατεβάσετε το νέο image και να δημιουργήσετε από αυτό ξανά το container, για παράδειγμα με docker compose up -d --force-recreate.

**Περιέχει ήδη το επίσημο image PHP τη διορθωμένη έκδοση;**  
Αυτό το ελέγχετε καλύτερα απευθείας: κατεβάστε ξανά το image και εκτελέστε μέσα σε αυτό το php -v. Αναμένονται 8.5.12, 8.4.27, 8.3.36 ή 8.2.35. Αν το image δείχνει παλαιότερο αριθμό, δεν έχει ενημερωθεί ακόμη ή προέρχεται από cache.

**Κινδυνεύει λιγότερο η PHP σε container απ' ό,τι στον host;**  
Η ίδια η ευπάθεια ισχύει στο container με τον ίδιο τρόπο. Ένα καλά χτισμένο container μπορεί να περιορίσει τις συνέπειες μιας εισβολής, για παράδειγμα με χρήστη χωρίς δικαιώματα root και σύστημα αρχείων μόνο για ανάγνωση. Δεν αντικαθιστά το patch.

## Πηγές

- [php.net: Ανακοινώσεις ασφαλείας](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)