Kurz gesagt: Das Remi PHP-Repository liefert aktuelle PHP-Versionen für Fedora und die RHEL-Familie, entweder als Modul-Stream, der die System-PHP ersetzt, oder als Software-Collection, die mehrere Versionen parallel installiert. Die PHP2Shell-Korrekturen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 wurden dort am 22. Oktober 2026 angekündigt. Prüfen Sie jede installierte Version einzeln und starten Sie jeden zugehörigen Dienst neu.
Warum so viele RHEL-Server PHP von Remi beziehen
Unternehmensdistributionen wie RHEL, AlmaLinux und Rocky Linux setzen auf lange Stabilität. Sie liefern wenige PHP-Zweige und behalten diese über Jahre. Viele Anwendungen verlangen aber neuere Versionen, als die Distribution anbietet. Hier springt das Repository von Remi Collet ein, einem langjährigen Paketbetreuer für PHP im Fedora- und RHEL-Umfeld.
Remi baut die PHP-Versionen in kurzer Folge nach den offiziellen Releases. Zu PHP2Shell erschien im Blog des Repositorys am 22. Oktober 2026 ein Beitrag zu den Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Darin werden die beiden kritischen Lücken CVE-2026-109618 und CVE-2026-109619 genannt und das Update dringend empfohlen. Die Sicherheitsmeldungen von Red Hat gelten für diese Pakete nicht; was Red Hat für die eigenen Pakete meldet, steht im Beitrag RHEL, AlmaLinux und Rocky Linux: PHP-Patch prüfen.
Zwei Wege: Modul-Stream oder Software-Collection
Laut Remi-Blog stehen die Builds für Enterprise Linux ab Version 8 auf zwei Wegen bereit. Welcher auf Ihrem Server genutzt wird, bestimmt, wie Sie prüfen und neu starten.
| Weg | Repository | Wirkung | Typischer Dienst |
|---|---|---|---|
Modul-Stream, etwa php:remi-8.3 |
remi-modular | ersetzt die System-PHP, eine Standardversion | php-fpm |
Software-Collection, etwa php83 |
remi-safe | zusätzliche Version parallel in eigenem Pfad | eigener Dienst je Version, etwa php83-php-fpm |
| Testpakete und Release-Kandidaten | remi-modular-test, remi-test | Vorabversionen | nicht für Produktion |
Software-Collections liegen typischerweise unter /opt/remi/phpXY, ihre Konfiguration unter /etc/opt/remi/phpXY. Das ist praktisch, um alte und neue Anwendungen auf einem Server zu betreiben. Es ist aber auch der häufigste Grund, warum eine Version beim Update übersehen wird.
Ein Hinweis zur Kommandozeile: Software-Collections stehen nicht automatisch unter dem Befehl php zur Verfügung. Je nach Einrichtung rufen Cronjobs und Skripte sie über einen eigenen Befehl oder einen vollen Pfad auf. Prüfen Sie deshalb auch Crontabs und Deployment-Skripte, wenn Sie wissen wollen, welche Collection wofür im Einsatz ist.
Remi PHP-Repository nach PHP2Shell prüfen
Die folgenden Befehle sind rein lesend und zeigen, welche Remi-Pakete installiert sind und welchen Stand sie haben.
# Aktive Paketquellen: Ist remi-modular oder remi-safe eingebunden?
dnf repolist
# Aktiver Modul-Stream für PHP
dnf module list --enabled php
# Basispakete und parallel installierte Software-Collections
rpm -qa 'php-*' 'php[0-9][0-9]-php-*' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' | sort
# Version jeder installierten Collection
for b in /opt/remi/php*/root/usr/bin/php; do echo "$b"; "$b" -v | head -1; done
Bei den unterstützten Zweigen ist die Lage eindeutig: Steht dort 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder neuer, ist die Korrektur enthalten. Bei Remi entspricht die Versionsnummer in der Regel der Upstream-Version, anders als bei den Distributionspaketen, die oft ihre alte Nummer behalten.
Für ältere Collections wie php81, php80 oder php74 gibt es keine offizielle Zielversion. Remi führt PHP 8.1 als End-of-Life. Ob ein installiertes Paket eine Korrektur gegen PHP2Shell enthält, klären Sie im Changelog, etwa mit rpm -q --changelog php81-php-fpm | grep -E "CVE-2026-10961[89]". Ohne Treffer behandeln Sie das Paket als ungeklärt. Wie Sie solche Treffer sauber belegen, beschreibt der Beitrag CVE-Nummern im Paket-Changelog nachweisen.
Aktivieren Sie Test-Repositorys wie remi-test oder remi-modular-test nicht dauerhaft auf Produktionsservern. Sie liefern Release-Kandidaten, die für Tests gedacht sind.
Update und Neustart jeder Version
Das Update selbst ist bei Remi meist unspektakulär: dnf upgrade holt neue Pakete für Stream und Collections. Der kritische Teil folgt danach. Jede Collection hat ihren eigenen FPM-Dienst, und jeder muss neu gestartet werden.
# Alle PHP-FPM-Dienste auflisten, auch die der Collections
systemctl list-units --type=service --all | grep -E "php.*fpm"
# Startzeiten aller PHP-Prozesse prüfen
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Startzeiten vor dem Update bedeuten: Dieser Dienst arbeitet noch mit altem Code. Warum ein Neuladen nicht ausreicht, erklärt die Seite PHP-FPM und alle Worker neu starten.
Remi und Distribution: Wer ist zuständig?
Wer per Modul-Stream auf Remi umstellt, wechselt für PHP den Lieferanten. Die Sicherheitsmeldungen von Red Hat, AlmaLinux oder Rocky Linux beziehen sich dann nicht mehr auf die installierten PHP-Pakete. Umgekehrt meldet Remi keine Probleme in anderen Paketen des Systems. Beide Quellen müssen Sie also im Blick behalten.
Woher ein installiertes Paket stammt, zeigt die Paketdatenbank, etwa mit rpm -qi php-fpm in den Feldern für Hersteller und Paketierer. Weil es für Remi-Pakete keine Errata im Sinne von Red Hat gibt, eignet sich der Blog des Repositorys als Benachrichtigungsweg; er lässt sich per RSS-Feed abonnieren. Bei PHP2Shell erschien dort der Hinweis einen Tag nach den offiziellen Releases.
Für Unternehmen ist diese Aufteilung kein Hindernis, sie muss aber dokumentiert sein. Halten Sie fest, welche Server PHP von Remi beziehen, wer die Meldungen liest und wer nach einem Update die Dienste neu startet. Sonst verlässt sich jeder auf den anderen.
Ordnung halten: weniger Versionen, weniger Risiko
Software-Collections laden dazu ein, alte Versionen einfach liegen zu lassen. Nach PHP2Shell ist ein guter Zeitpunkt aufzuräumen:
- Für jede Collection klären, welche Website oder welcher Cronjob sie nutzt.
- Nicht genutzte Collections deaktivieren und nach einer Beobachtungszeit entfernen.
- Anwendungen auf alten Collections auf einen unterstützten Zweig heben.
- Die verbleibenden Versionen mit Zweck und Verantwortlichem dokumentieren.
Wie man den Überblick über viele parallele Versionen behält, beschreibt der Beitrag Mehrere PHP-Versionen auf einem Server.
Wie hilft PHP SOS konkret?
- Wir erfassen alle Remi-Streams und Collections auf Ihren Servern und ordnen sie Websites und Cronjobs zu.
- Wir prüfen den PHP2Shell-Stand je Version über Paketversion und Changelog.
- Wir spielen Updates ein, starten jeden Dienst neu und belegen das mit Prozess-Startzeiten im Rahmen des PHP-Patch-Service.
- Nicht mehr benötigte Collections entfernen wir nach Abstimmung kontrolliert.
Häufige Fragen
Hat Remi die PHP2Shell-Versionen bereitgestellt?
Ja. Im Blog des Repositorys wurden am 22. Oktober 2026 die Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 angekündigt, mit dem Hinweis auf zwei kritische Lücken, CVE-2026-109618 und CVE-2026-109619, und der dringenden Empfehlung zum Update.
Was ist der Unterschied zwischen Modul-Stream und SCL bei Remi?
Über einen Modul-Stream ersetzen Sie die System-PHP durch eine Remi-Version, es gibt dann eine PHP-Version als Standard. Software-Collections installieren weitere Versionen parallel in eigenen Pfaden, jede mit eigenem Dienst.
Bekommt PHP 8.1 von Remi noch Updates?
Remi führt PHP 8.1 als End-of-Life, das PHP-Projekt pflegt den Zweig nicht mehr. Ob ein bestimmtes 8.1-Paket eine Korrektur gegen PHP2Shell enthält, prüfen Sie im Changelog des installierten Pakets. Ohne Eintrag gilt der Stand als ungeklärt.
Muss ich nach einem Remi-Update jede PHP-Version neu starten?
Ja. Jede parallel installierte Version hat einen eigenen FPM-Dienst. Wird nur der Dienst der Hauptversion neu gestartet, laufen die anderen mit altem Code weiter.