Kritisk PHP-sikkerhedsopdatering: sådan beskytter I jeres hjemmeside

Den 21. oktober 2026 udsendte PHP-projektet en kritisk PHP-sikkerhedsopdatering, der lukker to sårbarheder i PHP, som kan lade en angriber køre kode på jeres server uden at logge ind (fjernkørsel af kode, RCE). Det rammer næsten alle hjemmesider og webapplikationer bygget i PHP, også WordPress, WooCommerce, Laravel og Drupal. Her er, hvad sårbarhederne betyder, hvordan I tjekker jeres PHP-version, og hvordan vi kan hjælpe jer med at få opdateringen på plads nu.

Kernen i det

• To kritiske sårbarheder, CVE-2026-109618 og CVE-2026-109619, begge vurderet 9,2 (CVSS v4.0).
• En angriber behøver hverken login eller en fejl i jeres egen kode.
• Rettet i PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Kun en opdatering løser problemet helt.
• PHP 8.1 og ældre får ingen officiel opdatering. Kører I dem, skal I opgradere.
• På et webhotel er det som regel udbyderen, der opdaterer, men I skal selv kontrollere, at det er sket.

Hvad PHP-sikkerhedsopdateringen retter

PHP-holdet beskriver to fejl i den måde, PHP håndterer sine interne data på under en forespørgsel:

• Fejl ved hukommelsesmangel (CVE-2026-109618). Løber PHP tør for hukommelse midt i en forespørgsel, kan interne data stå halvt klargjort. Oprydningen bagefter kan så behandle de ugyldige data, som om de var gyldige.
• Gammel tilstand mellem forespørgsler (CVE-2026-109619). Data, der hører til én forespørgsel, kan overleve, efter hukommelsen er frigivet. En senere forespørgsel i samme proces kan bruge dem, før de bliver nulstillet.

Begge fejl kan føre til fjernkørsel af kode. Ifølge PHP-holdet er risikoen størst på Apache med mod_php, hvor de har vist et angreb, der virker, før jeres egen applikation overhovedet kører. Selv en velholdt og opdateret WordPress-side er altså ikke beskyttet, hvis PHP under den mangler opdateringen. Den fulde tekniske beskrivelse står i PHP-projektets sikkerhedsmeddelelse.

Hvem er berørt af PHP-sårbarheden?

Ifølge PHP-holdet er alle PHP-installationer, der besvarer webforespørgsler, berørt: PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP og LiteSpeed. Det dækker stort set alle måder at drive en PHP-hjemmeside på. I praksis betyder det blandt andet:

• WordPress- og WooCommerce-sider, uanset hvilke plugins de bruger.
• Applikationer bygget i Laravel, Symfony eller ren PHP.
• Kundeportaler, bookingsystemer og interne værktøjer.
• Ældre systemer, som ingen længere vedligeholder.

Den sidste gruppe er den farligste. Et system, ingen har rørt i årevis, kører ofte på PHP 7.4 eller 8.0, og de versioner får ingen officiel opdatering. PHP-holdet har lagt minimale rettelser til 7.4, 8.0 og 8.1 ud som kildekode, men det kræver, at nogen selv bygger PHP, og det er ikke en langsigtet løsning.

Sådan hjælper vi med PHP-opdateringen

Har I ikke tid eller folk til at håndtere det selv, tager vi opgaven fra start til slut:

• Tjek af jeres PHP-version. Vi finder ud af, hvilken version jeres hjemmesider og systemer faktisk kører, også når serveren bruger en distributionspakke, hvor nummeret ikke fortæller det hele.
• Opdatering af PHP. Vi opdaterer PHP på jeres server eller tager dialogen med jeres hostingudbyder og kontrollerer bagefter, at den nye version er aktiv.
• Midlertidig afhjælpning. Må opdateringen vente, sætter vi de anbefalede tiltag korrekt op, så de faktisk virker.
• Opgradering fra PHP 7.4, 8.0 og 8.1. Vi opdaterer plugins, temaer og egen kode, tester på en kopi og flytter jer til en understøttet version.
• Test efter opdateringen. Vi gennemgår formularer, login, betaling og fejllog, så I ved, at siden virker.
• Løbende vedligeholdelse. Med vores softwarevedligeholdelse holder vi PHP, WordPress og plugins opdateret, så næste sikkerhedsopdatering ikke kommer bag på jer.

Sådan tjekker I jeres PHP-version

• WordPress: Værktøjer → Webstedshelbred → Info → Server viser den PHP-version, siden kører på.
• Webhotel: Kontrolpanelets PHP-indstillinger, ofte kaldet “Select PHP Version” eller “MultiPHP Manager”.
• Egen server: php -v virker, men kommandolinjen kan bruge en anden PHP end webserveren. Tjek også, hvad webserveren selv kører.

Et nummer under de rettede versioner, fx 8.4.26, betyder som udgangspunkt, at opdateringen mangler. Der er én vigtig undtagelse. Linux-distributioner som Debian, Ubuntu og Red Hat lægger ofte rettelser ind i deres egne pakker uden at ændre versionsnummeret, og PHP-holdet oplyser, at distributionerne fik rettelserne på forhånd. Kører jeres server på distributionens pakker, skal I derfor tjekke distributionens sikkerhedsmeddelelse eller pakkens ændringslog, ikke kun nummeret.

Når I ikke kan opdatere PHP i dag

PHP-holdet er tydeligt: kun en opdatering løser problemet. Indtil den er på plads, beskriver de en række midlertidige tiltag, der mindsker risikoen ved de kendte angrebsveje uden at gøre installationen sikker. De mest overkommelige er:

• Slå session.upload_progress.enabled fra i php.ini eller serverkonfigurationen, og genstart alle PHP-processer. Det virker ikke via ini_set() eller en .user.ini-fil.
• Sæt en lav post_max_size: 8M, hvis siden ikke modtager filer, og 32M, hvis den gør.
• Begræns størrelsen af forespørgsler og antallet af felter på webserveren eller proxyen.

Andre tiltag på listen, fx at fjerne PHP’s hukommelsesgrænse, har deres egne konsekvenser for driften og bør kun laves af nogen, der kender serveren. Brug tiltagene som en bro til opdateringen, ikke som en erstatning for den.

Opdatér PHP uden at noget går i stykker

En opdatering inden for samme version, fx fra 8.4.26 til 8.4.27, er en ren sikkerhedsrettelse og ændrer normalt ikke, hvordan jeres kode opfører sig. Den er lav risiko og bør ske nu.

Det store arbejde ligger hos dem, der står på PHP 8.1 eller ældre. Et spring til 8.3 eller 8.4 kan få gamle plugins, temaer eller egen kode til at fejle. Tag en backup, test på en kopi af siden, gennemgå fejlloggen, og opdater plugins og temaer, før I skifter PHP-version. Bemærk også, at PHP 8.2 kun får sikkerhedsrettelser til 31. december 2026, så står I på 8.2, er det tid til at planlægge næste skridt. Kender I ikke koden, giver en kodeaudit overblik over, hvad der skal rettes, før I opgraderer.

Ofte stillede spørgsmål

I praksis

Tjek jeres PHP-version i dag. Ligger den under de rettede versioner, så bed hostingudbyderen om opdateringen, eller opdater selv, og kontrollér bagefter, at den nye version er aktiv. Står I på en version, der ikke længere understøttes, så planlæg opgraderingen nu i stedet for at vente på den næste kritiske sårbarhed. Større opgraderinger og ombygninger af ældre PHP-systemer hjælper vi med gennem vores webudvikling og softwareudvikling.