PHP-sårbarheder – er der grund til panik, eller skal vi se lidt på virkeligheden?

To kritiske sikkerhedshuller i PHP har skabt bekymring blandt websiteejere. Men hvor stor er risikoen egentlig, og hvem har ansvaret, når et website ligger på et almindeligt webhotel?

I oktober 2026 blev der offentliggjort alvorlige sikkerhedssårbarheder i PHP, som blandt andet benyttes af WordPress og mange andre CMS-systemer.

Sårbarhederne har fået en CVSS-score på 9,2 ud af 10, hvilket placerer dem i den kritiske kategori. Under bestemte forhold kan fejlene give en angriber mulighed for at udføre kode på en server.

Men betyder det, at tusindvis af websites pludselig står åbne for hacking? Nej, ikke nødvendigvis. Der er forskel på, at en PHP-version indeholder en kendt sårbarhed, og at sårbarheden rent faktisk kan udnyttes på den enkelte server.

Hvad er problemet med PHP?

De aktuelle sikkerhedsfejl omfatter blandt andet CVE-2026-109618 og CVE-2026-109619. Den ene vedrører PHP’s håndtering af hukommelse, når en forespørgsel får systemet til at løbe tør for tilgængelig hukommelse. Det kaldes Out of Memory (OOM). Under særlige omstændigheder kan PHP efterfølgende komme til at arbejde med ugyldige hukommelsesområder. Det kan i værste fald føre til Remote Code Execution (RCE), hvor uvedkommende får mulighed for at udføre kode på serveren. Det er alvorligt, men det er ikke det samme som, at enhver server med en berørt PHP-version uden videre kan overtages. Den konkrete risiko afhænger blandt andet af serverens konfiguration, PHP’s integrationsform og mulighederne for at fremprovokere den nødvendige fejltilstand.

De fleste websiteejere administrerer ikke deres egen server

Langt de fleste mindre og mellemstore virksomheder har deres websites liggende på et almindeligt webhotel. Her er det hostingudbyderen, der administrerer den underliggende server, PHP-installationerne, operativsystemet og en væsentlig del af sikkerheden. En server kan have flere hundrede websites liggende, og kunderne kan benytte forskellige PHP-versioner. Det håndteres eksempelvis gennem PHP-FPM, separate brugerrettigheder og forskellige former for isolering. Det betyder ikke, at en sårbarhed hos én kunde automatisk giver adgang til alle andre websites på serveren. En korrekt opsat hostingplatform skal begrænse mulighederne for, at et kompromitteret website påvirker andre kunder. Isolering fjerner dog ikke en sårbarhed i PHP. Den kan begrænse konsekvenserne af et angreb, men sikkerhedsrettelserne skal stadig installeres.

Hvorfor bliver PHP ikke bare opdateret?

Hvis en PHP-version indeholder en kritisk sikkerhedsfejl, hvorfor opdaterer man så ikke bare til den nyeste version? I praksis er det ikke altid så enkelt. Jeg har gennem mange års arbejde med websites oplevet WordPress-installationer og andre PHP-baserede CMS-systemer, hvor gamle templates, plugins og specialudviklede funktioner ikke længere understøtter nyere PHP-versioner. En opgradering kan betyde, at funktioner holder op med at virke, eller at hele websitet får fejl. I nogle tilfælde er det oprindelige template ikke blevet vedligeholdt i årevis. Andre gange er et vigtigt plugin blevet opgivet af udvikleren. Det er ikke et argument for at undlade sikkerhedsopdateringer. Tværtimod viser det, hvorfor løbende vedligeholdelse er nødvendig.

De gamle CMS-installationer kan være et større praktisk problem

Mens der bliver skrevet om nye PHP-sårbarheder, findes der stadig mange websites med mere almindelige sikkerhedsproblemer: CMS-installationer, som ikke er blevet opdateret i flere år, plugins med kendte sikkerhedshuller, templates uden vedligeholdelse og specialudviklede funktioner, som ingen længere har overblik over. Her kan angribere ofte benytte automatiserede værktøjer til at finde og forsøge at udnytte kendte fejl. For et konkret website kan sådanne problemer udgøre en større og mere umiddelbar risiko end en ny PHP-sårbarhed, der kræver særlige tekniske omstændigheder. Det afhænger naturligvis af de konkrete sårbarheder og servermiljøet. Et website bliver ikke automatisk sikkert, fordi PHP er opdateret, hvis resten af installationen stadig indeholder kendte sikkerhedshuller.

Hvad betyder en CVSS-score på 9,2?

CVSS står for Common Vulnerability Scoring System og bruges til at beskrive den tekniske alvor af sikkerhedssårbarheder. En score på 9,2 ud af 10 betegnes som kritisk. Men scoren er ikke en beregning af sandsynligheden for, at et bestemt website bliver hacket. Den fortæller heller ikke, at 92 procent af alle berørte websites kan kompromitteres. Scoren bygger på tekniske forhold, herunder angrebets kompleksitet, nødvendige forudsætninger og mulige konsekvenser. Når risikoen for et konkret website skal vurderes, er det nødvendigt også at se på serverkonfigurationen, eksponeringen og de eksisterende sikkerhedsforanstaltninger.

Hvad bør man gøre som websiteejer?

Først bør man undersøge, hvilken PHP-version websitet benytter. For de aktuelle sårbarheder er der offentliggjort rettelser i PHP 8.2.35, 8.3.36, 8.4.27 og 8.5.12. Benytter man en berørt version, bør den opdateres hurtigst muligt. På et almindeligt webhotel kan man kontakte hostingudbyderen og få oplyst, om den nødvendige sikkerhedsrettelse er installeret. Kontrollér samtidig, om CMS-systemet, plugins og templates er opdaterede. Inden større ændringer gennemføres, skal der være en fungerende sikkerhedskopi. Hvis en PHP-opgradering skaber kompatibilitetsproblemer, bør den gamle kode opdateres eller udskiftes frem for permanent at fortsætte på en usikker version.

Sikkerhed handler om hele installationen

Jeg har arbejdet med websites og søgemaskineoptimering siden 1999 og har gennem årene set mange forskellige servermiljøer og CMS-installationer.

En ting går igen: Sikkerhedsproblemer opstår ikke kun på grund af én bestemt PHP-version. De opstår også, når vedligeholdelsen bliver forsømt, når plugins ikke længere opdateres, eller når gamle templates gør det vanskeligt at gennemføre nødvendige ændringer.

De aktuelle PHP-sårbarheder er alvorlige, og sikkerhedsrettelserne bør installeres hurtigst muligt. Men det giver ikke mening at skabe panik uden samtidig at forklare, hvor problemerne ligger, og hvem der har mulighed for at løse dem.

Sikkerhed handler ikke kun om at reagere, når der kommer en kritisk advarsel. Det handler om at vedligeholde hele installationen, også når der ikke er nogen, der råber op.

Kilder: PHP-projektet · PHP Security Advisory (GitHub)