Kort sagt: Den som själv förvaltar en root-server eller vServer måste också själv säkra den efter PHP2Shell: ge PHP-paketen en åtgärdad version, starta om alla PHP-processer och kontrollera resultatet. Datacenteroperatören sköter i regel bara hårdvara, virtualisering och nät. Därefter lönar det sig att härda servern långsiktigt.
Ert ansvar med en egen server
Med en ohanterad root-server eller vServer hyr ni datorkraft, inte skötsel. Operativsystem, webbserver, PHP, databas, brandvägg, säkerhetskopior och övervakning ligger i era händer. För ledning och ägare betyder det: om ingen i huset eller hos en tjänsteleverantör uttryckligen har tagit på sig de här uppgifterna är det ingen som utför dem.
PHP2Shell gör det synligt. De två sårbarheterna CVE-2026-109618 och CVE-2026-109619 sitter i själva PHP och möjliggör kodkörning utan inloggning. PHP-projektet publicerade den 21 oktober 2026 versionerna 8.5.12, 8.4.27, 8.3.36 och 8.2.35. BSI (den tyska förbundsmyndigheten för informationssäkerhet) rekommenderar en omedelbar uppdatering och, om det inte går, att webbservern tillfälligt tas offline.
Säkra vServer: kontrollera bestånd och paketstatus
Skaffa först en överblick över vilka PHP-versioner som är installerade och från vilken källa de kommer. Många servrar använder utöver distributionens paket ytterligare paketkällor. Följande kommandon läser bara. Paketnamn är exempel.
# Debian/Ubuntu: installerade PHP-paket och deras ursprung
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm
# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'
# Vilka PHP-binärer finns över huvud taget?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
Versionsnumret ensamt räcker inte. Distributioner levererar ofta säkerhetsrättningar som backport, och det visade numret förblir då äldre. Avgörande är paketets ändringslogg.
# Debian/Ubuntu (paketnamn som exempel)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'
# RHEL-familjen (paketnamn som exempel)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'
En utförlig anvisning finns under Kontrollera PHP-version och patchstatus.
Installera uppdateringen och förnya alla processer
Installera uppdateringarna via pakethanteringen och starta därefter om varje tjänst som laddar PHP. Beroende på uppbyggnaden är det PHP-FPM, Apache med mod_php, LiteSpeed eller en applikationsserver. Nya filer på hårddisken räcker inte så länge gamla processer ligger kvar i minnet.
# Hitta tjänster med PHP
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'
# Visa processer med starttid
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep
# Debian/Ubuntu: hitta program med föråldrade bibliotek (om installerat)
needrestart -r l
Varje relevant process bör ha startats efter uppdateringen. Verktyget needrestart på Debian-system är till hjälp, eftersom det visar tjänster med föråldrade bibliotek. Detaljer om omstarten beskrivs under Starta om PHP-FPM och alla worker-processer.
En patch tar inte bort skadlig programvara som fördes in före uppdateringen. Spara webbserverloggarna från och med den 20 oktober 2026 och kontrollera servern med avseende på spår innan ni klassar den som ren.
För en första spårsökning passar några kontroller som inte ändrar något. Sök efter PHP-filer som har skapats eller ändrats i webbkatalogerna sedan den 17 oktober 2026, efter okända poster i alla användares crontabs, efter nya systemanvändare och SSH-nycklar samt efter processer som tillhör webbserveranvändaren och håller utgående anslutningar.
# PHP-filer ändrade sedan 17.10.2026 (sökväg som exempel)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls
# Nätverksanslutningar med tillhörande process
ss -tupn
Ingen av de här kontrollerna bevisar i sig ett intrång, och ett tomt resultat bevisar inte motsatsen. De visar dock om en djupare undersökning behövs. Arbeta på kopior av loggarna och ändra inte misstänkta filer förrän tillståndet är säkrat. Vid fynd är en ordnad undersökning det säkra sättet. Stäng i så fall inte bara av servern och sätt inte omedelbart upp den på nytt, eftersom spår då går förlorade som är viktiga för bedömningen av anmälningsplikt och för en eventuell polisanmälan.
Härda servern långsiktigt
Efter den akuta patchen följer grundsäkringen. Den förhindrar inte varje sårbarhet men begränsar skadan och förkortar reaktionstiden nästa gång. Följande punkter har visat sig fungera:
- Åtkomster: SSH endast med nyckel, ingen direkt root-inloggning, administrationsgränssnitt nåbara bara från kända nät.
- Brandvägg: öppna bara de portar som verkligen behövs och begränsa webbserverns utgående anslutningar.
- PHP-konfiguration: inaktivera farliga funktioner,
open_basedirper webbplats, egna pooler och användare per applikation. - Filrättigheter: webbservern får inte skriva till programkod, uppladdningskataloger kör ingen PHP.
- Uppdateringar: installera säkerhetsuppdateringar automatiskt och planera in omstart och kontroll.
- Säkerhetskopior: kopior enligt 3-2-1-regeln, minst en kopia utanför servern och skyddad mot ändring.
- Loggar: samla loggar centralt och spara dem tillräckligt länge.
Hur en tillförlitlig säkerhetskopia ser ut beskrivs under Säkerhetskopior enligt 3-2-1-regeln. Som ramverk för företag passar BSI:s IT-Grundschutz.
När en managed server är det bättre valet
En egen server lönar sig om någon tillförlitligt tar över skötseln: följer uppdateringar, bedömer lägen som PHP2Shell och kan reagera på natten. Saknas den kapaciteten är antingen en managed server eller ett fast underhållsavtal meningsfullt. I båda fallen är det viktigt att dokumentera ansvarsfördelningen skriftligt. Mer om det under Managed server: klargör ansvaret.
Hur hjälper PHP SOS konkret?
- Vi kartlägger alla PHP-installationer, paketkällor och tjänster på er server och bedömer den faktiska patchstatusen.
- Vi installerar uppdateringar, startar om alla processer och dokumenterar resultatet.
- Vi kontrollerar servern med avseende på spår av ett intrång och säkrar loggar för en senare utvärdering.
- Inom ramen för vår serverhärdning sätter vi upp åtkomster, brandvägg, PHP-pooler och rättigheter på ett ordentligt sätt.
- På begäran tar vi över den löpande skötseln via ett säkerhetsunderhållsavtal.
Vanliga frågor
Patchar mitt datacenter min vServer automatiskt?
Med ohanterade root-servrar och vServrar i regel inte. Leverantören tillhandahåller hårdvara eller virtualisering och nät, men operativsystemet och alla tjänster på det sköter ni själva. Kontrollera ert avtal om ni är osäkra.
Räcker automatiska säkerhetsuppdateringar?
De hjälper men ersätter inte kontrollen. Automatiska uppdateringar startar inte alltid om PHP-processer som redan körs och täcker ofta inte paket från tredjepartskällor. Kontrollera paketstatus och processernas starttider efter varje säkerhetsuppdatering.
Hur får jag reda på om mitt paket innehåller en backport?
I paketets ändringslogg och i säkerhetsmeddelandena från er distribution. Står CVE-numret där finns rättningen med, även om versionsnumret ser äldre ut. Saknas posten klarar ni ut läget innan ni klassar servern som patchad.
Vad gör jag om ingen patch kommer för min PHP-version?
PHP 8.1 och äldre får inga officiella uppdateringar längre. Sätt de tillfälliga åtgärderna enligt php.net, planera snabbt ett byte till en version som stöds och ta enligt BSI:s rekommendation vid behov servern tillfälligt offline.