Kort sagt: PHP2Shell er to kritiske sårbarheder i selve PHP, som angribere kan udnytte til at køre skadelig kode uden login. Hvis I hurtigt har brug for hjælp til denne PHP-sårbarhed, overtager vi på afstand opgørelsen, rettelsen eller en midlertidig foranstaltning, genstarten af alle PHP-processer og en første sporsøgning. Til sidst får I en skriftlig dokumentation af status.
Hjælp til PHP-sårbarheden: hvorfor der skal handles nu
Den 21.10.2026 kl. 16 tysk tid offentliggjorde PHP-projektet rettelser til CVE-2026-109618 og CVE-2026-109619. Begge sårbarheder er vurderet til CVSS v4.0 9,2 og gør det muligt at køre skadelig kode på afstand, uden at nogen skal logge ind. Berørt er de sædvanlige driftsformer: PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP og LiteSpeed.
BSI (det tyske forbundsagentur for informationssikkerhed) har udsendt advarselsniveau 3 (orange). Det anbefaler en øjeblikkelig opdatering og, hvis den ikke kan gennemføres med det samme, midlertidigt at tage webserverne af nettet. Palo Alto Networks (Unit 42) talte mere end 22,6 millioner eksponerede, potentielt sårbare instanser. Bekræftede vellykkede angreb i bredden var ifølge BSI først ikke kendt, men Cloudflare har allerede meldt om angrebsforsøg.
For direktion og ejere betyder det: Hver offentligt tilgængelig PHP-server er en kandidat, indtil det modsatte er dokumenteret. En letforståelig forklaring på sårbarheden finder I under Hvad er PHP2Shell?.
Hvem er PHP2Shell-akuthjælpen til?
Til virksomheder, bureauer og offentlige myndigheder, som driver PHP-applikationer, og som ikke selv kan eller vil løse situationen i den nødvendige dybde. Det gælder egne rootservere og vServere lige så vel som servere med Plesk eller cPanel, containermiljøer og managed servere, hvor ansvaret er uklart.
Også den, der har en hostingudbyder, har ofte brug for støtte. Mange udbydere indspiller backports; så viser f.eks. Plesk fortsat 8.2.34, selv om pakkestatus er rettet. Omvendt kan et nyt versionsnummer blive vist, mens gamle PHP-processer stadig kører i hukommelsen. Hvilke versioner der gælder som rettede, står under Hvilke PHP-versioner er berørt?.
Hvordan hjælper PHP SOS konkret?
- Opgørelse: Vi registrerer alle PHP-installationer, driftsformer og versioner på jeres servere, inklusive pakkestatus og kørende processer. Resultatet er en liste over, hvilke systemer der er berørt, rettede eller uklare.
- Rettelse eller midlertidig foranstaltning: Hvor det er muligt, indspiller vi de rettede versioner (8.5.12, 8.4.27, 8.3.36, 8.2.35) eller pakkerne fra jeres distribution. Hvis det ikke kan lade sig gøre med det samme, gennemfører vi de midlertidige foranstaltninger efter php.net og siger åbent, at de ikke giver fuld beskyttelse.
- Genstart og kontrol: Vi genstarter alle PHP-workers og -processer og kontrollerer bagefter, at ingen gammel proces kører længere. Nye filer alene lukker ikke sårbarheden.
- Første sporsøgning: Vi sikrer serverlogs fra og med 20.10. og leder efter uregelmæssigheder som nye PHP-filer, ukendte cronjobs eller usædvanlige processer. Da der ikke findes offentliggjorte, bekræftede Indicators of Compromise, bygger denne kontrol på adfærdsanalyse.
- Dokumentation og næste skridt: I får en skriftlig rapport. Ved mistanke om kompromittering anbefaler vi de passende opfølgende skridt, f.eks. fjernelse af malware eller en forensisk undersøgelse.
En rettelse fjerner ikke skadelig software, der allerede er blevet indsmuglet, og beviser ikke, at der ikke skete noget før. Derfor hører et blik på perioden siden 17.10.2026 altid med til akuthjælpen.
Hvad I får fra os
- en oversigt over alle kontrollerede servere med PHP-version, pakkestatus, driftsform og rettelsesstatus
- dokumentationen af de indspillede opdateringer eller de midlertidige foranstaltninger, der er sat i værk
- dokumentationen for, at alle PHP-processer er blevet genstartet
- en vurdering af sporsøgningen, opdelt i dokumenteret, sandsynligt og ukendt
- en liste over åbne punkter, f.eks. systemer med PHP 8.1 eller ældre
Denne rapport kan I give videre til direktionen, databeskyttelsesrådgiveren eller forsikringsselskabet. Den erstatter ikke den juridiske vurdering.
Hvad vi har brug for fra jer
- Adgang: SSH- eller panel-adgang med tilstrækkelige rettigheder, alternativt en tilladelse til, at jeres hostingudbyder må give os oplysninger
- Kontaktperson: en person, som må træffe beslutninger, f.eks. om en kort offlinedrift eller en genstart
- Overblik: hvilke websites, shops og applikationer der kører på hvilke servere
- Vedligeholdelsesvindue: jeres retningslinjer for, hvornår genstarter må finde sted
- Backups: oplysning om, hvor de aktuelle sikkerhedskopier ligger
For administratorer, som vil kontrollere på forhånd, er dette ufarlige blik på status ofte nok:
php -v
# Debian/Ubuntu: installerede PHP-pakker med version
dpkg -l | grep -i php
# kørende PHP-processer og deres starttidspunkt
ps -eo pid,lstart,cmd | grep -i php
Hvad vi ikke lover
Vi lover ingen absolut sikkerhed og ingen udtalelse om, at jeres server aldrig blev angrebet, hvis dokumentationen ikke bærer det. Vi arbejder på hændelsen, indtil den er afsluttet og dokumenteret. Om der består en anmeldelsespligt efter GDPR, eller om jeres forsikring skal informeres, afklarer I med databeskyttelsesrådgiveren, en advokat eller forsikringsselskabet. Vi leverer de tekniske fakta hertil.
Hvis I kun har brug for opdateringen med dokumentation, passer vores PHP-patch-service. Er der allerede tegn på et angreb, er akuthjælp ved hacket website det rigtige sted at starte.
Ofte stillede spørgsmål
Er det nok, at min hostingudbyder har opdateret PHP?
Det kan være nok, hvis hostingudbyderen skriftligt bekræfter pakkestatus, og alle PHP-processer er blevet genstartet. Det viste versionsnummer alene er ikke noget bevis, fordi distributioner indspiller backports. Om serveren allerede var blevet angrebet før, besvarer en rettelse under alle omstændigheder ikke.
Skal mit website gå offline under akuthjælpen?
Ikke nødvendigvis. BSI (det tyske forbundsagentur for informationssikkerhed) anbefaler midlertidigt at tage webservere af nettet, hvis opdateringen ikke kan gennemføres med det samme. Om det er nødvendigt hos jer, afgør vi sammen efter opgørelsen.
Beskytter en WordPress- eller Shopware-opdatering mod PHP2Shell?
Nej. PHP2Shell sidder i selve PHP, ikke i CMS'et. En CMS-opdatering er fortsat fornuftig, men lukker ikke denne sårbarhed.
Hvad sker der ved PHP 8.1 eller ældre?
For disse versioner findes der ikke længere officielle opdateringer fra PHP-projektet, kun minimale kildekode-backports til 7.4, 8.0 og 8.1. Vi sikrer serveren midlertidigt og planlægger sammen med jer skiftet til en understøttet version.