Εν ολίγοις: Για να ελέγξετε μια CVE στο changelog, αναζητήστε στο αρχείο αλλαγών του εγκατεστημένου πακέτου PHP τις CVE-2026-109618 και CVE-2026-109619: σε Debian και Ubuntu στο /usr/share/doc/<paket>/changelog.Debian.gz, σε συστήματα RPM με rpm -q --changelog. Ένα εύρημα, μαζί με το επίπεδο του πακέτου, την αντιπαραβολή με την επίσημη ανακοίνωση ασφαλείας και τον χρόνο επανεκκίνησης, αποτελεί αξιόπιστο τεκμήριο. Η απουσία ευρήματος δεν είναι ακόμη απόδειξη ανοιχτής ευπάθειας.
Γιατί η τεκμηρίωση είναι κάτι περισσότερο από το «κάναμε patch»
Μετά το PHP2Shell πολλοί θέλουν να μάθουν αν οι διακομιστές τους είναι ασφαλείς: η διοίκηση, ο υπεύθυνος προστασίας δεδομένων, πελάτες με ανάθεση επεξεργασίας, μερικές φορές ο ασφαλιστής κυβερνοκινδύνων. Το «κάναμε patch» δεν αρκεί γι' αυτό. Ζητείται ένα τεκμήριο που μπορεί να ελέγξει και τρίτος.
Ο αριθμός έκδοσης συχνά δεν ενδείκνυται, επειδή οι διανομές ενσωματώνουν διορθώσεις ως backport και ο αριθμός παραμένει ίδιος. Το changelog του πακέτου αποτελεί καλύτερη βάση. Το γράφει ο συντηρητής του πακέτου και στις ενημερώσεις ασφαλείας απαριθμεί κατά κανόνα τους αριθμούς CVE που διορθώθηκαν.
Πού βρίσκονται τα changelog
Κάθε μορφή πακέτου έχει τη δική της θέση. Ο παρακάτω πίνακας βοηθά να φτάσετε γρήγορα στο σωστό σημείο.
| Σύστημα | Θέση του changelog | Εντολή αναζήτησης |
|---|---|---|
| Debian, Ubuntu | /usr/share/doc/<paket>/changelog.Debian.gz |
zgrep |
| Debian, Ubuntu (online) | Αρχείο πακέτων της διανομής | apt changelog <paket> |
| RHEL, AlmaLinux, Rocky, Fedora | Βάση δεδομένων πακέτων RPM | rpm -q --changelog <paket> |
| Εικόνες container | μέσα στην εικόνα, όπως στο βασικό σύστημα | εκτέλεση της εντολής στο container |
Σε Debian και Ubuntu ο κατάλογος τεκμηρίωσης ορισμένων δυαδικών πακέτων παραπέμπει με συμβολικό σύνδεσμο σε κοινό πακέτο, για παράδειγμα php8.3-common. Αν το zgrep δεν βρίσκει το αρχείο, δείτε τον κατάλογο με ls -l /usr/share/doc/ | grep php.
Έλεγχος CVE στο changelog: πώς προχωράτε
Οι παρακάτω εντολές είναι αμιγώς ανάγνωσης. Προσαρμόστε τα ονόματα των πακέτων στην εγκατάστασή σας.
# Debian/Ubuntu: τοπικά, χωρίς δίκτυο
zgrep -n -E "CVE-2026-10961[89]|CVE-2026-115560" /usr/share/doc/php8.3-common/changelog.Debian.gz
# Debian/Ubuntu: επικεφαλίδα της νεότερης εγγραφής με επίπεδο πακέτου και ημερομηνία
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | head -20
# Οικογένεια RHEL: εγγραφή με ημερομηνία και επίπεδο πακέτου
rpm -q --changelog php-common | grep -n -B3 -E "CVE-2026-10961[89]"
Σε Debian και Ubuntu το επίπεδο του πακέτου βρίσκεται στην επικεφαλίδα κάθε εγγραφής, η ημερομηνία στην τελευταία γραμμή. Σε RPM και τα δύο βρίσκονται στη γραμμή πάνω από τις εγγραφές. Έτσι βλέπετε όχι μόνο αν αναφέρεται η CVE, αλλά και με ποιο επίπεδο πακέτου. Συγκρίνετε αυτό το επίπεδο με το εγκατεστημένο, για παράδειγμα μέσω dpkg-query -W ή rpm -q. Αν συμφωνούν, η διόρθωση περιέχεται στο πακέτο που τρέχει.
Πακέτα πάνελ και containers
Τα πάνελ φιλοξενίας φέρνουν δικά τους πακέτα PHP, για παράδειγμα το Plesk ή το cPanel. Και αυτά είναι συνήθη πακέτα DEB ή RPM και το changelog τους διαβάζεται με τα ίδια εργαλεία. Το αν οι πάροχοι αναφέρουν εκεί αριθμούς CVE ή μόνο τη νέα έκδοση PHP διαφέρει. Αν το πακέτο αναφέρει την έκδοση upstream 8.5.12, 8.4.27, 8.3.36 ή 8.2.35, αυτό αρκεί ως τεκμήριο· στα backport με παλιό αριθμό χρειάζεστε την ενημέρωση του παρόχου.
Στα containers το τεκμήριο ανήκει στην εικόνα και όχι στον host. Ελέγξτε τα πακέτα στην εικόνα από την οποία ξεκίνησε το container που τρέχει και καταγράψτε επιπλέον το digest της εικόνας. Έτσι αργότερα είναι κατανοητό ποιο επίπεδο έτρεχε πραγματικά, ακόμη κι αν η εικόνα έχει στο μεταξύ ξαναχτιστεί με το ίδιο tag.
Όταν η CVE λείπει από το changelog
Μια εγγραφή που λείπει έχει περισσότερες πιθανές αιτίες. Εξετάστε τις με αυτή τη σειρά:
- Αναζήτηση σε λάθος πακέτο: Σε διακομιστές με περισσότερους κλάδους PHP ή πηγές, η απάντηση βρίσκεται συχνά στο changelog άλλου πακέτου.
- Έκδοση upstream αντί για CVE: Αν η πηγή παραδίδει τη νέα έκδοση upstream, για παράδειγμα 8.4.27, στο changelog μπορεί να αναγράφεται μόνο «New upstream version». Τότε ο ίδιος ο αριθμός έκδοσης αποτελεί το τεκμήριο, επειδή το php.net ονομάζει τις εκδόσεις 8.5.12, 8.4.27, 8.3.36 και 8.2.35 ως διορθωμένες.
- Άλλη διατύπωση: Ορισμένοι συντηρητές αναφέρουν αριθμούς σφαλμάτων ή αναγνωριστικά advisory όπως GHSA-w8hw-w9fx-j79w και GHSA-6wmf-4rv5-p3rp αντί για την CVE.
- Αντιπαραβολή με την ανακοίνωση ασφαλείας: Αν η επίσημη ανακοίνωση της διανομής σας, για παράδειγμα ένα USN ή ο Debian Security Tracker, αναφέρει διορθωμένο επίπεδο πακέτου και αυτό ή νεότερο είναι εγκατεστημένο, αποτελεί επίσης τεκμήριο. Για Debian και Ubuntu θα βρείτε τα επίπεδα στο άρθρο Είναι το πακέτο PHP μου ενημερωμένο;, για την οικογένεια RHEL στο RHEL, AlmaLinux και Rocky Linux.
- Ερώτηση στον πάροχο: Για πακέτα πάνελ, builds παρόχου φιλοξενίας ή τρίτες πηγές βοηθά μόνο η γραπτή ενημέρωση. Υπόδειγμα προσφέρει ο οδηγός Ρωτήστε τον πάροχο φιλοξενίας για την κατάσταση του patch.
Αν μετά από αυτά τα βήματα δεν προκύψει τεκμήριο, αντιμετωπίστε τον διακομιστή ως μη ενημερωμένο και εφαρμόστε προσωρινά μέτρα μέχρι να διευκρινιστεί το ζήτημα.
Από το εύρημα στο τεκμήριο
Ένα εύρημα στο changelog αποδεικνύει ότι το πακέτο περιέχει τη διόρθωση. Δεν αποδεικνύει ότι οι διεργασίες που τρέχουν τη χρησιμοποιούν. Ένα πλήρες τεκμήριο περιλαμβάνει γι' αυτό πέντε στοιχεία ανά διακομιστή και εγκατάσταση PHP:
- διακομιστής, κλάδος PHP και τρόπος λειτουργίας, για παράδειγμα PHP-FPM ή mod_php
- εγκατεστημένο επίπεδο πακέτου και πηγή πακέτου
- σημείο εύρεσης στο changelog ή παραπομπή στην επίσημη ανακοίνωση ασφαλείας
- χρόνος της ενημέρωσης και χρόνος εκκίνησης των διεργασιών PHP που τρέχουν
- όνομα του προσώπου που έκανε τον έλεγχο και ημερομηνία του ελέγχου
Αποθηκεύστε τα ακατέργαστα αποτελέσματα των εντολών ως αρχείο κειμένου δίπλα στο τεκμήριο. Είναι ευκολότερο να ελεγχθούν αργότερα από μια περίληψη που γράφτηκε από μνήμης.
Ένα τεκμήριο απαντά μόνο στο ερώτημα αν η ευπάθεια ήταν κλειστή από ένα συγκεκριμένο χρονικό σημείο. Για την προηγούμενη περίοδο χρειάζεστε τα logs από τις 20 Οκτωβρίου 2026 και, ενδεχομένως, έρευνα ιχνών. Τη γενική διαδικασία ελέγχου έκδοσης περιγράφει η σελίδα Σωστός έλεγχος της έκδοσης PHP και του επιπέδου patch.
Πώς βοηθά συγκεκριμένα η PHP SOS;
- Διερευνούμε τα changelog όλων των πακέτων PHP των διακομιστών σας και τα αντιπαραβάλλουμε με τις επίσημες ανακοινώσεις ασφαλείας.
- Όπου τα changelog σιωπούν, διευκρινίζουμε το επίπεδο με τη διανομή, τον πάροχο του πάνελ ή τον πάροχο φιλοξενίας.
- Ελέγχουμε ότι οι διεργασίες που τρέχουν επανεκκινήθηκαν μετά την ενημέρωση.
- Με την υπηρεσία patch PHP λαμβάνετε το τεκμήριο ανά διακομιστή σε μορφή που μπορείτε να παραδώσετε σε τρίτους.
Συχνές ερωτήσεις
Γιατί δεν αρκεί η έκδοση PHP ως τεκμήριο;
Πολλές διανομές ενσωματώνουν διορθώσεις ασφαλείας ως backport, χωρίς να αλλάζουν την έκδοση PHP. Ο αριθμός έκδοσης δεν λέει τότε τίποτα για το patch. Το changelog του εγκατεστημένου πακέτου αναφέρει αντίθετα τους αριθμούς CVE που διορθώθηκαν.
Τι σημαίνει αν η CVE λείπει από το changelog;
Μπορεί να σημαίνει ότι λείπει η διόρθωση. Μπορεί όμως και ο συντηρητής του πακέτου να διατύπωσε διαφορετικά, για παράδειγμα με αριθμό σφάλματος ή με την έκδοση upstream. Τότε αντιπαραβάλλετε το επίπεδο του πακέτου με την επίσημη ανακοίνωση ασφαλείας ή ρωτάτε τον πάροχο.
Για πόσο καιρό πρέπει να φυλάσσω το τεκμήριο;
Για όσο διάστημα μπορεί να είναι σχετικό για εσωτερικούς ελέγχους, ασφαλιστές ή πιθανά ζητήματα προστασίας δεδομένων. Αρχειοθετήστε το μαζί με τα logs από τις 20 Οκτωβρίου 2026. Τις συγκεκριμένες προθεσμίες τις διευκρινίζετε με τον υπεύθυνο προστασίας δεδομένων ή με νομικό σύμβουλο.
Μπορώ να ελέγξω το changelog και χωρίς πρόσβαση στο διαδίκτυο;
Ναι. Το Debian και το Ubuntu αποθηκεύουν το changelog κάθε πακέτου τοπικά στο /usr/share/doc, τα συστήματα RPM το φυλάσσουν στη βάση δεδομένων πακέτων. Και τα δύο διαβάζονται χωρίς δίκτυο.