Kritiske PHP-sårbarheder: Er jeres virksomhed berørt?

Kritiske PHP-sårbarheder: Ved I, om jeres virksomhed er berørt?

 
To kritiske sårbarheder i PHP har på kort tid udviklet sig fra en teknisk sikkerhedsadvarsel til en aktuel trussel.

Sårbarhederne CVE-2026-109618 og CVE-2026-109619 har begge en CVSS-score på 9,2 ud af 10 og kan give en angriber mulighed for at køre kode på en sårbar server uden først at logge ind. CERT-EU anbefaler, at berørte systemer bliver opdateret med det samme. [cert.europa.eu]

For danske SMV’er er pointen ikke, at ledelsen skal forstå PHP. Pointen er, at I bør vide, om jeres virksomhed er berørt, og hvem der har ansvaret for at reagere.

PHP kan være en del af jeres IT, uden at I ved det

PHP er et udbredt programmeringssprog, der bruges bag mange websites og webapplikationer.

Men det er vigtigt ikke kun at tænke på virksomhedens hjemmeside.

PHP kan også være indbygget i kommercielle produkter, appliances, netværksenheder, administrationsinterfaces og andre leverandørprodukter. Derfor kan PHP være en del af virksomhedens IT-miljø, uden at virksomheden selv administrerer eller måske overhovedet er opmærksom på teknologien. [github.com]

Det gør den aktuelle situation relevant for langt flere virksomheder end dem, der selv udvikler PHP-løsninger. Det kan eksempelvis være et website eller en webapplikation, som administreres af et webbureau, en hostingpartner eller en anden ekstern leverandør.

Find derfor den PHP-version, jeres site kører på, der står i jeres hostingpanel og opdater til de nyeste versioner hurtigst muligt. Hvis det ikke allerede er sket, og kontroller, at sikkerhedsrettelsen faktisk er installeret. Spørg jeres hostingudbyder hvem, der sørger for rettelsen. Det eneste der fjerner hullerne i sikkerheden her, er en rettet PHP.

Det relevante spørgsmål for de fleste SMV’er er nu:

“Har vi fået afklaret, om nogle af vores løsninger er berørt?”

Hvor alvorlige er sårbarhederne?

De to sårbarheder kan muliggøre såkaldt remote code execution. Kort fortalt betyder det, at en angriber potentielt kan få mulighed for at køre kode på en sårbar server uden at være logget ind. [cert.europa.eu]

Det er netop derfor, sikkerhedsmyndighederne reagerer.

Den 21. oktober blev rettelser frigivet i PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35. CERT-EU anbefaler, at berørte systemer bliver opdateret straks. Hvis det ikke er muligt, anbefales det at overveje at isolere internetvendte applikationer fra offentlige netværk, indtil rettelsen er installeret og verificeret. [cert.europa.eu]

CERT-SE anbefaler desuden virksomheder at identificere PHP-baserede applikationer og undersøge systemerne for tegn på kompromittering. [cert.se]

Hvad betyder det konkret for en SMV?

Hvis I har en ekstern leverandør, der driver virksomhedens website, webshop eller andre webbaserede løsninger, er det ikke nødvendigvis jer selv, der skal installere opdateringen.

Men I bør få bekræftet, at nogen har håndteret det.

Det samme gælder produkter, hvor PHP ligger under overfladen. Det nederlandske NCSC fremhæver netop, at påvirkningen ikke begrænser sig til websites, fordi PHP også kan være indbygget i andre leverandørprodukter. Her kan virksomheden være afhængig af, at producenten eller leverandøren frigiver og installerer den nødvendige opdatering. [github.com]

Det gør ansvarsfordelingen helt central.

Jeres webbureau tror måske, at hostingpartneren håndterer det. Hostingpartneren håndterer måske serveren, men ikke et bestemt produkt. Og jeres interne IT-ansvarlige har måske ikke den pågældende løsning med i sit normale overblik.

Det afgørende er ikke, hvem der har ansvaret. Det afgørende er, at ansvaret er tydeligt placeret.

3 spørgsmål, I bør få svar på

Hændelsen er en god anledning til at kontrollere, om jeres virksomhed har det nødvendige overblik og klare ansvarsforhold.

1. Hvordan ved vi, om vores PHP-løsninger er berørt?

Start med at få afklaret om virksomheden har systemer, der anvender berørte versioner af PHP.

Få jeres IT-, hosting- eller webleverandør til at afklare, om PHP indgår i jeres internetvendte websites, applikationer eller andre relevante produkter.

Det gælder også tredjepartsløsninger og produkter med indbygget PHP. NCSC-NL anbefaler specifikt at identificere PHP-baserede applikationer og deres runtime-versioner med prioritet på internetvendte systemer.

Ledelsen behøver ikke kende den tekniske konfiguration. Men virksomheden bør vide, hvem der gør.

2. Er de nødvendige sikkerhedsopdateringer installeret?

Det er ikke nok at antage, at et system eller en leverandør automatisk har håndteret problemet.

Få det bekræftet.

For nogle driftsmiljøer kan en sikkerhedsrettelse være installeret som en såkaldt backport. Curanet fremhæver eksempelvis CloudLinux, hvor PHP kan være sikkerhedsopdateret, selv om versionsnummeret ser uændret ud. [VS: Kritis…befalinger | Outlook] 
 
De rettede PHP-versioner er 8.5.12, 8.4.27, 8.3.36 og 8.2.35. For ældre versioner kan distributioner og LTS-leverandører stille backportede sikkerhedsrettelser til rådighed.

Kontrollen bør derfor handle om, hvorvidt den relevante sikkerhedsrettelse er implementeret, og ikke kun om hvilket versionsnummer der står på systemet.

3. Er der tegn på kompromittering og er det tydeligt, hvem der har ansvaret?

Ansvaret kan ligge hos jeres egen IT-ansvarlige eller hos en hosting-, web- eller IT-leverandør. CERT-SE anbefaler organisationer både at opdatere berørte systemer og undersøge dem for tegn på kompromittering. [cert.se]

Det bør derfor også indgå i dialogen med den leverandør eller IT-partner, der har ansvaret for løsningen.

Det afgørende er, at ansvaret er tydeligt placeret. Nogen skal holde øje med kritiske sårbarheder, vurdere om virksomhedens løsninger er berørt og sikre, at nødvendige opdateringer bliver gennemført.

Hvis det er uklart, hvem der gør det, har virksomheden et hul i sit IT-sikkerhedsberedskab.

Det handler ikke kun om PHP

De aktuelle PHP-sårbarheder illustrerer en større udfordring for SMV’er.

I er sandsynligvis afhængige af langt flere teknologier, komponenter og leverandører, end ledelsen har behov for at kende navnene på.

Og sådan skal det også være.

En direktør skal ikke holde øje med nye PHP-versioner eller læse CVE-advarsler.

Men virksomheden bør have en proces, der sikrer, at nogen gør.

Det kræver klare svar på:

• Hvilke systemer er kritiske for vores forretning?

• Hvem holder øje med nye kritiske sårbarheder?

• Hvem vurderer, om vores løsninger er berørt?

• Hvem sørger for sikkerhedsopdateringer?

• Hvem kontrollerer, om de er gennemført?

• Og hvem reagerer, hvis der er tegn på, at et system allerede er blevet kompromitteret?

Det er her, god IT-drift og IT-sikkerhed mødes.

Ved I, hvem der reagerer, når en kritisk sårbarhed opstår?

PHP-sårbarhederne er aktuelle lige nu. Men den vigtigste læring handler ikke kun om PHP.

Den handler om at have overblik over virksomhedens løsninger, klare ansvarsområder og en fast proces for at reagere, når kritiske sikkerhedsproblemer opdages.

For en SMV er målet ikke at blive ekspert i den enkelte sårbarhed.

Målet er at kunne få et hurtigt og dokumenteret svar på:

Er vi berørt? Er problemet håndteret? Og hvem har ansvaret?

Er I usikre på, om jeres løsninger er berørt, eller hvem der har ansvaret for sikkerhedsopdateringerne?

Tal med MainBrain, og få afklaret jeres setup og ansvar.