Aktuel situation: PHP2Shell. To kritiske PHP-sårbarheder (CVSS 9,2) tillader skadelig kode uden login. Rettelser siden 21.10.2026.Hvad der skal gøres nu →

Ofte stillede spørgsmål

Kort besvaret. Uddybende information finder I på de linkede vidensider.

Hvad er PHP2Shell?

PHP2Shell betegner to kritiske sårbarheder i selve PHP (CVE-2026-109618 og CVE-2026-109619, CVSS 9,2). De kan give angribere mulighed for at køre skadelig kode på serveren uden login. Der findes rettelser siden 21.10.2026.

Hvilke PHP-versioner er sikre?

Rettelserne findes i PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Hostingudbydere og distributioner indspiller nogle gange backports uden at ændre versionsnummeret. Det afgørende er pakkens status eller udbyderens skriftlige bekræftelse.

Er en WordPress- eller shopopdatering nok?

Nej. Sårbarheden ligger i PHP, ikke i CMS'et. En CMS-opdatering lukker den ikke. Og en PHP-rettelse fjerner ikke skadelig kode, der allerede er blevet indsmuglet.

Hvor hurtigt kan I hjælpe?

Vi arbejder på afstand og går i gang, så snart adgangene er på plads. Skriv til os på WhatsApp med system, PHP-version og jeres observation. Så afklarer vi fremgangsmåden direkte.

Arbejder I også for bureauer og hostingkunder?

Ja. Vi arbejder direkte for virksomheder, i baggrunden på vegne af bureauer og i samråd med jeres hostingudbyder, hvis denne administrerer serveren.

Skal vi anmelde hændelsen?

Hvis personoplysninger kan være berørt, gælder der efter art. 33 GDPR som regel en anmeldelsesfrist på 72 timer fra det tidspunkt, hvor I fik kendskab til hændelsen. Om fristen finder anvendelse, afklarer I med jeres databeskyttelsesrådgiver. Vi leverer den tekniske dokumentation hertil.

Er PHP2Shell en WordPress-sårbarhed?

Nej. Sårbarhederne sidder i PHP, altså i det programmeringssprog, som WordPress, Shopware, TYPO3 og mange andre systemer kører på. En opdatering af CMS'et lukker dem derfor ikke. Afgørende er PHP-status på serveren.

Skal jeg som hostingkunde selv gøre noget?

Ved shared hosting indspiller som regel hostingudbyderen PHP-opdateringen. I bør dog få skriftligt bekræftet, at den PHP-version, I bruger, er rettet og genstartet. Om der skete noget før rettelsen, besvarer opdateringen ikke.

Hvor kommer navnet PHP2Shell fra?

Navnet beskriver følgen: Via PHP kan en angriber i værste fald få en kommandolinje, altså en shell, på serveren. De officielle betegnelser er CVE-numrene CVE-2026-109618 og CVE-2026-109619.

Er mit website allerede blevet angrebet, hvis det blev taget offline?

Ikke nødvendigvis. Nogle udbydere har af forsigtighed taget websites af nettet, som BSI anbefaler, hvis en opdatering ikke er mulig med det samme. Det er en beskyttelsesforanstaltning og ikke et bevis på et angreb.

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.

Fra hvornår løber de 72 timer?

Efter art. 33 GDPR fra det tidspunkt, hvor den dataansvarlige fik kendskab til bruddet. Hvornår det skal antages i det enkelte tilfælde, er en juridisk vurdering. Dokumentér derfor nøje, hvornår hvem havde hvilke oplysninger.

Skal enhver sikkerhedssårbarhed anmeldes?

Nej. En sårbarhed alene er endnu ikke et brud på beskyttelsen af personoplysninger. Anmeldelsespligt kan opstå, hvis der er tegn på, at uvedkommende havde eller kunne have adgang til sådanne data, og at der deraf opstår en risiko for de registrerede.

Hvad hvis jeg efter 72 timer endnu ikke ved alt?

Art. 33, stk. 4, GDPR tillader at eftersende oplysninger trinvis, hvis de ikke kan gives på samme tid. En forsinket anmeldelse skal begrundes. At vente på fuld klarhed er derfor som regel ingen grund til at lade fristen udløbe.

Hvem anmelder, hvis hostingudbyderen var berørt?

Anmeldelsespligtig er den dataansvarlige, altså som regel den virksomhed, der driver websitet. En databehandler som hostingudbyderen skal efter art. 33, stk. 2, GDPR underrette den dataansvarlige uden unødig forsinkelse.

Hvor anmelder jeg et databrud?

Til den kompetente tilsynsmyndighed for databeskyttelse; for virksomheder i Tyskland er det som regel myndigheden i den delstat, hvor de har hjemsted. De fleste myndigheder tilbyder onlineformularer hertil.

Akut kontakt

Hver time tæller. Skriv til os nu.

Beskriv kort system, PHP-version og observation. Vi vender tilbage, afklarer situationen og arbejder på afstand, indtil hændelsen er afsluttet og dokumenteret.

Akut hjælp