Kort sagt: Den, der selv administrerer en root-server eller vServer, må også selv sikre den efter PHP2Shell: bring PHP-pakker op på en rettet status, genstart alle PHP-processer, og kontrollér resultatet. Datacenteroperatøren tager sig som regel kun af hardware, virtualisering og net. Derefter kan det betale sig at hærde serveren varigt.
Jeres ansvar ved egen server
Ved en uadministreret root-server eller vServer lejer I regnekraft, ikke betjening. Operativsystem, webserver, PHP, database, firewall, sikkerhedskopier og overvågning ligger i jeres hænder. For ledelse og ejere betyder det: Hvis ingen i huset eller hos en tjenesteudbyder udtrykkeligt har overtaget disse opgaver, gør ingen dem.
PHP2Shell gør det synligt. De to sårbarheder CVE-2026-109618 og CVE-2026-109619 sidder i PHP selv og tillader kodeudførelse uden login. PHP-projektet udgav den 21.10.2026 versionerne 8.5.12, 8.4.27, 8.3.36 og 8.2.35. BSI (det tyske forbundsagentur for informationssikkerhed) anbefaler en øjeblikkelig opdatering og, hvis det ikke er muligt, at tage webserveren midlertidigt af nettet.
Sikring af vServer: kontrollér beholdning og pakkestatus
Skaf først et overblik over, hvilke PHP-versioner der er installeret, og hvilken kilde de stammer fra. Mange servere bruger ved siden af distributionens pakker yderligere pakkekilder. Følgende kommandoer læser kun. Pakkenavne er eksempler.
# Debian/Ubuntu: installerede PHP-pakker og deres oprindelse
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm
# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'
# Hvilke PHP-binærfiler findes overhovedet?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
Versionsnummeret alene er ikke nok. Distributioner leverer ofte sikkerhedsrettelser som backport, og det viste nummer forbliver så ældre. Afgørende er pakkens ændringslog.
# Debian/Ubuntu (pakkenavn som eksempel)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'
# RHEL-familien (pakkenavn som eksempel)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'
En udførlig vejledning står under Kontrollér PHP-version og patch-status.
Indspil opdateringen og forny alle processer
Indspil opdateringerne via pakkehåndteringen, og genstart derefter hver tjeneste, der indlæser PHP. Afhængigt af opbygningen er det PHP-FPM, Apache med mod_php, LiteSpeed eller en applikationsserver. Nye filer på disken er ikke nok, så længe gamle processer kører i hukommelsen.
# Find tjenester med PHP
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'
# Vis processer med starttidspunkt
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep
# Debian/Ubuntu: genkend programmer med forældede biblioteker (hvis installeret)
needrestart -r l
Hver relevant proces bør være startet efter opdateringen. Værktøjet needrestart på Debian-systemer er nyttigt, fordi det viser tjenester med forældede biblioteker. Detaljer om genstarten beskriver Genstart PHP-FPM og alle workere.
En patch fjerner ikke skadelig software, som blev smuglet ind før opdateringen. Gem webserverens logs fra og med 20.10.2026, og undersøg serveren for spor, før I klassificerer den som ren.
Til en første sporsøgning egner sig nogle kontroller, der ikke ændrer noget. Søg efter PHP-filer, der siden 17.10.2026 er oprettet eller ændret i webmapper, efter ukendte poster i alle brugeres crontabs, efter nye systembrugere og SSH-nøgler samt efter processer under webserverens bruger, som holder udgående forbindelser.
# PHP-filer ændret siden 17.10.2026 (sti som eksempel)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls
# Netværksforbindelser med tilhørende proces
ss -tupn
Ingen af disse kontroller beviser i sig selv et indbrud, og et tomt resultat beviser ikke det modsatte. De viser dog, om en dybere undersøgelse er nødvendig. Arbejd på kopier af logs, og ændr ikke mistænkelige filer, før tilstanden er sikret. Ved fund er en ordnet undersøgelse den sikre vej. Sluk i så fald ikke bare serveren, og opsæt den ikke straks på ny, for dermed går spor tabt, som er vigtige for vurderingen af anmeldelsespligter og for en mulig politianmeldelse.
Hærd serveren varigt
Efter den akutte patch følger grundsikringen. Den forhindrer ikke enhver sårbarhed, men begrænser skaden og forkorter reaktionstiden næste gang. Disse punkter har vist sig at virke:
- Adgange: SSH kun med nøgle, ingen direkte root-login, administrationsflader kun tilgængelige fra kendte net.
- Firewall: åbn kun de porte, der virkelig er brug for, og begræns webserverens udgående forbindelser.
- PHP-konfiguration: deaktivér farlige funktioner,
open_basedirpr. website, egne pools og brugere pr. applikation. - Filrettigheder: webserveren må ikke kunne skrive i programkoden, upload-mapper udfører ikke PHP.
- Opdateringer: indspil sikkerhedsopdateringer automatisk, planlæg genstart og kontrol fast.
- Sikkerhedskopier: kopier efter 3-2-1-reglen, mindst én kopi uden for serveren og beskyttet mod ændring.
- Protokoller: saml logs centralt, og opbevar dem længe nok.
Hvordan en pålidelig sikkerhedskopi ser ud, beskriver Sikkerhedskopier efter 3-2-1-reglen. Som ramme for virksomheder egner BSI's IT-Grundschutz sig.
Hvornår en managed server er det bedre valg
En egen server kan betale sig, hvis nogen pålideligt overtager vedligeholdelsen: følge opdateringer, vurdere situationer som PHP2Shell, kunne reagere om natten. Mangler denne kapacitet, er enten en managed server eller en fast vedligeholdelsesaftale fornuftig. Vigtigt er i begge tilfælde at fastholde ansvarsfordelingen skriftligt. Mere herom under Managed server: afklar ansvaret.
Hvordan hjælper PHP SOS konkret?
- Vi opgør alle PHP-installationer, pakkekilder og tjenester på jeres server og vurderer den faktiske patch-status.
- Vi indspiller opdateringer, genstarter alle processer og dokumenterer resultatet.
- Vi undersøger serveren for spor af et kompromis og sikrer logs til en senere analyse.
- Som led i vores serverhærdning opsætter vi adgange, firewall, PHP-pools og rettigheder ordentligt.
- På ønske overtager vi den løbende vedligeholdelse via en sikkerhedsvedligeholdelsesaftale.
Ofte stillede spørgsmål
Patcher mit datacenter min vServer automatisk?
Ved uadministrerede root-servere og vServere som regel ikke. Udbyderen stiller hardware eller virtualisering og net til rådighed, mens I selv administrerer operativsystemet og alle tjenester derpå. Kontrollér i tvivlstilfælde jeres kontrakt.
Er automatiske sikkerhedsopdateringer nok?
De hjælper, men erstatter ikke kontrollen. Automatiske opdateringer genstarter ikke altid kørende PHP-processer og dækker ofte ikke pakker fra eksterne kilder. Kontrollér efter hver sikkerhedsopdatering pakkestatus og processernes starttidspunkter.
Hvordan finder jeg ud af, om min pakke indeholder en backport?
I pakkens ændringslog og i jeres distributions sikkerhedsmeddelelser. Står CVE-nummeret dér, er rettelsen med, selv om versionsnummeret ser ældre ud. Mangler posten, så afklar status, før I klassificerer serveren som patchet.
Hvad gør jeg, hvis der ikke kommer en patch til min PHP-version?
PHP 8.1 og ældre får ikke længere officielle opdateringer. Sæt de midlertidige foranstaltninger efter php.net, planlæg hurtigt skiftet til en understøttet version, og tag om nødvendigt serveren midlertidigt af nettet efter BSI's anbefaling.