RHEL, Rocky und AlmaLinux
Unterscheiden Sie OS-Pakete, Modulstreams und Drittanbieterquellen. Prüfen Sie vollständige RPM-Revision und Errata. Bleiben Sie in einem kompatiblen Stream. Die Beispiele gelten für php-*-Pakete ohne Versionspräfix; parallele Installationen können andere Namen haben. Drittanbieter müssen beide Korrekturen belegen.
Alpine Linux
Erfassen Sie Alpine-Version, Repository und vollständige Paketrevision. Prüfen Sie den installierten Zweig, etwa php83 oder php84, anhand der Herstellerinformationen. Aktualisieren Sie passende Erweiterungen gemeinsam. Starten Sie FPM neu oder ersetzen Sie den Container. Ein Alpine-Suffix allein belegt keine Anfälligkeit.
Distributions-Backports
Ubuntu, Debian und Enterprise-Linux können alte Upstream-Nummern mit neuen Sicherheitsrevisionen behalten. Ein Banner wie 8.3.6 beweist weder Anfälligkeit noch Korrektur. Ordnen Sie OS, Repository, Architektur und Paketrevision den Herstellerangaben für BEIDE CVEs zu. Diese Website erfindet keine Paketgrenzen.
3. Neustarten und vollständig prüfen
Neue Dateien ersetzen keine laufenden Worker im Speicher. Starten Sie Apache bei mod_php oder alle betroffenen FPM-Dienste und Pools neu, ebenso dauerhafte Queue-Prozesse. Prüfen Sie Startzeit, Web-Version, Paketrevision, Healthchecks und alle Replikate. Entfernen Sie Diagnose-Seiten sofort; phpinfo() darf nicht öffentlich bleiben.
Befehlsbeispiel / RPM
rpm -q php-common php-fpm php-cli
dnf updateinfo info --cves CVE-2026-109618,CVE-2026-109619
# Confirm that the enabled vendor repository contains the fix first.
sudo dnf upgrade php-common php-fpm php-cli
sudo systemctl restart php-fpmBefehlsbeispiel / ALPINE
apk info -v | grep '^php'
apk policy php84 php84-fpm
# Example: PHP 8.4 packages; match your installed branch.
sudo apk update
sudo apk upgrade php84 php84-fpm
sudo rc-service php-fpm84 restart