# Γιατί το mod_php φέρει τον υψηλότερο κίνδυνο

> Γιατί η ομάδα της PHP κατατάσσει τον κίνδυνο του PHP2Shell στον Apache με mod_php στον υψηλότερο, πώς αναγνωρίζετε το mod_php και τι να ενημερώσετε και να αλλάξετε τώρα.

Πηγή: https://phpsos.de/el/php2shell/mod-php-risiko/  
Ημερομηνία: 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

**Εν συντομία:** Από το PHP2Shell επηρεάζονται όλοι οι συνήθεις τρόποι λειτουργίας, στον Apache με mod_php όμως η ομάδα της PHP κατατάσσει τον κίνδυνο στον υψηλότερο. Εκεί επιδείχθηκε exploit προτού καν εκτελεστεί κώδικας της εφαρμογής. Όποιος χρησιμοποιεί mod_php πρέπει πρώτα να ενημερώσει την PHP και να επανεκκινήσει πλήρως τον Apache.

## Τι είναι το mod_php;

Στο mod_php η PHP είναι ένα module μέσα στον διακομιστή ιστού Apache. Κάθε διεργασία του Apache περιέχει έναν πλήρη διερμηνέα PHP και εκτελεί κώδικα PHP απευθείας. Αυτός ο τρόπος λειτουργίας ήταν για πολύ καιρό το πρότυπο και παραμένει διαδεδομένος σε παλαιότερους διακομιστές, σε πολλά πακέτα διανομών και σε ορισμένα images Docker μέχρι σήμερα.

Η εναλλακτική είναι το PHP-FPM: εκεί η PHP εκτελείται ως δική της υπηρεσία με δικές της διεργασίες και ο Apache ή ο Nginx απλώς προωθεί τα αιτήματα. Και οι δύο παραλλαγές επηρεάζονται από το PHP2Shell, όπως και το php-cgi, το FrankenPHP και το LiteSpeed.

Τυπικά περιβάλλοντα με mod_php είναι παλαιότεροι root servers που εκτελούνται αμετάβλητοι εδώ και χρόνια, τυπικές εγκαταστάσεις του Apache από πακέτα διανομών και images Docker με Apache και PHP σε ένα container. Όποιος δεν γνωρίζει με βεβαιότητα ποιον τρόπο λειτουργίας χρησιμοποιεί ο διακομιστής του, πρέπει να το ελέγξει αντί να το υποθέσει.

## Γιατί θεωρείται ιδιαίτερα επικίνδυνη η ευπάθεια του mod_php;

Η ομάδα της PHP έδωσε για το PHP2Shell μια σαφή εκτίμηση: στο mod_php ο κίνδυνος είναι ο υψηλότερος. Αιτιολόγηση: εκεί επιδείχθηκε ένα exploit που ενεργοποιείται προτού καν εκτελεστεί κώδικας της εφαρμογής.

Για τους διαχειριστές αυτό έχει μια άβολη συνέπεια. Πολλά μέτρα προστασίας βρίσκονται στην εφαρμογή: plugins ασφαλείας στο WordPress, modules firewall σε καταστήματα, έλεγχοι στον δικό σας κώδικα. Όλα είναι κώδικας της εφαρμογής. Όταν η εκμετάλλευση γίνεται πριν από αυτά, έρχονται πολύ αργά.

Προστίθεται η στενή σύνδεση: στο mod_php η PHP μοιράζεται τη διεργασία με τον Apache. Ό,τι παραβιάζει την PHP, εκτελείται με τα δικαιώματα του διακομιστή ιστού και στη μνήμη του. Στο PHP-FPM, αντίθετα, τα pools μπορούν να διαχωριστούν με δικούς τους χρήστες ανά ιστότοπο, κάτι που μπορεί να περιορίσει τις συνέπειες μιας εισβολής.

Για την ιεράρχηση αυτό σημαίνει: αν διαχειρίζεστε περισσότερους διακομιστές, εκείνοι με mod_php έχουν σειρά πρώτοι, και σε αυτούς είναι ιδιαίτερα σημαντικός ένας επακόλουθος έλεγχος για ίχνη.

Αυτό που δεν γνωρίζουμε: πόσες από τις 22,6 εκατομμύρια εκτεθειμένες, δυνητικά ευάλωτες εγκαταστάσεις που μετρήθηκαν παγκοσμίως χρησιμοποιούν mod_php. Αξιόπιστα στοιχεία γι' αυτό δεν έχουν δημοσιευθεί.

## Χρησιμοποιεί ο διακομιστής μου mod_php;

Οι παρακάτω εντολές είναι αποκλειστικά ανάγνωσης. Τα ονόματα υπηρεσιών και εντολών διαφέρουν ανά διανομή: Debian και Ubuntu χρησιμοποιούν `apache2`, η οικογένεια RHEL `httpd`.

```bash
apachectl -M 2>/dev/null | grep -i php     # π.χ. php_module ή php8_module
httpd -M 2>/dev/null | grep -i php         # RHEL, AlmaLinux, Rocky
a2query -m | grep -i php                   # Debian/Ubuntu
apt policy libapache2-mod-php8.3           # Debian/Ubuntu, έκδοση πακέτου του module
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619"   # οικογένεια RHEL
```

Αν δεν εμφανίζεται κανένα module PHP, ο Apache χρησιμοποιεί πιθανότατα PHP-FPM μέσω `proxy_fcgi`. Τότε ισχύουν αναλογικά οι υποδείξεις στο [Ασφάλιση του Nginx με PHP-FPM](https://phpsos.de/el/server/nginx-php-fpm/).

## Τι πρέπει να κάνουν τώρα όσοι χρησιμοποιούν mod_php

1. **Ενημερώστε το module PHP** σε 8.5.12, 8.4.27, 8.3.36 ή 8.2.35 ή σε επιβεβαιωμένο backport της διανομής σας.
2. **Επανεκκινήστε πλήρως τον Apache,** όχι μόνο επαναφόρτωση. Στο mod_php ο παλιός κώδικας PHP βρίσκεται σε κάθε διεργασία του Apache.

```bash
sudo systemctl restart apache2     # Debian/Ubuntu
sudo systemctl restart httpd       # οικογένεια RHEL
ps -o pid,lstart,cmd -C apache2    # έλεγχος ώρας εκκίνησης, στο RHEL: -C httpd
```

3. **Ορίστε προσωρινά μέτρα, αν η ενημέρωση δεν είναι ακόμη εφικτή.** Το php.net αναφέρει μεταξύ άλλων σταθερά όρια που οι εφαρμογές δεν μπορούν να αντικαταστήσουν:

```apache
# Διαμόρφωση διακομιστή ή VirtualHost, όχι .htaccess
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
```

Με `memory_limit=-1` πρέπει να προστεθεί ένα όριο μνήμης μέσω cgroup, όχι μέσω `RLIMIT_AS` ή `RLIMIT_DATA`. Αυτά τα μέτρα δεν αποτελούν πλήρη προστασία· οι λεπτομέρειες βρίσκονται στο [Άμεσα μέτρα όταν δεν μπορείτε ακόμη να εφαρμόσετε patch](https://phpsos.de/el/php2shell/sofortmassnahmen-ohne-patch/). Αν κανένα από τα δύο δεν είναι άμεσα εφικτό, το BSI συνιστά την προσωρινή αποσύνδεση του διακομιστή ιστού από το δίκτυο.

> **Δράστε άμεσα:**
> Αν ο Apache σας με mod_php ήταν απροστάτευτος στο διαδίκτυο μεταξύ 17 Οκτωβρίου και του patch, διασώστε τα logs από τις 20 Οκτωβρίου και αφήστε τον διακομιστή να ελεγχθεί για ίχνη. Το patch από μόνο του δεν αποδεικνύει ότι δεν συνέβη τίποτα.

## Μεσοπρόθεσμα: μακριά από το mod_php

Μετά το patch αξίζει μια ματιά στην αρχιτεκτονική. Η μετάβαση στο PHP-FPM με Apache `mpm_event` και `proxy_fcgi` ή με Nginx διαχωρίζει την PHP από τον διακομιστή ιστού, επιτρέπει δικά του pools και χρήστες ανά ιστότοπο και κάνει ευκολότερες τις επανεκκινήσεις και τις αλλαγές εκδόσεων. Δεν κλείνει το PHP2Shell, μειώνει όμως την επιφάνεια επίθεσης μελλοντικών ευπαθειών.

Η μετάβαση απαιτεί σχεδιασμό. Ρυθμίσεις που ορίζονταν μέχρι τώρα με `php_value` στο `.htaccess` δεν ισχύουν πλέον στο PHP-FPM και πρέπει να μεταφερθούν στο pool. Οι χρήστες και τα δικαιώματα αλλάζουν, οι κατάλογοι uploads και cache ίσως χρειάζονται νέες άδειες. Σε περιβάλλον δοκιμών αυτό ελέγχεται καλά, στη ζωντανή λειτουργία υπό πίεση χρόνου όχι. Υποδείξεις για τη μετάβαση θα βρείτε στο [Ασφάλιση του Apache με mod_php](https://phpsos.de/el/server/apache-mod-php/).

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

- **Εντοπισμός:** Ελέγχουμε ποιοι διακομιστές χρησιμοποιούν mod_php και από ποια πηγή πακέτων προέρχεται το module.
- **Patch και επανεκκίνηση:** Μέσω της [υπηρεσίας PHP patch](https://phpsos.de/el/leistungen/php-patch-service/) εφαρμόζουμε την ενημέρωση και ελέγχουμε ότι δεν εκτελείται πλέον καμία παλιά διεργασία του Apache.
- **Θωράκιση της μετάβασης:** Όπου η ενημέρωση εμποδίζεται, ορίζουμε τα μέτρα του php.net στη διαμόρφωση του διακομιστή.
- **Μετάβαση:** Στο πλαίσιο της [σκλήρυνσης διακομιστή](https://phpsos.de/el/leistungen/server-haertung/) σχεδιάζουμε και δοκιμάζουμε την αλλαγή στο PHP-FPM με χωριστά pools.


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

**Πώς καταλαβαίνω αν ο Apache μου χρησιμοποιεί mod_php;**  
Με το apachectl -M ή το httpd -M βλέπετε τα φορτωμένα modules. Αν εμφανίζεται εκεί ένα module όπως php_module ή php8_module, η PHP εκτελείται απευθείας στον Apache. Σε Debian και Ubuntu το a2query -m δείχνει επίσης αν είναι ενεργό ένα module php.

**Με προστατεύει ένα plugin ασφαλείας στο WordPress στο mod_php;**  
Σε αυτή την ευπάθεια όχι. Σύμφωνα με την ομάδα της PHP, στο mod_php επιδείχθηκε exploit προτού καν εκτελεστεί κώδικας της εφαρμογής. Ένα plugin είναι κώδικας της εφαρμογής και έρχεται επομένως πολύ αργά. Προστασία προσφέρει μόνο η ενημέρωση της PHP με επανεκκίνηση του Apache.

**Πρέπει να μεταβώ τώρα από το mod_php στο PHP-FPM;**  
Πρώτα patch, μετά μετάβαση. Η αλλαγή στο PHP-FPM έχει νόημα μεσοπρόθεσμα για τις περισσότερες διαμορφώσεις, επειδή η PHP εκτελείται τότε χωριστά από τον διακομιστή ιστού. Δεν κλείνει όμως το PHP2Shell, επειδή επηρεάζεται και το PHP-FPM.

## Πηγές

- [php.net: Ανακοινώσεις ασφαλείας](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Ομοσπονδιακή Υπηρεσία Ασφάλειας Πληροφοριών](https://www.bsi.bund.de/)