Kritiske PHP-sårbarheder: Har din virksomhed styr på teknologien bag hjemmesiden?
Kritiske PHP-sårbarheder: Har din virksomhed styr på teknologien bag hjemmesiden?
PHP udsendte den 21. oktober 2026 sikkerhedsopdateringerne 8.2.35, 8.3.36, 8.4.27 og 8.5.12 og opfordrede brugerne til at opdatere hurtigst muligt.
Hændelsen er særlig relevant, fordi PHP anvendes bag en lang række hjemmesider og digitale løsninger. Det betyder også, at en virksomhed kan være berørt, uden at ledelsen eller den IT-ansvarlige nødvendigvis er klar over det.
Fra sårbarhed til reel risiko
Virksomhedens risiko afhænger ikke kun af en sårbarheds tekniske alvor, men også af, om berørte systemer er interneteksponerede, og hvor hurtigt de kan identificeres og opdateres.
I PHP-sagen blev oplysninger om sårbarhederne hurtigt offentligt tilgængelige. Det reducerer potentielt den tid, virksomheder har til at identificere og beskytte berørte systemer, fordi samme information også kan anvendes til at udvikle eller tilpasse angreb.
Et konkret dansk eksempel viser, hvor hurtigt en sårbarhed kan få praktiske konsekvenser.
Sikkerhedsbrud hos DMI
I forbindelse med den globale udmelding om PHP-sårbarhederne konstaterede DMI efterfølgende, at uautoriserede personer den 22. oktober 2026 kl. 12 havde fået adgang til et brugeradministrationssystem bag NorthAvimet, en nordisk vejrportal, som piloter kan benytte til vejrinformation i forbindelse med flyvninger.
DMI lukkede hjemmesiden ned kl. 14 samme dag, sikkerhedsopdaterede den og genåbnede den senere på dagen. Inden da havde uvedkommende nået at downloade en liste med oplysninger om cirka 5.000 piloter. Oplysningerne omfattede navn, nationalitet, e-mailadresse, password i krypteret form samt nummeret på pilotens flycertifikat.
DMI og Trafikstyrelsen vurderede ikke umiddelbart databruddet som kritisk, men DMI vurderede, at omfanget af personoplysninger kunne udgøre en risiko for den enkelte bruger. De berørte brugere skulle derfor oprette nye passwords, og bruddet blev anmeldt til politiet og Datatilsynet.
Hændelsen illustrerer samtidig en vigtig pointe: Det er ikke nødvendigvis tilstrækkeligt blot at installere en sikkerhedsopdatering. Hvis et sårbart system har været eksponeret mod internettet, bør virksomheden også undersøge, om sårbarheden kan være blevet udnyttet, inden opdateringen blev installeret.
Det centrale budskab er derfor ikke alene, at virksomheder skal opdatere PHP. Hændelsen illustrerer et mere generelt problem:
- En organisation kan ikke beskytte de systemer og komponenter, den ikke ved, den har
- Udfordringen ligger også hos leverandørerne
- For mange virksomheder ligger hjemmesiden, webshoppen eller kundeportalen hos et webbureau, en hostingudbyder eller en anden IT-leverandør. Derfor kan det være fristende at antage, at leverandøren automatisk håndterer sikkerhedsopdateringer.
Det er ikke nødvendigvis tilfældet.
PHP kan også være indbygget i kommercielle produkter og open source-løsninger, selv om virksomheden ikke selv driver en synlig PHP-installation.
Virksomhedens overblik bør derfor række videre end egne servere og virksomhedens primære hjemmeside. Det bør også omfatte relevante leverandører og de internetvendte tjenester, som de driver på virksomhedens vegne.
At en hjemmeside eller løsning fungerer, er således ikke det samme som, at den er sikker eller fortsat supporteret.
Hvad bør virksomheder gøre nu?
PHP-hændelsen giver anledning til fem konkrete spørgsmål, som virksomheder med fordel kan stille deres IT-organisation eller leverandører:
1. Har vi overblik over vores internetvendte systemer? Identificér hjemmesider, webshops, kundeportaler, API'er, ældre kampagnesider, servere og andet internetvendt udstyr. Husk også løsninger, som drives på virksomhedens vegne af eksterne leverandører.
PHP-projektet offentliggjorde eksempelvis den 23. oktober en supplerende anbefaling vedrørende CVE-2026-115560, som vedrørte en særlig kombination af konfiguration og applikationskode. Det understreger behovet for løbende at følge sikkerhedsanvisningerne, også efter at den første opdatering er installeret.
3. Er de berørte systemer blevet opdateret?
Det er ikke tilstrækkeligt at konstatere, at en leverandør "står for IT". Bed om dokumentation for, at den relevante sikkerhedsopdatering er installeret, at relevante tjenester er genstartet, hvor det er nødvendigt, og at den aktive PHP-version efterfølgende er kontrolleret.
For outsourcede løsninger er det derfor relevant at spørge leverandøren konkret:
- Hvilken PHP-version anvender løsningen?
- Er de relevante sikkerhedsrettelser installeret?
- Hvornår blev de installeret?
- Var løsningen eksponeret, inden opdateringen blev gennemført?
- Er der foretaget kontrol for tegn på kompromittering?
4. Kan systemet allerede være kompromitteret?
DMI-hændelsen illustrerer netop betydningen af dette spørgsmål. At et system bliver opdateret, er ikke i sig selv ensbetydende med, at der ikke kan være sket noget inden opdateringen. Hvis en sårbar løsning har været tilgængelig fra internettet, bør virksomheden derfor ikke alene opdatere systemet. Logs og øvrige sikkerhedsdata bør også undersøges for tegn på mulig udnyttelse.
En korrekt installeret sikkerhedsopdatering reducerer risikoen for fremtidig udnyttelse af den konkrete sårbarhed, men dokumenterer ikke, at systemet ikke allerede er blevet kompromitteret. Det kan derfor være relevant at undersøge eksempelvis webserver- og applikationslogs, hændelser i virksomhedens EDR-løsning og usædvanlig aktivitet på de berørte servere.
5. Har vi en proces for den næste kritiske sårbarhed?
Virksomheden bør kende sine vigtigste systemer, deres ejere og leverandører og på forhånd have fastlagt, hvordan kritiske sårbarheder håndteres.
For kritiske internetvendte systemer bør processen gøre det muligt hurtigt at:
- identificere, om virksomheden anvender den berørte teknologi
- fastlægge, hvilke systemer og leverandører der er berørt
- vurdere systemernes eksponering
- installere eller verificere relevante sikkerhedsopdateringer
- iværksætte midlertidige sikkerhedstiltag, hvis en opdatering ikke umiddelbart er mulig
- undersøge, om sårbarheden allerede kan være blevet udnyttet.
PHP er den aktuelle hændelse, men problemet er større
Den vigtigste læring fra PHP-sagen er derfor ikke navnet på den konkrete teknologi.
Moderne IT-løsninger består af et stort antal komponenter, open source-biblioteker, cloudtjenester og leverandørløsninger. Når en kritisk sårbarhed offentliggøres, kan virksomheder få meget kort tid til at identificere og beskytte berørte systemer. Eksemplet fra DMI viser, hvorfor tiden er afgørende: Uautoriseret adgang blev registreret den 22. oktober kl. 12, og NorthAvimet blev lukket ned og sikkerhedsopdateret kl. 14. Alligevel var oplysninger om cirka 5.000 brugere allerede blevet downloadet. Derfor bliver overblik over aktiver, systemejerskab, leverandørstyring, patch management og evnen til hurtigt at reagere på nye sårbarheder afgørende elementer i virksomhedens cybersikkerhed.
PHP-hændelsen er et godt eksempel på dette. Spørgsmålet for den enkelte virksomhed bør derfor ikke kun være: "Har vi fået opdateret PHP?" Det mere væsentlige spørgsmål er: "Hvis den næste kritiske sårbarhed offentliggøres i morgen, ved vi så, om vi er berørt, og hvem der skal reagere?"
/Employees/MLA.jpg)