So prüfst du, ob deine selbst gehosteten Apps eine anfällige PHP-Version verwenden

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Conceptual guide: CHECK THE RUNNING PHP. Identify service; Inspect runtime; Verify vendor fix.

Auf einem Host können mehrere PHP-Versionen gleichzeitig laufen. Die Version, die eine SSH-Shell ausgibt, kann zu einem Befehlszeilentool gehören, während eine öffentliche Website eine andere Laufzeit verwendet. Um die PHP-Sicherheitslücken vom Oktober 2026 zu bewerten, ordnen Sie jedes Versionsergebnis einer tatsächlichen Anwendung und einem Dienst zu.

Prüfen Sie die Umgebung, in der die Anwendung ausgeführt wird, nicht nur das PHP der Befehlszeile auf dem Host. Vergleichen Sie den exakten Laufzeitzweig oder die Distributionspaket-Revision mit der entsprechenden Empfehlung und berücksichtigen Sie dokumentierte Hersteller-Backports. Entfernen Sie nach der Prüfung alle temporären Diagnoseseiten.

1. PHP-basierte Anwendungen ermitteln

Listen Sie die Anwendungen, Installationsmethoden und externen Zugriffswege auf. Prüfen Sie die Dokumentation oder Paketmetadaten der Anwendung, um festzustellen, ob sie PHP verwendet. Berücksichtigen Sie auch Nebendienste wie Cron-Runner und Warteschlangen, wenn sie dasselbe Anwendungsimage verwenden.

Leiten Sie die PHP-Nutzung nicht von der NAS-Marke ab. Auf einem Gerät, auf dem verschiedene Anwendungen laufen, muss jede Anwendung einzeln bewertet werden.

2. Eine Compose-Bereitstellung prüfen

docker compose ps
docker compose images
docker compose exec -T app php -v
docker compose exec -T app php --ini

Führen Sie diese Befehle im Verzeichnis des vorgesehenen Compose-Projekts aus; ersetzen Sie app durch den Dienst, der PHP enthält. Die Befehle ermitteln die aktuellen Container und fragen die Binärdatei innerhalb dieses Dienstes ab. Wenn PHP in einem separaten Dienst namens php oder fpm ausgeführt wird, prüfen Sie stattdessen diesen Dienst.

Eine fehlende ausführbare Datei php beweist nicht, dass die Anwendung sicher ist. Minimale Images, alternative Binärdateipfade oder separate Laufzeitdienste erfordern möglicherweise die vom Maintainer vorgesehene Prüfmethode. Installieren Sie keine Pakete in einem Produktionscontainer, nur um eine Versionsprüfung durchzuführen.

3. Auf dem Host installiertes PHP prüfen

command -v php
php -v
php --ini

Diese beschreiben das PHP der Shell. Prüfen Sie als Nächstes Ihre Webserverkonfiguration und den Dienstmanager, um den PHP-FPM-Pool, das Apache-Modul oder einen anderen Handler zu ermitteln, über den die Website bereitgestellt wird. Prüfen Sie die Paketversion dieser Komponente und die Herstellerempfehlung. PHP weist darauf hin, dass Konfigurationsorte und Verhalten je nach Server-Schnittstelle variieren.

Wenn ein Dashboard private Laufzeitinformationen für den tatsächlichen Webdienst bereitstellt, kann es die Bestandsaufnahme ergänzen. Lassen Sie keine öffentliche phpinfo()-Seite online; sie kann Details offenlegen, die für diese Prüfung nicht relevant sind.

4. Nachweise mit der Sicherheitsmeldung abgleichen

Für den Vorfall vom 21. Oktober lauten die Sicherheitsveröffentlichungen des Upstream-Projekts PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Eine spätere unterstützte Version desselben Zweigs kann diese Fehlerbehebungen enthalten. Wenn eine Distribution Sicherheitspatches zurückportiert, orientieren Sie sich an ihrer Paketrevision und Sicherheitsmeldung, statt ein Paket allein anhand der scheinbaren Upstream-Versionsnummer abzulehnen oder freizugeben.

Halten Sie das Ergebnis in einem von drei Zuständen fest: nachweislich behoben, nachweislich betroffen oder ungeklärt und abhängig von Nachweisen des Anbieters. Legen Sie bei Software am Ende ihres Lebenszyklus ein unterstütztes Upgrade oder eine ausdrücklich bestätigte Fehlerbehebung durch einen Anbieter fest, der die Software weiterhin pflegt. Ein ungeklärtes Ergebnis sollte in Ihrer Wartungsliste sichtbar bleiben.

5. Bestätigen, was nach dem Update geschieht

Wiederholen Sie dieselben Prüfungen nach der Bereitstellung, einschließlich separater Worker und Container. Halten Sie die Image-Kennung oder Paketrevision sowie den Neustartstatus fest. Testen Sie eine normale authentifizierte Anfrage und die Funktionen, die Ihr Haushalt tatsächlich nutzt.

Führen Sie diese Aufzeichnung auf einer persönlichen Cloud von ZimaCube 2 zusammen mit der App-Konfiguration und den Backup-Anweisungen. Das nützliche Ergebnis ist eine nachvollziehbare Aussage wie „Diese Anwendung verwendet diese gepatchte Laufzeitumgebung“ statt „Das NAS wurde aktualisiert“. Wenn Sie einen betroffenen Container finden, befolgen Sie die verlinkte Update-Anleitung, bevor Sie seine Daten-Volumes ändern.

Entdecken Sie ZimaCube 2 Persönliche Cloud-Heim-NAS für Ihren privaten Speicher und Ihre selbst gehosteten Anwendungen. Die Softwaresicherheit hängt von den installierten Diensten, ihrer Konfiguration und überprüften Updates ab.

Die PHP-Sicherheitsreihe fortsetzen

Quellen und Umfang

Geprüft am 22. Oktober 2026. Bereitstellungsempfehlungen müssen mit Ihrer Anwendung und der Dokumentation des Anbieters abgeglichen werden; aus diesen Artikeln lässt sich keine produktspezifische Gefährdung ableiten.