To alvorlige fejl i programmeringssproget PHP udløste den 21. oktober en akut sikkerhedskrise for hjemmesideejere og IT-afdelinger verden over. Hackere havde allerede forsøgt at udnytte sårbarhederne, inden rettelserne blev offentliggjort. Nu står det klart, hvorfor fejlene er så farlige – og hvorfor de kan få betydning for millioner af hjemmesider.
For en kort stund blev den normale arbejdsdag afløst af noget helt andet hos serveradministratorer og IT-folk verden over.
To kritiske sikkerhedshuller i PHP, et af de mest udbredte programmeringssprog bag hjemmesider, krævede pludselig øjeblikkelig opmærksomhed.
Servere skulle undersøges. Software skulle opdateres. Og hjemmesider skulle kontrolleres for at sikre, at de fortsat fungerede efter opdateringerne.
Det var ikke, fordi hele internettet gik ned. Men for de IT-folk, der havde ansvaret for berørte systemer, måtte andre opgaver vige for en akut sikkerhedstrussel.
Onsdag den 21. oktober 2026 frigav udviklerne bag PHP sikkerhedsrettelser til to alvorlige sårbarheder.
De to fejl, der har fået betegnelserne CVE-2026-109618 og CVE-2026-109619, omtales samlet som PHP2Shell.
Begge er blevet vurderet til 9,2 ud af 10 på sikkerhedsskalaen CVSS 4.0.
Og det mest bekymrende er, at hackere allerede havde forsøgt at udnytte problemerne.
Hackere behøver ikke engang kende adgangskoden
Normalt forestiller mange sig, at en hacker skal stjæle et password eller narre en medarbejder til at åbne en mistænkelig mail for at få adgang til en server.
Men disse sårbarheder kan under bestemte forhold udnyttes uden nogen af delene.
Problemerne findes nemlig i PHP’s egen håndtering af computerens hukommelse.
Ved at sende særligt konstruerede forespørgsler til en sårbar server kan en angriber forsøge at få PHP til at udføre kode, som serverens ejer aldrig har godkendt.
Det kaldes Remote Code Execution, eller RCE.
På almindeligt dansk betyder det, at en hacker på afstand kan få en server til at udføre kommandoer.
Afhængigt af serverens opsætning kan konsekvenserne blandt andet være, at hackeren får mulighed for at ændre filer, stjæle oplysninger eller installere skadelig software.
Det betyder ikke automatisk, at alle PHP-hjemmesider kan overtages. Risikoen afhænger af blandt andet PHP-versionen, serverens opsætning og mulighederne for at udnytte fejlene.
Men potentialet er alvorligt nok til, at sikkerhedsrettelserne bør prioriteres højt.
To fejl gemte sig dybt inde i PHP
De to sikkerhedshuller er forskellige, men begge handler om, hvordan PHP arbejder med hukommelsen.
Den første, CVE-2026-109618, opstår i særlige situationer, hvor PHP når en hukommelsesgrænse.
Under bestemte omstændigheder kan PHP efterlade interne oplysninger i en tilstand, som programmet ikke håndterer korrekt.
Når systemet efterfølgende forsøger at rydde op, kan det føre til, at ugyldige data bliver behandlet.
Den anden sårbarhed, CVE-2026-109619, er en såkaldt use-after-free-fejl.
Det betyder, at et program forsøger at bruge et område af computerens hukommelse, efter at området egentlig er blevet frigivet.
Den slags fejl kan være særdeles farlige, fordi de under bestemte forhold kan udnyttes til at ændre et programs normale opførsel.
For almindelige hjemmesideejere er de tekniske detaljer ikke nødvendigvis det vigtigste.
Det afgørende er, at fejlene findes i den underliggende software, som mange forskellige hjemmesider er afhængige af.
Problemet begyndte flere år tidligere
En af de mest opsigtsvækkende detaljer ved sagen er, at tegn på mindst den ene fejl blev opdaget allerede i 2024.
Ifølge PHP Foundation opstod de første undersøgelser i forbindelse med arbejdet efter en ekstern sikkerhedsrevision.
Dengang var det endnu ikke påvist, at fejlen kunne bruges til at udføre fremmed kode på en server.
Udviklerne undersøgte forskellige muligheder for at rette problemet, men arbejdet viste sig vanskeligt.
Nogle løsninger kunne skabe kompatibilitetsproblemer med eksisterende PHP-software. Andre risikerede at introducere nye fejl.
PHP Foundation har efterfølgende beskrevet, hvordan både tekniske udfordringer og begrænsede ressourcer var med til at forsinke arbejdet.
I løbet af sommeren 2026 ændrede situationen sig.
Sikkerhedsforskere kunne nu demonstrere, hvordan problemerne under bestemte forhold kunne udnyttes til fjernudførelse af kode.
Dermed var der ikke længere blot tale om en teoretisk programmeringsfejl.
Det var blevet en konkret sikkerhedstrussel.
En lækage ændrede planerne
Sikkerhedsopdateringerne var oprindeligt planlagt til offentliggørelse den 22. oktober.
Men dagen før begyndte oplysninger om sårbarhederne at cirkulere offentligt.
Det fik PHP’s sikkerhedsteam til at fremskynde offentliggørelsen.
Den 21. oktober blev de nye sikkerhedsrettede PHP-versioner derfor frigivet.
For serveradministratorer betød det, at planlagte opgaver måtte udsættes, mens berørte systemer blev undersøgt og opdateret.
Og tidspunktet var langt fra tilfældigt.
For nogle angribere havde allerede opdaget mulighederne.
Amazon opdagede angreb fire dage før
Amazon Threat Intelligence har offentliggjort oplysninger om forsøg på at udnytte PHP2Shell allerede den 17. oktober.
Det var fire dage før de officielle opdateringer blev frigivet.
Angrebsforsøgene blev registreret gennem Amazons honeypot-systemer.
En honeypot er en slags digital fælde, hvor sikkerhedsforskere opstiller systemer, der skal tiltrække og registrere hackeraktivitet.
Formålet er at opdage angrebsmetoder og forstå, hvordan hackere arbejder.
Amazon registrerede efterfølgende yderligere forsøg på at udnytte sårbarhederne.
Observationerne viser, at der var tale om en reel trussel og ikke blot en teoretisk mulighed.
Det er dog vigtigt at skelne mellem angrebsforsøg og vellykkede hackerangreb.
Der foreligger ikke et pålideligt samlet tal for, hvor mange almindelige hjemmesider der faktisk er blevet kompromitteret gennem de to sårbarheder.
WordPress og webshops er blandt de potentielt berørte
PHP er en af de teknologier, der arbejder usynligt bag en stor del af internettet.
Blandt de kendte hjemmesidesystemer, der anvender PHP, er WordPress, Joomla og Drupal.
Det samme gælder mange webshops og specialudviklede hjemmesider.
Det betyder ikke, at samtlige installationer er sårbare.
Men hjemmesider, som kører på en berørt PHP-version uden de nødvendige sikkerhedsrettelser, kan være udsatte.
WordPress har selv advaret om problemet og opfordret hjemmesideejere til at sikre, at deres PHP-installationer bliver opdateret.
Og her ligger en detalje, som mange hjemmesideejere måske overser.
Det er ikke nok, at selve WordPress er opdateret.
Hvis PHP-versionen på serveren stadig er sårbar, kan der fortsat eksistere et sikkerhedsproblem.
Derfor er det også hostingudbyderne og serveradministratorerne, der spiller en afgørende rolle.
Også danske servere måtte opdateres
Sikkerhedsproblemerne skabte også ekstra arbejde i Danmark.
Hos Vores IT afdeling ApS blev både aftenen og natten den 21. oktober brugt på at opgradere virksomhedens Linux-servere og opdatere PHP.
Det er et eksempel på det arbejde, som ofte foregår bag kulisserne, når kritiske sikkerhedshuller bliver offentliggjort.
En serveropdatering kan nemlig være mere omfattende end blot at installere en ny softwarepakke.
Der skal tages hensyn til eksisterende hjemmesider, programmer, afhængigheder og serverkonfigurationer.
Efter opdateringen skal det desuden kontrolleres, at hjemmesiderne stadig fungerer korrekt, og at de opdaterede PHP-processer faktisk er taget i brug.
Det kan betyde mange timers arbejde uden for normal arbejdstid, særligt når flere servere og hjemmesider skal håndteres.
Hvilke versioner af PHP er sikre?
PHP-udviklerne har frigivet sikkerhedsrettelser i følgende versioner:
| PHP-serie | Sikkerhedsrettet version |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Hjemmesider, der anvender berørte versioner uden rettelserne, bør opdateres hurtigst muligt.
Det gælder også servere, der benytter ældre PHP-versioner.
Her skal administratorerne dog være opmærksomme på, at nogle Linux-distributioner vedligeholder ældre PHP-pakker med særskilte sikkerhedsrettelser.
Det betyder, at versionsnummeret ikke altid alene fortæller, om en server er beskyttet.
Det afgørende er, om den konkrete sikkerhedsrettelse er installeret.
Kan hjemmesider allerede være blevet hacket?
Ja, det er muligt.
Men der er forskel på, at en sårbarhed bliver forsøgt udnyttet, og at en hacker faktisk lykkes med at overtage et system.
Amazon har dokumenteret angrebsforsøg, men det giver ikke i sig selv et fuldstændigt billede af antallet af kompromitterede hjemmesider.
Der er heller ikke offentliggjort en verificeret samlet liste over større websites, som med sikkerhed er blevet overtaget via PHP2Shell.
For hjemmesideejere betyder det, at en opdatering er første skridt, men ikke nødvendigvis det eneste.
Hvis en server har været udsat, kan det også være relevant at gennemgå adgangslogs, undersøge mistænkelige filer og kontrollere, om der har været usædvanlig aktivitet.
En sikkerhedsopdatering lukker selve hullet, men fjerner ikke automatisk eventuel skadelig software, som en angriber allerede måtte have installeret.
Hvorfor kan sådan noget ske?
Mange forestiller sig måske, at software med millioner af brugere må være gennemtestet og fri for alvorlige fejl.
Virkeligheden er mere kompliceret.
Moderne software består af enorme mængder programkode, som løbende bliver ændret, udvidet og tilpasset.
Nogle fejl kan eksistere i årevis uden at blive opdaget.
Andre er kendte, men viser sig vanskelige at rette uden at ødelægge noget andet.
PHP2Shell-sagen illustrerer netop dette problem.
En fejl, der oprindeligt blev undersøgt som et teknisk problem med hukommelseshåndtering, viste sig senere at kunne få langt alvorligere konsekvenser.
Det er samtidig en påmindelse om, hvorfor sikkerhedsopdateringer er så vigtige.
De handler ikke kun om nye funktioner eller forbedret ydeevne.
Nogle gange handler de om at forhindre uvedkommende i at få adgang til en virksomheds systemer.
Hvad betyder det for almindelige danskere?
Hvis du blot besøger hjemmesider, er der normalt ikke noget, du selv kan gøre ved PHP-versionen på den server, du besøger.
Ansvaret ligger hos hjemmesidens ejer og dennes hostingudbyder.
Men hvis du driver en hjemmeside, webshop eller virksomhed med digitale tjenester, er situationen anderledes.
Så bør du sikre dig, at den ansvarlige IT-leverandør har undersøgt, om serveren er berørt, og at nødvendige rettelser er installeret.
For selv om en hjemmeside ser normal ud, kan der godt eksistere alvorlige sikkerhedsproblemer under overfladen.
Og hvis en angriber får adgang til en server, kan konsekvenserne i værste fald ramme både virksomheden og dens kunder.
Internettet gik ikke ned – men alarmen var reel
PHP2Shell er et tydeligt eksempel på, hvor sårbart det moderne internet kan være.
En fejl i et centralt programmeringssprog kan på få timer skabe et akut behov for opdateringer på servere verden over.
Det er ikke dokumenteret, at internettet som helhed blev sat ud af drift den 21. oktober.
Men for mange IT-afdelinger blev det en dag, hvor andre opgaver måtte vente.
Sikkerhedshullerne skulle lukkes, før angriberne fik mulighed for at udnytte dem.
Og med dokumenterede angrebsforsøg allerede før offentliggørelsen var der god grund til at reagere hurtigt.
For hjemmesideejere er budskabet enkelt: Det er ikke nok, at hjemmesiden virker. Softwaren bag den skal også være sikker.
