Så kontrollerar du om dina självhostade appar använder en sårbar PHP-version

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

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

En värd kan köra flera PHP-versioner samtidigt. Versionen som visas i ett SSH-skal kan tillhöra ett kommandoradsverktyg, medan en offentlig webbplats använder en annan körmiljö. För att bedöma PHP-sårbarheterna från oktober 2026 måste du koppla varje versionsresultat till ett faktiskt program och en tjänst.

Kontrollera miljön som kör programmet, inte bara värdens PHP för kommandoraden. Jämför den exakta körmiljögrenen eller distributionens paketrevision med relevant säkerhetsmeddelande, med hänsyn till dokumenterade bakåtporterade korrigeringar från leverantören, och ta bort alla tillfälliga diagnostiksidor efter kontrollen.

1. Identifiera PHP-baserade program

Lista program, installationsmetoder och externa åtkomstvägar. Läs programmets dokumentation eller paketmetadata för att avgöra om det använder PHP. Ta med sidotjänster som cron-jobb och köer om de använder samma programavbildning.

Dra inga slutsatser om PHP-användning utifrån NAS-märket. En enhet som kör en blandning av program behöver bedömas tjänst för tjänst.

2. Granska en Compose-distribution

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

Kör dessa kommandon från den avsedda Compose-projektkatalogen; ersätt app med tjänsten som innehåller PHP. Kommandona identifierar de aktuella containrarna och frågar efter binärfilen i den tjänsten. Om PHP körs i en separat tjänst med namnet php eller fpm ska du undersöka den tjänsten i stället.

Att den körbara filen php saknas är inget bevis för att programmet är säkert. Minimala avbildningar, alternativa sökvägar till binärfiler eller separata körtjänster kan kräva att du använder underhållarens inspektionsmetod. Installera inte paket i en produktionscontainer enbart för att kunna kontrollera versionen.

3. Granska PHP som är installerat på värden

command -v php
php -v
php --ini

Dessa beskriver PHP i skalet. Undersök sedan webbserverns konfiguration och tjänstehanterare för att identifiera PHP-FPM-poolen, Apache-modulen eller en annan hanterare som betjänar webbplatsen. Kontrollera den komponentens paketversion och leverantörens säkerhetsmeddelande. PHP dokumenterar att konfigurationsplatser och beteenden varierar beroende på servergränssnitt.

Om en kontrollpanel visar privat information om körmiljön för den faktiska webbtjänsten kan den komplettera inventeringen. Låt inte en offentlig phpinfo()-sida vara tillgänglig; den kan avslöja uppgifter som inte har med kontrollen att göra.

4. Jämför underlaget med säkerhetsmeddelandet

För incidenten den 21 oktober är PHP:s säkerhetsversioner 8.2.35, 8.3.36, 8.4.27 och 8.5.12. En senare version som fortfarande stöds inom samma gren kan innehålla dessa korrigeringar. Om en distribution bakåtporterar säkerhetskorrigeringar ska du utgå från dess paketversion och säkerhetsmeddelande i stället för att underkänna eller godkänna ett paket enbart utifrån versionsnumret från PHP uppströms.

Dokumentera resultatet som ett av tre tillstånd: bekräftat åtgärdat, bekräftat berört eller olöst i väntan på underlag från leverantören. För programvara som nått slutet av sin livscykel ska du fastställa en uppgradering till en version som fortfarande stöds eller en uttrycklig korrigering från en leverantör som fortfarande underhåller den. Ett olöst resultat ska finnas kvar synligt i din underhållslista.

5. Bekräfta vad som händer efter uppdateringen

Upprepa samma kontroller efter driftsättningen, även för separata arbetsprocesser och containrar. Dokumentera avbildningens identifierare eller paketversion och omstarter. Testa en vanlig autentiserad begäran och de funktioner som hushållet faktiskt använder.

På en ZimaCube 2 personlig molnlösning sparar du den här dokumentationen tillsammans med appkonfigurationen och instruktionerna för säkerhetskopiering. Målet är en spårbar uppgift som ”den här applikationen använder den här korrigerade körmiljön” snarare än ”NAS-enheten uppdaterades”. Om du hittar en berörd container följer du den länkade uppdateringsguiden innan du ändrar dess datavolymer.

Utforska ZimaCube 2 Personal Cloud NAS för hemmet för din privata lagring och självhostade appmiljö. Programvarans säkerhet beror på de installerade tjänsterna, deras konfiguration och verifierade uppdateringar.

Fortsätt läsa serien om PHP-säkerhet

Källor och omfattning

Kontrollerat den 22 oktober 2026. Driftsättningsråd måste anpassas till din applikation och leverantörens dokumentation; dessa artiklar fastställer inte produktspecifik exponering.