Kurz gesagt: Auf RHEL, AlmaLinux und Rocky Linux prüfen Sie den PHP-Patch gegen PHP2Shell über drei Wege: die Sicherheitsmeldungen der Distribution (dnf updateinfo), das Paket-Changelog (rpm -q --changelog) und die Startzeit der PHP-Prozesse. Red Hat führt RHEL 7 bis 10 als betroffen und meldete beim Abruf, dass einige Updates verfügbar und weitere in Arbeit sind. Nach dem Update gilt: vollständig neu starten, nicht nur neu laden.
Was Red Hat zu PHP2Shell veröffentlicht hat
Red Hat hat zu PHP2Shell das Sicherheitsbulletin RHSB-2026-013 herausgegeben. Wir haben es am 25. Oktober 2026 abgerufen. Die wichtigsten Punkte für Admins:
- Betroffen sind RHEL 10, 9, 8 und 7 sowie darauf aufbauende Produkte und Container auf Basis von RHEL- oder UBI-Images.
- RHEL 7 ist laut Red Hat nur von CVE-2026-109619 betroffen; der Code für CVE-2026-109618 sei dort nicht enthalten.
- Nicht betroffen sind Systeme ohne PHP oder ohne PHP, das nicht vertrauenswürdige HTTP-Anfragen verarbeitet.
- Updates: Einige waren beim Abruf verfügbar, weitere in Arbeit. Konkrete Errata-Nummern nannte das Bulletin nicht, sondern verwies auf die Errata-Seiten.
Red Hat bewertet CVE-2026-109618 mit eigener Methode als „Important“ und verweist darauf, dass Standardinstallationen ab RHEL 8 PHP-FPM statt mod_php nutzen. Das ist eine Einordnung, keine Entwarnung. Das PHP-Projekt bewertet beide Lücken mit CVSS v4.0 9.2, und das BSI empfiehlt das sofortige Update.
AlmaLinux und Rocky Linux: gleiche Quelle, eigener Takt
AlmaLinux und Rocky Linux bauen ihre Pakete aus den Quellen von Red Hat nach. Korrekturen kommen deshalb in der Regel inhaltlich gleich an, aber mit eigenem Zeitpunkt und unter eigenen Sicherheitsmeldungen. Ein Hinweis auf eine Red-Hat-Errata bedeutet nicht, dass das Paket bei Ihrem Nachbau am selben Tag bereitsteht.
Entscheidend ist deshalb der Stand auf Ihrem System. Prüfen Sie ihn mit den Werkzeugen der Paketverwaltung und nicht anhand von Nachrichten oder Foren.
Achten Sie außerdem darauf, ob auf dem Server Spiegelserver oder interne Paketquellen genutzt werden. In vielen Unternehmen holen Server ihre Updates nicht direkt beim Hersteller, sondern über einen internen Spiegel oder ein Verwaltungswerkzeug. Ist dieser Spiegel nicht aktuell, findet dnf keine neuen Pakete, obwohl sie längst veröffentlicht sind.
Den PHP-Patch auf RHEL und Nachbauten prüfen
Die folgenden Befehle sind rein lesend. Paketnamen gelten für die PHP-Pakete der Distribution; Pakete aus Drittquellen wie Remi heißen teils anders.
# Welche PHP-Streams kennt das System, welcher ist aktiv? (RHEL 8 und 9)
dnf module list php
# Installierte PHP-Pakete mit Version und Herkunft
rpm -qa 'php*' --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n' | sort
# Gibt es Sicherheitsmeldungen zu den CVEs für dieses System?
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619
# Steht die Korrektur im Changelog des installierten Pakets?
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"
dnf updateinfo zeigt nur Meldungen für Updates, die noch nicht installiert sind; mit --installed sehen Sie auch bereits eingespielte. Ein leeres Ergebnis kann also zweierlei bedeuten: Das Update ist schon drin oder noch nicht veröffentlicht. Der Changelog-Abgleich klärt das. Wie Sie das Ergebnis als Nachweis festhalten, beschreibt der Beitrag CVE-Nummern im Paket-Changelog nachweisen.
Wie bei anderen Unternehmensdistributionen behält das Paket meist seine ursprüngliche PHP-Version; nur die Release-Angabe ändert sich. Eine ältere Nummer bei php -v ist deshalb kein Hinweis auf eine fehlende Korrektur. Allgemeine Hinweise zur Versionsprüfung stehen unter PHP-Version und Patchstand richtig prüfen.
Die richtige Betriebsart erkennen
Red Hat nennt die Standard-Betriebsarten: Ab RHEL 8 läuft PHP über PHP-FPM, auf RHEL 7 als mod_php im Apache-Dienst httpd. Viele Server weichen davon ab, etwa durch Panels, Fremdquellen oder alte Konfigurationen.
| System | Standard laut Red Hat | Neustart nach dem Update |
|---|---|---|
| RHEL 8, 9, 10 und Nachbauten | PHP-FPM | systemctl restart php-fpm |
| RHEL 7 | mod_php in httpd | systemctl restart httpd |
| Container auf RHEL- oder UBI-Basis | je Image | Image neu bauen, Container ersetzen |
Für Container empfiehlt Red Hat, nach aktualisierten Basis-Images die eigenen Images neu zu bauen und laufende Container oder Pods zu ersetzen. Ein Update im laufenden Container ist kein belastbarer Weg.
Nach dem Update: Neustart und Kontrolle
Red Hat betont, dass ein Reload nicht genügt. Bestehende Worker können den betroffenen Zustand behalten. Starten Sie deshalb jeden Dienst neu, der PHP lädt, und kontrollieren Sie das Ergebnis:
# Dienste mit veralteten Bibliotheken anzeigen (dnf-utils bzw. dnf-plugins-core)
needs-restarting -s
# Startzeit der PHP-Prozesse mit dem Update-Zeitpunkt vergleichen
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Für die Konfiguration hat Red Hat einen praktischen Hinweis: php -i zeigt die Einstellungen der Kommandozeile, nicht die des Webservers. Wer prüfen will, ob Übergangswerte wie session.upload_progress.enabled=0 im Webkontext greifen, nutzt kurzzeitig eine geschützte phpinfo-Seite und löscht sie danach. Was beim Neustart sonst zu beachten ist, steht unter PHP-FPM und alle Worker neu starten.
Übergangsmaßnahmen: die Hinweise von Red Hat
Wo ein Update noch fehlt, verweist Red Hat auf dieselben Übergangsmaßnahmen wie php.net und ergänzt einige praktische Hinweise für RHEL-Systeme. Sie ersetzen das Update nicht.
- Zeile wirklich ergänzen: Laut Red Hat ist die Zeile für
session.upload_progress.enabledin der ausgelieferten Konfiguration auskommentiert, die Funktion also standardmäßig aktiv. Der Wert0muss ausdrücklich gesetzt werden. - Nicht überschreibbar setzen: über
php_admin_valueim PHP-FPM-Pool, bei mod_php in der Apache-Konfiguration. Nicht überini_set()oder.user.ini. - Gegenspieler suchen: Red Hat empfiehlt,
.htaccess-Dateien, VirtualHosts und.user.ini-Dateien darauf zu prüfen, ob sie die betroffenen Einstellungen wieder einschalten. - Grenzen auch davor setzen: Neben
post_max_sizein PHP rät Red Hat, Grenzen für die Anfragegröße auch im Webserver oder Proxy zu erwägen.
Auf PHP-FPM-Systemen liegen die Pools in der Regel unter /etc/php-fpm.d/. Nach jeder Änderung gilt dasselbe wie nach dem Update: alle Worker vollständig neu starten.
Läuft auf demselben Server zusätzlich PHP aus dem Remi-Repository, gelten dafür eigene Pakete und Dienste. Lesen Sie dazu den Beitrag Das Remi-Repository.
Wie hilft PHP SOS konkret?
- Wir prüfen auf RHEL, AlmaLinux und Rocky Linux alle PHP-Pakete, Streams und Fremdquellen und gleichen sie mit den Sicherheitsmeldungen ab.
- Wir spielen Updates ein, starten alle Worker vollständig neu und kontrollieren die Prozess-Startzeiten.
- Für Container-Umgebungen bauen wir Images neu und ersetzen laufende Instanzen kontrolliert.
- Den Stand je Server halten wir im Nachweis des PHP-Patch-Service fest.
Häufige Fragen
Ist RHEL 7 von PHP2Shell betroffen?
Laut Red Hat ist RHEL 7 nur von CVE-2026-109619 betroffen, der verwundbare Code für CVE-2026-109618 sei dort nicht vorhanden. Auf RHEL 7 ist mod_php die Standard-Betriebsart, die das PHP-Team als besonders riskant einstuft.
Warum bewertet Red Hat die Lücke niedriger als php.net?
Red Hat nutzt eine eigene Bewertung nach CVSS v3.1 und stuft CVE-2026-109618 als Important ein, weil die Ausnutzung genaues Timing erfordere. php.net bewertet mit CVSS v4.0 9.2. Beide sehen Codeausführung ohne Anmeldung als möglich an, das Update ist in jedem Fall nötig.
Bekommen AlmaLinux und Rocky Linux die Korrekturen automatisch?
Beide bauen ihre Pakete aus den Quellen von Red Hat nach und veröffentlichen eigene Sicherheitsmeldungen. Der Zeitpunkt kann von Red Hat abweichen. Prüfen Sie den Stand deshalb auf dem eigenen System und in den Meldungen Ihrer Distribution.
Reicht systemctl reload php-fpm nach dem Update?
Nein. Red Hat weist ausdrücklich darauf hin, dass ein Reload nicht genügt, weil bestehende Worker den betroffenen Zustand behalten können. Starten Sie alle Worker neu, bei mod_php den Apache-Dienst httpd.