PHP2Shell — Δύο Critical Pre-Auth RCE στο PHP (CVSS 9.2) και Επείγον Patch Σήμερα

1. Περίληψη (Executive Summary)

Στις 20 Οκτωβρίου 2026, λεπτομέρειες για δύο critical ευπάθειες του PHP διέρρευσαν δημόσια πριν από το προγραμματισμένο coordinated disclosure. Πρόκειται για δύο pre-auth Remote Code Execution (RCE) ευπάθειες — ο επιτιθέμενος δεν χρειάζεται λογαριασμό, συνθηματικό ή ρόλο — με καταχωρημένα IDs CVE-2026-109618 και CVE-2026-109619 και βαθμολογία CVSS v4.0: 9.2 (Critical).

Η κοινότητα τους βάφτισε συλλογικά «PHP2Shell» — PHP σε shell: από ένα απλό POST request στην εκτέλεση εντολών στον server. Η PHP Team αντέδρασε με έκτακτο security release προγραμματισμένο για τις 21 Οκτωβρίου, γύρω στις 14:00 UTC, ενώ το php.net υποχώρησε προσωρινά κάτω από την πίεση της κίνησης της ανακοίνωσης.

2. Τι είναι το PHP2Shell

«PHP2Shell» είναι η ονομασία που επικράτησε στην κοινότητα ασφαλείας για το ζεύγος των ευπαθειών CVE-2026-109618 / CVE-2026-109619: δύο ξεχωριστά καταχωρημένα αλλά συναφή ευρήματα που οδηγούν και τα δύο σε unauthenticated RCE σε προεπιλεγμένες ρυθμίσεις PHP.

2.1 Τι είναι το session.upload_progress

Πρόκειται για feature του PHP από την έκδοση 5.4 (2012): όταν ο χρήστης ανεβάζει αρχείο μέσω multipart/form-data φόρμας, η PHP μπορεί να γράφει στην session την πρόοδο του upload, ώστε μια JavaScript μπάρα να τη δείχνει ζωντανά. Ο μηχανισμός ενεργοποιείται όταν το POST περιλαμβάνει το ειδικό πεδίο PHP_SESSION_UPLOAD_PROGRESS.

3. Τεχνική Ανάλυση: Το Heap Use-After-Free

Η ρίζα της ευπάθειας βρίσκεται στο php_session_rfc1867_callback μέσα στο ext/session/session.c του PHP core — τον κώδικα που διαχειρίζεται το upload progress. Κατά την επεξεργασία multipart uploads, ο handler δουλεύει με raw δείκτες σε zval buckets (τις εσωτερικές δομές μεταβλητών του PHP Engine). Σε συγκεκριμένες ακολουθίες, η μνήμη απελευθερώνεται ενώ εξακολουθεί να αναφέρεται — ένα κλασικό use-after-free.

3.1 Γιατί ένα UAF είναι τόσο σοβαρό

Σε ένα use-after-free, ο επιτιθέμενος μπορεί να επανακαταλάβει την ελεύθερη μνήμη με δικά του δεδομένα (heap grooming): στέλνοντας στοχευμένα POST bodies, γεμίζει τον allocator με ελεγχόμενο περιεχόμενο που καταλαμβάνει το freed slot. Όταν ο handler γράψει/διαβάσει ξανά από τον stale δείκτη, διαχειρίζεται δεδομένα του επιτιθέμενου σαν να ήταν εσωτερική δομή του PHP — συμπεριλαμβανομένων function pointers που μπορεί να παραποιήσει, οδηγώντας στην εκτέλεση αυθαίρετου κώδικα στη διεργασία του PHP-FPM.

3.2 Το χρονικό παράθυρο της διαρροής

Το χειρότερο σενάριο coordinated disclosure υλοποιήθηκε: οι λεπτομέρειες και PoC εκμεταλλεύσεις βγήκαν δημόσια πριν υπάρχει patch διαθέσιμο. Από εκεί και πέρα, ο χρονικός «διαγωνισμός» ανάμεσα σε defenders και attackers ξεκίνησε αμέσως — με τα PoCs να πολλαπλασιάζονται στο GitHub μέσα σε ώρες (βλ. §7).

4. Χρονολόγιο

5. Αλυσίδες Εκμετάλλευσης (Attack Chains)

Οι ερευνητές που ανέλυσαν τα PoCs (μεταξύ αυτών το εργαστήριο του Qi Deng στο ikow/php2shell-poc) τεκμηρίωσαν πέντε διαφορετικές αλυσίδες — από το «απλό» session poisoning έως πλήρες RCE. Παρακάτω τις περιγράφουμε εννοιολογικά, χωρίς κώδικα εκμετάλλευσης:

5.1 Η πιο «εφικτή» αλυσίδα: Session Injection + LFI

Η αλυσίδα 1 είναι αυτή που ανησυχεί περισσότερο τους defenders, γιατί δεν απαιτεί memory corruption: το upload_progress επιτρέπει στον επιτιθέμενο να γράψει ελεγχόμενο περιεχόμενο μέσα στο αρχείο session. Αν η εφαρμογή έχει ένα LFI (Local File Inclusion) — ένα από τα πιο συνηθισμένα λάθη στον κόσμο της PHP — μπορεί να «συμπεριλάβει» το session αρχείο και το περιεχόμενο του επιτιθέμενου να εκτελεστεί ως κώδικας.

6. Ποιοι Κινδυνεύουν

Η PHP τροφοδοτεί ακόμη το συντριπτικό μέρος του web (κατά τη W3Techs, ~74–75% των sites με γνωστή server-side γλώσσα). Επειδή το upload_progress είναι default-On και η επίθεση pre-auth, το εύρος στόχων είναι σχεδόν κάθε PHP server που δέχεται POST requests.

6.1 Η ευρωπαϊκή οδηγία: «κατέβασε το site offline»

Σύμφωνα με ρεπορτάζ της Reuters, ευρωπαϊκοί αξιωματούχοι κυβερνοασφάλειας συμβούλευσαν οργανισμούς που δεν μπορούν να διορθώσουν έγκαιρα τα συστήματά τους να τα αποσύρουν προσωρινά από το internet μέχρι να διορθωθούν. Πρόκειται για απευθείας αναγνώριση ότι το παράθυρο πριν τη μαζική εκμετάλλευση είναι κρίσιμο — και ότι ένα site εκτός αέρα είναι φθηνότερο από ένα site με webshell.

7. Τι Συμβαίνει Τώρα: Το Οικοσύστημα των PoCs

Μέσα σε ~12 ώρες από τη διαρροή, το GitHub γέμισε PoC repos και defensive tools — ενδεικτικά (λίστα τη στιγμή συγγραφής, τα αστέρια αλλάζουν ραγδαία):

7.1 «Mass exploitation looms»

Ο τίτλος του SecurityWeek αποτυπώνει την κατάσταση: «PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws». Τη στιγμή συγγραφής δεν έχουμε επιβεβαιωμένα εκτεταμένα incident σε παραγωγικά συστήματα — αλλά το “looms” είναι η λέξη-κλειδί: δημόσια PoCs + pre-auth + default-On ρύθμιση = κύμα scanning/recon που είναι σχεδόν βέβαιο. Ιστορικά (Log4Shell, ProxyShell, Spring4Shell), το παράθυρο ανάμεσα στο δημόσιο PoC και τη μαζική σάρωση μετριέται σε ώρες, όχι μέρες.

8. Playbook Προστασίας

8.1 Άμεσες ενέργειες (0–24 ώρες)

• Πάρε το patch μόλις βγει για τα branches 8.2–8.5 και κάνε restart το PHP-FPM/Apache module (το σφάλμα ζει στη μνήμη της διεργασίας).
• Αν ΔΕΝ μπορείς να κάνεις patch: απενεργοποίησε το upload progress (κάτω) και σκέψου αποσύνδεση από το internet (βλ. ευρωπαϊκή οδηγία, §6.1).
• Κυνήγησε ήδη: έλεγξε τα logs με βάση το §9 πριν το patch φτάσει σε εσένα.
• Απογραφή: βρες ΠΟΥ τρέχει PHP και σε ποια έκδοση (βλ. §15.1) — συμπεριλαμβανομένων servers που «λοιποί» διαχειρίζονται.
• Ενημέρωσε ομάδες: dev, hosting, SOC/on-call.

8.2 Early mitigation: κλείσε το upload_progress

; php.ini (ή conf.d/*.ini) — επανεκκίνηση PHP-FPM μετά
session.upload_progress.enabled = 0

# Επαλήθευση σε CLI
php -i | grep -i upload_progress
# Επιθυμητό αποτέλεσμα: session.upload_progress.enabled => 0

8.3 WAF level: μπλόκαρε multipart POSTs (προσωρινά)

# NGINX (στον server block που σερβίρει PHP):
# ΠΡΟΣΟΧΗ: κόβει και νόμιμα uploads! Χρησιμοποίησε μόνο
# σε endpoints χωρίς upload ανάγκες, ή scope-άρισέ το ανά location.
if ($content_type ~* "multipart/form-data") {
    return 403;
}

Έχουν κυκλοφορήσει και πιο προσεγμένα Nginx/Apache rule-sets από την κοινότητα (ενδεικτικά άρθρα του Pasquale Pillitteri) που στοχεύουν το pattern PHP_SESSION_UPLOAD_PROGRESS. Αν έχεις ModSecurity, φτιάξε rule που κόβει POST bodies/params που περιέχουν PHP_SESSION_UPLOAD_PROGRESS εκτός ρητά επιτρεπόμενων εφαρμογών.

8.4 Σκλήρυνση sessions (καλό μέτρο — μειώνει τις αλυσίδες 4–5)

; php.ini
session.use_only_cookies = 1
session.use_strict_mode = 1
; και σκέψου: session.upload_progress.prefix / cleanup_freq review

8.5 Βραχυπρόθεσμες ενέργειες (1–7 ημέρες)

• Χαρτογράφηση EOL PHP σε κάθε υποδομή (production, staging, forgotten boxes).
• Σχέδιο migration σε 8.3+ για ό,τι μείνει σε 8.1 ή παλαιότερο — με χρονοδιάγραμμα και owner.
• Deployment των defensive tools (php2shell-triage, php-hunting) στα κρίσιμα hosts.
• Ενημέρωσε hosting/provider σου και δώσε τους το κείμενο §8.2 αν δεν το έχουν κάνει.
• Θέσε κανόνα alerting για multipart traffic anomalies στα PHP endpoints.

8.6 Μακροπρόθεσμα (1–4 εβδομάδες)

• Policy: υποστηριζόμενα PHP branches μόνο — nothing older than N-1 in production.
• Patch SLA για κρίσιμα PHP CVEs (π.χ. ≤48h για RCE).
• Review session usage στις εφαρμογές σου: ποιος χρειάζεται πραγματικά upload progress;
• WAF rules permanent (περιορισμός multipart ανά endpoint, όχι blanket).
• Tabletop exercise: «PHP2Shell hits 47 servers at 03:00» — ποιος κάνει τι;

9. Ανίχνευση & Δείγματα IOCs

Τι να ψάξεις στα logs σου — τόσο πριν όσο και μετά το patch:

9.1 Το πιο θορυβώδες σημάδι: PHP_SESSION_UPLOAD_PROGRESS

# Apache/Nginx access logs — ύποπτα multipart POSTs
grep -i "PHP_SESSION_UPLOAD_PROGRESS" /var/log/apache2/access.log
grep -i "PHP_SESSION_UPLOAD_PROGRESS" /var/log/nginx/access.log

# ModSecurity audit logs
grep -ri "PHP_SESSION_UPLOAD_PROGRESS" /var/log/modsec_audit/

# FPM error/slow logs
grep -ri "upload_progress" /var/log/php*-fpm*

Το PHP_SESSION_UPLOAD_PROGRESS είναι νόμιμο για εφαρμογές με upload progress bars — αλλά αν δεν έχεις τέτοιες εφαρμογές και το βλέπεις στα logs, κάθε εμφάνιση είναι ύποπτη απόπειρα. Πρόσεξε και ύποπτα POST bodies με πολλά κενά/μη-unicode γέμισμα (heap grooming pattern) σε endpoints με sessions.

9.2 Σημάδια επιτυχημένης παραβίασης

• Απρόσμενες child processes του PHP-FPM (sh, bash, python, curl, wget, nc) — κλασικό RCE footprint.
• Νέα/τροποποιημένα αρχεία σε writable directories (uploads, tmp, cache) με PHP περιεχόμενο.
• Εξόδυνες συνδέσεις από PHP worker processes (reverse shell patterns).
• Ανωμαλίες σε session αρχεία: ασυνήθιστα μεγάλα, με μη-κανονικά strings στο εσωτερικό τους.
• Απότομη αύξηση POST requests στο ίδιο endpoint από διαφορετικές IPs (recon wave).

10. Γιατί είναι Σημαντικό

• Υποδομή δεν ευθύνεται η εφαρμογή: η ευπάθεια είναι στο PHP core, όχι σε plugin/framework. Δεν «ανήκει» στον developer — αλλά το RCE ανήκει στον server.
• Pre-auth + default-On: δεν χρειάζεται λάθος configuration για να εκτεθείς. Χρειάζεσαι μόνο να τρέχεις PHP με sessions.
• Ο μόνιμος κατάλογος EOL: το τεράστιο long-tail των PHP 5.x/7.x/8.0/8.1 installations δεν θα διορθωθεί ποτέ. Η ανανέωση αυτών είναι η πραγματική δουλειά των επόμενων εβδομάδων.
• Διαρροή πριν το patch: το χειρότερο σενάριο disclosure. Η διαφορά ανάμεσα σε «sophisticated APT» και «script kiddie wave» είναι απλά 24–48 ώρες.
• LFI as force multiplier: η αλυσίδα 1 δείχνει πώς ένα «μικρό» LFI γίνεται πλήρες RCE όταν το core σου σερβίρει attack surface. Defense in depth, γιατί τα layers συνδυάζονται.
• Institutional response: η ευρωπαϊκή οδηγία «κατέβασε το offline αν δεν μπορείς να διορθώσεις» είναι σπάνια τόσο blunt — και δείχνει πού πηγαίνουν οι μαζικές ζώνες κινδύνου.

Συχνές Ερωτήσεις (FAQ)

13. Γλωσσάρι

15. Παράρτημα: Εντολές Ελέγχου

15.1 Απογραφή εκδόσεων PHP

# Ποια έκδοση τρέχει στο CLI (πρόσεξε: CLI ≠ FPM runtime!)
php -v

# Ποια έκδοση τρέχει ΜΕΣΑ στο web (FPM/module):
echo "<?php phpinfo();" > /var/www/html/info.php
# …άνοιξε το info.php μέσω browser, δες "PHP Version",
# και ΣΒΗΣΕ ΤΟ αρχείο αμέσως μετά.

# Σε hosting farms — βρες όλες τις εκδόσεις που ζουν:
ls /etc/php/           # Debian/Ubuntu: φάκελοι ανά branch
find / -name "php-fpm" -type f 2>/dev/null

15.2 Έλεγχος ρύθμισης upload_progress

php -i | grep -i upload_progress

# Επιθυμητό (mitigation):
# session.upload_progress.enabled => 0

# Αν είναι 1 και δεν μπορείς να πιάσεις patch:
# γράψε στο php.ini: session.upload_progress.enabled = 0
# μετά: systemctl restart php8.*-fpm

15.3 Κυνηγητό στα logs

# Ύποπτα multipart POSTs με session progress πεδίο:
grep -i "PHP_SESSION_UPLOAD_PROGRESS" /var/log/nginx/access.log

# Ύποπτα child processes του FPM (τυπικά RCE footprints):
ps aux | grep -E "php-fpm.*(sh|bash|python|curl|nc) "

# Πρόσφατα τροποποιημένα .php σε writable dirs:
find /var/www -name "*.php" -mtime -2 -ls

15.4 Post-patch checklist

# 1. Ενημέρωση
sudo apt update && sudo apt install --only-upgrade php8.\*

# 2. Επιβεβαίωση έκδοσης
php -v

# 3. Restart FPM (η μνήμη της διεργασίας πρέπει να ξαναπέσει)
sudo systemctl restart php8.4-fpm php8.3-fpm

# 4. Smoke test εφαρμογών (login, upload, session flows)

Σχετικά Άρθρα

Πηγές & Διαφάνεια

• php.net — επίσημη ανακοίνωση «Upcoming Critical PHP Security Release» (20/10/2026, φάκελος ειδήσεων: archive/2026)
• PoC bundle Zer061/CVE-2026-109618 + writeup jackalsyn.com (J4ck3LSyN, A. Dorman, Arch&Yuki)
• ikow/php2shell-poc — verified αλυσίδες εκμετάλλευσης (Qi Deng, writeup στο Substack)
• eness/php2shell PoC — αυτόνομο RCE PoC
• Defensive tools: php2shell-lab · php2shell-triage · php-hunting
• php-src PR #22113 — session fixation hardening (ερευνητικό εύρημα)
• NVD: CVE-2026-109618 · NVD: CVE-2026-109619
• ma.ttias.be (Mattias Geniar) — early mitigations (disable upload_progress / block multipart)
• Aikido Security — advisory & παρακολούθηση mitigation/patches
• Ρεπορτάζ επιβεβαιώσεων: watchTowr (reproduction), Huntress, Florian Roth — και ευρωπαϊκή οδηγία «take offline» μέσω Reuters. Επιπλέον κάλυψη: BleepingComputer, Ars Technica, SecurityWeek, Cyber Daily, Techzine, CyberSecurityNews, Pasquale Pillitteri (WAF rules).

Διαφάνεια: Το άρθρο γράφτηκε εν μέσω εξελισσόμενου γεγονότος (21/10/2026, ~09:35 UTC), πριν τη δημοσίευση του patch. Οι τεχνικές λεπτομέρειες προέρχονται από researcher writeups και δημόσια PoC repos — όχι ακόμη από πλήρες επίσημο security advisory. Στοιχεία που είναι ερευνητικά και όχι επίσημα (αλυσίδες 4–5, ακριβείς μηχανισμοί παραβίασης) σημειώνονται ως τέτοια. Το χρονοδιάγραμμα κυκλοφορίας του patch (~14:00 UTC) βασίζεται στις δημόσιες ανακοινώσεις και μπορεί να μετατοπιστεί. Δεν παρέχουμε κώδικα εκμετάλλευσης — μόνο defensive ανάλυση. Θα ενημερώσουμε το άρθρο όταν δημοσιευτούν οι διορθωτικές εκδόσεις και τα επίσημα advisories.