Kritisk PHP-sikkerhedshul: Det skal virksomheder gøre nu

To kritiske sårbarheder i PHP blev rettet den 21. oktober 2026, efter at oplysninger om dem var begyndt at cirkulere før den planlagte offentliggørelse. Fejlene, CVE-2026-109618 og CVE-2026-109619, er begge vurderet til 9,2 på CVSS v4.0 og kan under de rette forhold give en angriber mulighed for at køre kode på en webserver uden først at logge ind. PHP-projektet vurderer, at alle PHP-installationer, der håndterer webrequests, skal betragtes som berørte, selv om den praktiske udnyttelse afhænger af blandt andet serveropsætning, applikation og worker-livscyklus. Den vigtigste handling er derfor ikke at opdatere WordPress eller et sikkerhedsplugin, men at få verificeret og rettet den PHP-runtime, der faktisk betjener webtrafikken.

Det vigtigste at gøre nu: Få en teknisk ansvarlig til at kortlægge alle internetvendte PHP-systemer, dokumentere den effektive PHP-pakke og SAPI, installere den relevante rettelse eller leverandørens backport, genstarte eller genudrulle alle berørte workers og derefter kontrollere både forretningskritiske funktioner og tegn på kompromittering. PHP-projektets egen formulering er usædvanligt klar: “There are no complete mitigations, updating is the only safe choice.” (PHP-projektet, 21. oktober 2026↗, egen oversættelse: Der findes ingen fuldstændige afværgeforanstaltninger; opdatering er det eneste sikre valg).

Nyheden: To kritiske fejl i selve PHP udløste hasteopdateringer og forebyggende nedlukninger

PHP-projektet offentliggjorde den 21. oktober 2026 fire rettede udgivelser: PHP 8.2.35, 8.3.36, 8.4.27 og 8.5.12. Begge sårbarheder kan føre til unauthenticated remote code execution, altså fjernudførelse af kode uden forudgående login. Det er en alvorlig egenskab, fordi fejlen ligger i PHP-motoren under mange hjemmesider og webapplikationer, ikke i ét bestemt WordPress-plugin eller ét bestemt CMS. PHP fremhævede Apache med mod_php som den højeste risiko, fordi en demonstreret angrebsvej dér kan udløses, før applikationskoden overhovedet kører. PHP-FPM, php-cgi, FrankenPHP og LiteSpeed er også omfattet af risikovurderingen, men de konkrete veje til udnyttelse er ikke identiske.

CISA beskrev samme dag fejlene, der også omtales under navnet “php2shell”, som sårbarheder, der “allow for unauthenticated remote code execution in PHP” (CISA, 21. oktober 2026↗, egen oversættelse: kan muliggøre fjernudførelse af kode i PHP uden autentifikation). CERT-EU noterede samtidig, at “initial proofs of concept (PoCs) have begun to circulate” (CERT-EU, 21. oktober 2026↗, egen oversættelse: de første proof-of-concept-eksempler er begyndt at cirkulere). Det øgede tidspresset markant, fordi tekniske detaljer og demonstrationskode kunne omsættes til automatiserede scanninger og angrebsforsøg.

Det er vigtigt at skelne mellem angrebsforsøg, vellykket udnyttelse, bekræftet kompromittering og forebyggende nedlukning. PHP Foundation skrev, at teamet ved selve release/offentliggørelsen endnu ikke havde identificeret funktionelle exploits blandt de proof-of-concepts, det overvågede. Efter offentliggørelsen rapporterede sikkerhedsleverandører om aktive exploit-forsøg. watchTowr oplyste eksempelvis, at virksomheden observerede aktive forsøg mod begge sårbarheder, mens Huntress tidligere på dagen skrev: “Huntress has not yet seen in-the-wild exploitation of these vulnerabilities across our partner base” (Huntress, 21. oktober 2026↗). De udsagn modsiger ikke nødvendigvis hinanden: leverandørerne ser forskellige kundepopulationer, og observationerne er foretaget på forskellige tidspunkter. Ingen af dem er i sig selv et dokumenteret tal for vellykkede kompromitteringer globalt.

Den 22. oktober opdaterede Tenable sin gennemgang med, at Amazon Threat Intelligence ifølge deres telemetri havde observeret et exploit-forsøg allerede den 17. oktober, fire dage før den offentlige disclosure, og Tenable beskrev på dette tidspunkt php2shell som bredt udnyttet i det fri. Det er væsentlig ny information, men stadig leverandørtelemetri: et registreret exploit-forsøg er ikke det samme som dokumenteret vellykket kompromittering af et bestemt system, og kilden giver ikke et autoritativt globalt antal kompromitterede sites.

I Danmark reagerede Styrelsen for Samfundssikkerhed den 21. oktober med en direkte opfordring til systemejere om at opdatere hurtigst muligt. Styrelsen skrev samtidig: “Hvis det ikke er muligt at opdatere inden for en kort tidshorisont, kan det være nødvendigt at tage systemer offline” (SAMSIK, 21. oktober 2026↗). Det er ikke en generel anbefaling om at lukke alle PHP-sites. Det er en risikobaseret nødforanstaltning, når en relevant internetvendt installation ikke kan bringes sikkert op på et rettet niveau hurtigt nok.

DMI er et konkret eksempel på en forebyggende driftsreaktion samme dag. DMI oplyste først, at DMI.dk og andre services var lukket, mens en potentiel teknisk sikkerhedsrisiko blev håndteret. Senere blev siden genåbnet, og DMI skrev: “Vi har åbnet DMI.DK igen efter en kortvarig nedlukning.” (DMI, opdateret 21. oktober 2026 kl. 18.20 dansk tid↗). DMI’s egen tekst på den nuværende side navngiver ikke PHP, og nedlukningen bør derfor ikke bruges som bevis for, at DMI var kompromitteret eller for, at PHP-sårbarhederne faktisk blev udnyttet mod DMI.

Dansk Industri koblede den samme eftermiddag sagen direkte til danske webløsninger og opfordrede medlemmer til at afklare, om de bruger PHP, og opdatere med det samme. DI’s rådgivning er relevant som erhvervsperspektiv, men versions- og patchstatus bør kontrolleres i de tekniske primærkilder, fordi operativsystemleverandører kan levere backportede rettelser med versionsnumre, der ser “gamle” ud.

Faktaboks

Kilder: PHP-projektet, PHP-advisories, CERT-EU og NCSC-NL.

Tidslinje

Tidslinjen bygger især på PHP Foundation, PHP-projektet, CERT-EU, Ubuntu, SAMSIK og DMI.

Problemet: Derfor rammer en PHP-fejl virksomheder, der aldrig har “valgt PHP”

En virksomhedsejer kan sagtens være afhængig af PHP uden nogensinde at have truffet et aktivt valg om programmeringssproget. Et website kan være bestilt som “en WordPress-side”, en webshop som “WooCommerce”, et bookingmodul som en færdig løsning eller et kundeområde som specialudvikling. Under brugerfladen kan serveren stadig køre PHP for at fortolke kode, hente data, bygge HTML, kontrollere login, modtage formularer, oprette ordrer eller tale med andre systemer. Derfor er spørgsmålet ikke kun, hvilket CMS virksomheden bruger, men hvilken runtime og hvilken serverpakke der faktisk behandler webtrafikken.

Det gør denne sag bredere end en klassisk plugin-sårbarhed. En opdateret WordPress-installation kan fortsat ligge oven på en sårbar PHP-runtime. Det samme gælder en Laravel-applikation, et ældre kundesystem, en intern portal eller en specialbygget integration. Omvendt betyder det ikke, at ethvert website med PHP allerede er hacket. En CVSS-score på 9,2 beskriver den tekniske alvorlighed under standardiserede forudsætninger, ikke sandsynligheden for, at netop din server allerede er kompromitteret. Praktisk risiko afhænger blandt andet af eksponering, SAPI, konfiguration, worker-adfærd, applikationsveje, patchstatus og angribernes aktivitet.

For virksomheden er den første konsekvens ofte tilgængelighed. Hvis et site lukkes forebyggende, eller hvis en fejludnyttelse får PHP-workers til at crashe, kan kunder ikke gennemføre køb, sende formularer, booke tider eller logge ind. En RCE kan potentielt være mere alvorlig: angriberen kan få de rettigheder, som webserverprocessen har, og derfra forsøge at læse konfiguration, credentials, filer eller data og bevæge sig videre. Det er ikke det samme som automatisk “root-adgang” til hele serveren. Skadens omfang afhænger af, hvilke rettigheder processen har, hvordan netværk og secrets er adskilt, og hvilke yderligere kontroller der findes.

For en webshop er den forretningsmæssige risiko sammensat. En utilgængelig produktside kan stoppe organisk og betalt trafik fra at konvertere. En fungerende forside med en defekt checkout kan være værre at opdage, fordi annoncer og trafik fortsætter, mens køb fejler. Betalingscallbacks, lagerintegrationer, ordremails og tracking kan desuden være separate komponenter, der fejler forskelligt. Det er derfor utilstrækkeligt at teste “forsiden virker”. Man skal teste den fulde kunderejse efter en opdatering. Det gælder især WooCommerce og andre løsninger, hvor PHP er tæt involveret i checkout og backend.

Illustrativt eksempel: webshop med annoncering og utilgængelig checkout. Antag, at en webshop normalt omsætter for 240.000 kr. i døgnet, jævnt fordelt for enkelhedens skyld. Det svarer til 10.000 kr. i gennemsnitlig omsætning pr. time. Hvis checkout er helt utilgængelig i tre timer, er den umiddelbart eksponerede omsætningsmulighed 30.000 kr. Det er ikke automatisk et realiseret tab: nogle kunder vender tilbage senere, og salget er sjældent jævnt fordelt. Antag derudover et dækningsbidrag på 35 procent og 1.500 kr. i annonceforbrug pr. time. Hvis ingen af de tre timers ordrer genvindes, svarer 30.000 kr. i manglende omsætning til 10.500 kr. i manglende dækningsbidrag før øvrige faste omkostninger, mens annonceforbruget i perioden er 4.500 kr. De 4.500 kr. skal ikke lægges ukritisk oven i “tabt omsætning”, fordi annonceudgift og omsætning er forskellige økonomiske størrelser. Eksemplet viser, hvorfor en driftshændelse bør vurderes med faktiske data fra ordre- og annonceplatforme i stedet for et rundt “nedetid koster X”-tal.

Illustrativt eksempel: servicevirksomhed med formular eller booking. Forestil dig en virksomhed med 120 relevante besøgende pr. arbejdsdag og en normal formular- eller bookingrate på 5 procent. Det giver i gennemsnit seks henvendelser pr. dag. Er formularen nede en tredjedel af dagen, er den simple forventningsværdi omkring to henvendelser, der udsættes eller risikerer at gå tabt. Det er stadig ikke to dokumenteret tabte kunder. Nogle ringer, nogle vender tilbage, og trafik fordeler sig ujævnt. Den rigtige efteranalyse er at sammenholde serverlogs, formularlog, CRM, telefonhenvendelser og kampagnedata. Pointen er, at også en “lille” teknisk funktion kan være virksomhedens primære salgskanal.

Nedetid kan også påvirke SEO, men her er det vigtigt ikke at love bestemte placeringstab eller sætte en fast tidsfrist på. Google anbefaler ved kortvarig, nødvendig nedlukning at svare med HTTP-status 503 Service Unavailable, fordi det signalerer, at utilgængeligheden er midlertidig. I Googles aktuelle dokumentation står der: “If you need to urgently disable the site for 1-2 days, then return … a 503 HTTP response” (Google Search Central↗, egen oversættelse: Hvis du akut skal deaktivere sitet i 1 til 2 dage, så returnér et 503-svar). Google oplyser samtidig, at længerevarende 503-svar kan få crawlaktiviteten til at falde og på sigt få URL’er til at forsvinde fra indekset. Det er en god grund til at gøre en nødside teknisk korrekt, men ikke en grund til at holde et sårbart system online. Sikkerhed kommer først.

Betalt annoncering har en anden mekanik. Google Ads kræver, at annoncers destination fungerer og kan crawles. Et utilgængeligt eller teknisk defekt landingssite kan derfor føre til “Destination not working”-problemer eller afviste annoncer. Før en platform når at registrere problemet, kan der desuden være perioder, hvor trafik stadig sendes mod en side, der ikke kan konvertere. Derfor bør marketingansvarlige have en beredskabsrutine for at pause eller omdirigere kampagner, hvis centrale landingssider eller checkout er nede.

Måling bliver samtidig mindre pålidelig. Client-side tracking kræver, at siden og dens tag faktisk indlæses. Google Analytics dokumenterer grundprincippet således: “Google Analytics only collects data from your website pages that include the snippet.” (Google Analytics↗, egen oversættelse: Google Analytics indsamler kun data fra websitesider, som indeholder tagget). Hvis en side slet ikke leveres, kan det normale browserbaserede pageview og konverteringsflow derfor heller ikke registreres på samme måde. Server-side tracking kan i visse arkitekturer bevare dele af signalerne, men det gør ikke en utilgængelig købsrejse til en fungerende købsrejse.

Det organisatoriske problem er ofte lige så vigtigt som det tekniske. Når en kritisk runtime-fejl rammer, skal nogen kunne svare på fem spørgsmål hurtigt: Hvilke systemer bruger teknologien? Hvem har adgang til at rette dem? Hvem beslutter midlertidig isolation? Hvordan verificeres rettelsen? Hvem informerer forretning og kunder? Hvis svaret er “vores webbureau må vide det” eller “hostingen plejer at opdatere”, mangler virksomheden dokumenteret ansvarsplacering. En driftsaftale behøver ikke være kompleks, men den bør beskrive patchansvar, reaktion på kritiske advisories, backup, logging, test, kommunikation og eskalation.

Forklaringen: Sådan kan en fejl i PHP blive til fjernudførelse af kode

PHP er et server-side programmeringssprog og en runtime. Når en bruger besøger en klassisk PHP-baseret hjemmeside, sender browseren en HTTP-request til en webserver eller reverse proxy. Webserveren afgør, om requesten skal håndteres direkte eller sendes videre til PHP. PHP kører derefter applikationskoden, som for eksempel kan være WordPress, WooCommerce eller et specialbygget system. Applikationen kan hente information i en database, kalde et betalingssystem eller et API og returnerer til sidst et HTTP-svar til browseren. Fejlene i denne sag ligger i selve PHP-runtimeens interne håndtering af hukommelse og request-tilstand.

CVE-2026-109618: out-of-memory-fejl kan efterlade intern request-hukommelse i en farlig tilstand. PHP bruger en mekanisme baseret på longjmp() til at afbryde behandling, når processen rammer en out-of-memory-situation. Problemet er, at et sådant spring kan ske på et tidspunkt, hvor interne datastrukturer kun er delvist initialiseret. Senere cleanup-kode kan så behandle ugyldige eller uinitialiserede data, som om de var korrekte. PHP’s advisory beskriver flere måder at fremprovokere OOM på og konkluderer, at tilstanden kan gøres stabil nok til remote code execution.

En forenklet analogi er et lager, hvor en medarbejder midt i registreringen af en kasse bliver tvunget til at forlade arbejdet. Systemet tror bagefter, at registreringen blev afsluttet, og en oprydder bruger derfor et halvt udfyldt kort som gyldig instruktion. En angriber forsøger at forme de “halvt udfyldte” data, så oprydningen gør noget nyttigt for angriberen. Analogien hjælper med at forstå rækkefølgen, men hukommelseskorruption er ikke bogstaveligt en forkert lageretiket. I virkeligheden handler det om pointere, allokeringer, kontrolflow og data i proceshukommelsen.

På Apache med mod_php har forskerne demonstreret en vej, hvor en uautoriseret request kan udløse sårbarheden under request-startup, før applikationskoden kører. Det er afgørende: et WordPress-sikkerhedsplugin kan ikke nødvendigvis stoppe en fejl, der opstår, før WordPress er startet. For PHP-FPM er den præcise startup-vej anderledes, blandt andet fordi en child-process kan afslutte ved startup-fejl. Den første advisory bemærkede, at den identiske mod_php-vej ikke var fuldt demonstreret for FPM, mens PHP Foundation efterfølgende oplyste, at RCE var bekræftet på PHP-FPM via applikationsniveau-veje. Det er et godt eksempel på, hvorfor “alle er berørt” ikke betyder “alle er lige lette at angribe på samme måde”.

CVE-2026-109619: gammel request-tilstand kan overleve den hukommelse, den pegede på. Her er problemet en anden livscyklusfejl. PHP kan gemme request-ejet intern tilstand i globale strukturer. Hvis en fatal fejl eller anden afbrydelse sker på det forkerte tidspunkt, kan en reference til den tilstand blive hængende, selv efter at den underliggende request-hukommelse er frigivet. Når samme worker senere håndterer en ny request, kan tidlig initialiseringskode bruge den “stale” reference. Det er en form for use-after-free. Advisoryen dokumenterer blandt andet tidlige consumers via INI-diagnostik og session upload progress.

Her kan en analogi være et hotel, hvor receptionens system beholder et gammelt nøglekortnummer, efter at gæsten er checket ud og værelset er blevet tildelt en anden. Hvis en senere proces stoler på det gamle nummer, kan den koble den nye situation til forældet tilstand. I software kan konsekvensen være langt værre end en administrativ forveksling, fordi den frigivne hukommelse kan være genbrugt til andre data. Igen er analogien kun en mental model: den tekniske sårbarhed afhænger af worker-genbrug, request-grænser, fejlveje og præcis hukommelsesadfærd.

Advisoryen for CVE-2026-109619 viser netop, hvorfor konfiguration betyder noget. Apache mod_php kan anvende visse .htaccess- eller Apache-baserede PHP-indstillinger tidligt nok til at fungere som en “consumer” af den stale tilstand. PHP-FPM er betinget udsat på andre måder, eksempelvis hvis frontenden sender PHP_VALUE eller PHP_ADMIN_VALUE, der udløser diagnostik før normal initialisering. FPM-pool-værdier og .user.ini har en anden timing og er derfor ikke den samme angrebsvej. Samtidig dokumenteres en session-upload-progress-vej, som kan fungere uafhængigt af INI-diagnostikken.

Det er også derfor, at en simpel versionsstreng ikke fortæller hele historien om eksponeringen. To servere med “PHP 8.3” kan have forskellige web-SAPI’er, distributionspakker, extensions, memory limits, reverse proxies, worker-pools og applikationsflows. Det ændrer angrebsfladen og exploit-stabiliteten. Det ændrer ikke den overordnede anbefaling: PHP-projektet og NCSC-NL anbefaler rettet upstream-version eller en verificeret leverandørbackport på internetvendte PHP-systemer.

Hvad betyder CVE og CVSS? CVE er et offentligt identifikationssystem, der giver en konkret sårbarhed et entydigt nummer, så leverandører og sikkerhedsteams taler om samme fejl. CVSS er en standardiseret alvorlighedsvurdering. Begge fejl har CVSS v4.0-score 9,2, kategoriseret som kritisk i de officielle advisories. Det tal bør bruges til prioritering, men ikke læses som “92 procents risiko for at blive hacket” eller som dokumentation for, at kompromittering allerede er sket.

PHP er ikke WordPress. WordPress, WooCommerce, Drupal og mange specialsystemer er applikationer, som kan køre oven på PHP. Plugins og temaer er yderligere kode i applikationslaget. En sårbarhed i et plugin kan ofte rettes ved at opdatere netop plugin’et. CVE-2026-109618 og CVE-2026-109619 ligger derimod i PHP core. En WordPress-opdatering ændrer derfor ikke automatisk PHP-binæren, PHP-FPM-pakken eller Apache-modulet under sitet. Omvendt gør en PHP-opdatering heller ikke WordPress-plugins sikre mod deres egne sårbarheder. Lagene skal vedligeholdes hver for sig.

Kilder: PHP-projektets advisories og NCSC-NL’s operative oversigt.

AI’s rolle er reel, men historien begyndte ikke med, at en chatbot pludselig “fandt PHP-fejlen”. PHP Foundation fortæller, at en ekstern audit allerede i 2024 fandt tegn på OOM-rodproblemet, og at en potentiel exploit blev overvejet, men uden en konkret RCE-vej. I 2026 blev sikkerhedsarbejdet intensiveret. Calif begyndte en audit 30. juli som del af OpenAI’s Patch the Planet-program og rapporterede 11. august en ubetinget RCE med samme rodårsag. OpenAI rapporterede uafhængigt samme rodårsag samme dag; Wiz leverede senere yderligere angrebsveje.

OpenAI beskriver sin rolle som koordinator og AI-leverandør, men understreger også, at PHP-maintainerne ejede rettelserne. For virksomheder er den vigtigste sætning i OpenAI’s egen status: “For organizations using PHP, the priority now is applying the fixes.” (OpenAI, 21. oktober 2026↗, egen oversættelse: For organisationer, der bruger PHP, er prioriteten nu at installere rettelserne). OpenAI er part i forskningssamarbejdet og har derfor en naturlig interesse i at beskrive værdien af sine modeller; PHP Foundation er den bedste primærkilde til den samlede tidslinje.

PHP Foundation er samtidig usædvanligt åben om den menneskelige proces før 2026. Om den langsomme håndtering af rodproblemet skriver organisationen, at “the delay was a structural failure” og senere, at “AI helps the team validate reports and group reports sharing the same root cause” (PHP Foundation, 21. oktober 2026↗, egne oversættelser). Foundation beskriver altså både et organisatorisk kapa og en situation, hvor AI har gjort rapportering og validering hurtigere, men hvor mennesker stadig træffer beslutninger og gennemgår patches.

Løsningen: Fra “vi har opdateret noget” til dokumenteret rettelse og efterkontrol

Den rigtige respons har tre faser: Gør dette nu, kontrollér efter opdateringen og forebyg fremover. Virksomhedsejeren skal ikke nødvendigvis køre terminalkommandoer eller læse memory dumps, men skal kunne få et entydigt, dokumenteret svar fra den teknisk ansvarlige. Administratoren eller hostingpartneren skal til gengæld kunne bevise, hvilken runtime der betjener trafikken, hvilken pakke eller backport der er installeret, og at alle relevante processer faktisk kører den rettede kode.

Gør dette nu. Start med et aktivregister, ikke med én kendt hjemmeside. Medtag hoveddomæner, subdomæner, webshops, kundelogin, booking, API’er, kampagnesites, ældre løsninger, staging- og testmiljøer, administrationsinterfaces, cron- eller queue-workers, containere og leverandørprodukter, der kan indeholde PHP. NCSC-NL fremhæver specifikt, at PHP også kan være indbygget i appliances, netværksudstyr og managementinterfaces. Et glemt testsite med internetadgang kan være lige så relevant for en angriber som forsiden.

Sæt derefter en ejer på hvert system. Virksomhedens opgave er at få navn, leverandør og eskalationsvej på plads. Administratorens opgave er at identificere webserver, SAPI, operativsystem/distribution, PHP-pakke, containerimage og de faktiske workers. En kommando som php -v kan være nyttig, men den viser typisk CLI-runtime og er ikke i sig selv dokumentation for, hvad nginx, Apache eller en containeriseret applikation bruger. På samme host kan CLI, FPM og mod_php være forskellige versioner. I containerplatforme kan en gammel pod fortsat køre, selv om et nyt image er bygget. Verifikation skal derfor ske på den runtime og de processer, der faktisk modtager webtrafik.

De første rettede upstream-versioner er følgende:

Pr. 22. oktober 2026 er disse fortsat de relevante rettede udgivelser i PHP’s releasearkiv. Ved senere publicering bør redaktionen altid kontrollere PHP’s aktuelle releasehistorik igen og vælge en nyere vedligeholdelses- eller sikkerhedsudgivelse i samme gren, hvis en sådan er kommet.

Ældre PHP-versioner kræver mere omtanke end “versionsnummeret er lavere, så den er sårbar”. PHP 8.1 og ældre er ude af normal upstream-support. På grund af denne sags alvor publicerede PHP-teamet ekstraordinære minimale kildekode-backports til 7.4, 8.0 og 8.1. Det er ikke det samme som at genåbne almindelig support for grenene. Samtidig kan Linux-distributioner og LTS-leverandører backporte rettelser til endnu ældre pakker. Ubuntu har eksempelvis publiceret rettede pakker, hvor det synlige upstream-versionsnummer fortsat er 8.3.6 eller 7.4.3, men distributionssuffixet identificerer en pakke med backporten. Debian har tilsvarende markeret 8.4.27-1~deb13u1 som rettet for Debian 13. Derfor kan man ikke afgøre patchstatus ved blot at sammenligne “8.3.6” med “8.3.36”. Brug leverandørens sikkerhedsbulletin, package changelog og installeret build-id.

For en standardinstallation fra php.net er løsningen at gå til mindst den rettede version i den relevante understøttede gren. For distribution-managed PHP er løsningen normalt at installere distributionens rettede sikkerhedspakke. For et appliance eller en managed platform skal man følge produktleverandørens patchvejledning. At erstatte en leverandørstyret PHP-komponent manuelt kan bryde support, afhængigheder eller signering og bør ikke gøres ukritisk.

Efter opdatering skal administratoren sikre, at rettelsen er aktiveret, ikke bare downloadet. Genstart eller reload de relevante PHP-workers og webserverprocesser, eller genudrul containere og pods, så gammel kode ikke bliver ved med at køre i hukommelsen. Kontroller alle noder bag load balanceren. I miljøer med autoscaling skal gamle images eller launch templates også væk; ellers kan en ny, sårbar instans dukke op senere. NCSC-NL anbefaler eksplicit at kontrollere tredjepartsimages, appliances og indlejrede runtimes særskilt.

Midlertidig risikoreduktion er ikke en patch. PHP beskriver specifikke tiltag for de to CVE’er, hvis opdatering ikke kan ske straks. For CVE-2026-109618 kan en administrativ memory_limit=-1 fjerne den kontrollerbare PHP-memory-limit-fejl som angrebsvej, men underliggende allokeringsfejl kan stadig ramme den sårbare kode. PHP anbefaler desuden lave, forretningsmæssigt realistiske grænser for request- og uploadstørrelser samt grænser i webserver eller proxy. Et container- eller cgroup-memory-limit kan bruges som tilgængelighedsgrænse. PHP advarer specifikt mod at erstatte dette med RLIMIT_AS eller RLIMIT_DATA, fordi de selv kan udløse den sårbare allokeringsfejl.

De råd har driftsmæssige konsekvenser. memory_limit=-1 fjerner PHP’s normale hukommelsesloft og kan øge konsekvensen af memory leaks eller denial-of-service, hvis processen ikke samtidig begrænses på et andet sikkert niveau. Et lavt post_max_size kan bryde store uploads, importfunktioner og formularer. Det skal derfor behandles som en midlertidig, risikobaseret ændring med test og rollback-plan, ikke som en universel opskrift.

For CVE-2026-109619 anbefaler PHP midlertidigt at deaktivere session.upload_progress administrativt og genstarte alle workers; på PHP 8.5 kan fatal_error_backtraces=0 blokere den demonstrerede fatal-backtrace-vej. Begge dele dækker kun bestemte angrebsveje. Advisoryen siger direkte, at en rettet release med fuld state-reset er den eneste pålidelige generelle afværgning. Hvis en applikation bruger upload-progress-funktionen, kan ændringen også påvirke funktionalitet.

En WAF, et CDN eller et WordPress-sikkerhedsplugin kan være nyttige forsvarslag, men er ikke en fuldstændig rettelse. Cloudflare implementerede WAF-beskyttelser før den offentlige disclosure og anbefalede stadig kunder at patche PHP. Det giver mening: en WAF kan blokere kendte requestmønstre, men den ændrer ikke den sårbare memory-management-kode på origin-serveren. Et CDN kan holde cachede statiske sider tilgængelige, men en dynamisk checkout, login eller formular skal stadig ramme origin. Og på mod_php kan den demonstrerede CVE-2026-109618-vej opstå før applikationskoden, hvilket begrænser, hvad et plugin inde i WordPress kan nå at gøre.

Hvis en relevant internetvendt installation ikke kan patches eller få en verificeret backport hurtigt, bør midlertidig isolation eller nedlukning vurderes. SAMSIK siger, at det kan være nødvendigt at tage systemer offline, hvis opdatering ikke er mulig inden for kort tid. CERT-EU anbefaler tilsvarende isolation af internetvendte systemer, indtil rettelsen er installeret og verificeret. Det kan betyde at fjerne offentlig adgang, begrænse til VPN eller allow-listede netværk, eller tage en bestemt funktion ud af drift. Man bør ikke lukke alle virksomhedens websites per automatik; beslutningen skal baseres på faktisk eksponering, forretningskritikalitet og evnen til hurtigt at rette.

Hvis hele sitet må lukkes kortvarigt, er der også et teknisk kommunikationslag. For en kort, planlagt eller sikkerhedsbetinget utilgængelighed anbefaler Google et 503-svar frem for en falsk 200-side, 404 eller noindex. En enkel statisk statusbesked kan oplyse kontaktvej og næste status. Det hjælper både kunder og crawlere med at forstå, at situationen er midlertidig. Men et korrekt 503-svar er en drifts- og SEO-foranstaltning, ikke en cybersikkerhedspatch.

Kontrollér efter opdateringen. Først skal den tekniske ansvarlige bevise patchniveauet på hver node. Dokumentationen kan være et distro-advisory og installeret pakkenummer, et containerimage med digest og buildlog, eller en hostingudbyders skriftlige bekræftelse, der identificerer de konkrete CVE’er og tidspunktet for udrulningen. En marketingmedarbejders screenshot af et kontrolpanel med “PHP 8.3” er ikke nok.

Dernæst skal virksomheden lave en hurtig, risikobaseret funktionstest. Test mindst login, formularer, booking, søgning, filupload hvis det bruges, checkout, betaling, ordreoprettelse, ordremails, webhooks, ERP/lager, CRM, tredjeparts-API’er og de vigtigste cron- eller queue-jobs. Test både succes- og fejlflows. Formålet er ikke et fuldt regressionsprojekt, men at opdage de forretningskritiske fejl, som en runtime-opdatering eller nød-konfigurationsændring kan have udløst.

Derefter kommer sikkerhedskontrollen. Gennemgå webserver- og reverse-proxy-logs, PHP error logs, WAF-telemetri, process events, filændringer og relevante EDR-signaler. Se efter unormale OOM- eller fatal-error-mønstre, worker-crashes, usædvanlige multipart/upload-requests, nye processer startet af webserverbrugeren, nye filer i webroot eller tempområder, ændrede SSH-nøgler eller konti, mistænkelige outbound-forbindelser og adgang til secrets. Advisoryen understreger, at fravær af fejl i logs ikke er bevis for sikkerhed, blandt andet fordi relevante hændelser kan ske før en loglinje skrives, eller fordi historisk logging ikke har dækket alt.

En patch fjerner ikke automatisk følgerne af et tidligere angreb. Hvis der er tegn på kompromittering, er opgaven ikke længere blot patch management, men incident response. Isolér relevante systemer på en måde, der begrænser fortsat adgang uden unødigt at ødelægge spor. Sikr logs, snapshots og anden evidens, fastlæg tidslinjen, undersøg persistence og lateral movement, og rotér credentials ud fra fundene. Gendannelse bør ske fra kendt rene artefakter eller backups, når man har tilstrækkelig forståelse af hændelsen. At installere PHP 8.3.36 oven på en server, hvor en angriber allerede har lagt en webshell eller stjålet en API-nøgle, fjerner ikke webshellen eller gør nøglen hemmelig igen.

Hvis undersøgelsen viser et brud på persondatasikkerheden, kan GDPR-pligter blive relevante. Datatilsynet oplyser, at den dataansvarlige skal anmelde et brud uden unødig forsinkelse og om muligt inden 72 timer efter at være blevet bekendt med det, medmindre det er usandsynligt, at bruddet medfører risiko for personers rettigheder eller frihedsrettigheder. En sårbar PHP-version eller et angrebsforsøg er ikke i sig selv dokumentation for et persondatabrud. Ved en mistanke skal hændelsen undersøges hurtigt, så virksomheden kan vurdere, om betingelserne er opfyldt.

Forebyg fremover. Det vigtigste er at behandle runtime, CMS, plugins, operativsystem, containere og tredjepartsservices som hver sit vedligeholdelseslag. Opret et register med systemejer og teknisk ejer. Abonnér på advisories fra PHP, Linux-distribution, hostingpartner og centrale applikationsleverandører. Definér en patch-SLA efter alvorlighed, eksempelvis at kritiske internetvendte RCE’er skal vurderes straks, men lad ikke en generisk tidsfrist erstatte risikovurdering. Sørg for staging eller anden realistisk test, automatiserede funktionstests, central logging og dokumenteret backup/restore. Og gennemfør mindst én øvelse, hvor I finder ud af, hvem der faktisk kan lukke, patche og genåbne et vigtigt website uden at lede efter adgangskoder under hændelsen.

En god driftsaftale bør desuden forklare forskellen mellem rettelse, risikoreduktion, isolation og gendannelse. Rettelse fjerner den kendte fejl fra koden. Risikoreduktion gør bestemte angrebsveje vanskeligere uden at fjerne fejlen. Isolation begrænser, hvem der kan nå systemet. Gendannelse bringer et kompromitteret miljø tilbage til en troværdig tilstand. De fire handlinger kan være nødvendige på forskellige tidspunkter og må ikke blandes sammen i statusmeldingen “det er fikset”.

Praktisk tjekliste

• Vi har identificeret alle websites, subdomæner, portaler, testmiljøer, containere og leverandørprodukter, der kan bruge PHP.
• Hvert system har en navngiven forretningsansvarlig og teknisk ansvarlig.
• Vi har verificeret den PHP-runtime og pakke, der faktisk betjener webtrafikken, ikke kun CLI-versionen.
• Vi har installeret mindst 8.2.35, 8.3.36, 8.4.27 eller 8.5.12, eller en dokumenteret leverandørbackport.
• Alle workers, containere og noder er genstartet eller genudrullet, og autoscaling bruger rettede images.
• Hosting- eller platformleverandøren har skriftligt bekræftet patchstatus for CVE-2026-109618 og CVE-2026-109619.
• Login, formularer, booking, checkout, betaling, webhooks og centrale integrationer er testet.
• Logs og sikkerhedstelemetri er gennemgået for relevante tegn på angrebsforsøg eller kompromittering.
• Ved mistanke om kompromittering har vi bevaret relevante spor og aktiveret incident response frem for blot at “patche videre”.
• Vi har registreret hvad der blev ændret, hvornår, af hvem, med hvilken pakke/build og hvordan det blev verificeret.

Besked, der kan sendes til hostingudbyderen

Vi vil have bekræftet vores status for CVE-2026-109618 og CVE-2026-109619. Hvilke af vores domæner, subdomæner, containere eller servere kører PHP, og hvilken web-runtime/SAPI betjener trafikken? Hvilken rettet PHP-version eller leverandørbackport er installeret, og hvornår blev den aktiveret? Er alle PHP-workers/noder genstartet eller genudrullet? Har I observeret relevante exploit-forsøg eller tegn på kompromittering på vores miljø, og hvilke logs har I kontrolleret? Angiv gerne advisory/package-id og tidspunkt for næste status, hvis noget endnu ikke er færdigt.

Sådan hjælper Manids

Vi drifter og vedligeholder WordPress- og WooCommerce-sider, og PHP-versioner og sikkerhedspatches er en fast del af vedligeholdet af virksomhedshjemmesider. Ændringer testes på staging, før de rammer live-sitet.

For webshops stopper efterkontrollen ikke ved, at forsiden åbner. Vi tester checkout, betaling og de integrationer, der opretter ordren, fordi det er dér, en fejl koster penge.

Har sitet været nede eller fået ændret opsætning, tjekker vi statuskoder, crawl, redirects og indeksering i Search Console og målingen i GA4 som en del af vores arbejde med teknisk SEO.

Er du i tvivl om, hvem der har ansvaret for PHP på jeres server, eller vil du have en anden til at kontrollere patchstatus og teste bagefter, så kontakt os. Vi tager udgangspunkt i jeres konkrete hosting og driftsaftale.

FAQ

Hvordan finder jeg ud af, om min hjemmeside bruger PHP?
Start med dokumentationen fra hosting- eller webleverandøren. WordPress og WooCommerce er stærke indikatorer på PHP, men du bør stadig få verificeret den runtime, som webserveren faktisk bruger. På managed hosting er det ofte leverandøren, der styrer pakken. På VPS, cloud eller dedikeret server kan jeres administrator kontrollere webserverkonfiguration, FPM-pools, installerede pakker, processer og containerimages. Undgå at gøre en offentligt tilgængelig phpinfo()-side til jeres permanente kontrolmetode, fordi den kan afsløre detaljer om miljøet.

Er min WordPress-hjemmeside berørt?
Hvis den betjenes af en sårbar PHP-runtime, er den relevant for sagen. Det betyder ikke, at WordPress som produkt er årsagen, eller at siden er kompromitteret. PHP-projektet siger, at alle PHP-installationer, der serverer webrequests, skal håndteres, og at risikoen er størst for mod_php. Praktisk exploitability varierer med server- og applikationsopsætning. Få derfor PHP-laget verificeret i stedet for kun at kontrollere WordPress-dashboardet.

Er det nok at opdatere WordPress, tema og plugins?
Nej. De to CVE’er ligger i PHP core. WordPress-, tema- og pluginopdateringer er stadig nødvendige som almindelig sikkerhedsdrift, men de installerer ikke automatisk en ny PHP-binær eller en distributionsbackport på serveren. Det omvendte gælder også: en patched PHP-runtime løser ikke en separat sårbarhed i et plugin.

Hvordan ved jeg, at hostingudbyderen har rettet problemet?
Bed om et konkret svar, der nævner begge CVE-numre og enten den rettede upstream-version eller leverandørens security advisory/package-version. Bed også om bekræftelse på, at rettelsen er aktiv på alle noder og workers. Det er særligt vigtigt ved backports, fordi eksempelvis Ubuntu kan have rettet en pakke, hvis upstream-del stadig hedder 8.3.6. Et kontrolpanel, der blot viser “PHP 8.3”, er derfor utilstrækkeligt.

Beskytter en firewall, CDN eller et sikkerhedsplugin?
De kan reducere risiko og blokere kendte mønstre, men de er ikke den fulde løsning. PHP siger, at kun en rettet release eller en korrekt backport løser sårbarhederne generelt. Cloudflare rullede WAF-beskyttelse ud, men anbefalede stadig patching. I mod_php kan en demonstreret angrebsvej desuden ramme før applikationskoden, så et plugin inde i WordPress kan være for sent i kæden.

Skal min hjemmeside lukkes?
Ikke automatisk. Hvis systemet kan patches og verificeres hurtigt, er det normalt førstevalg. Hvis en relevant internetvendt installation ikke kan opdateres eller få en dokumenteret backport inden for kort tid, siger SAMSIK, at det kan være nødvendigt at tage systemet offline. CERT-EU anbefaler isolation, hvor patching ikke kan ske straks. Beslutningen skal tage højde for eksponering, kritikalitet og muligheden for kontrolleret isolation.

Er en utilgængelig hjemmeside nødvendigvis blevet hacket?
Nej. Nedetid kan skyldes en forebyggende lukning, patcharbejde, genstart, kapa, fejl i konfigurationen eller et angreb. DMI’s 21. oktober-meddelelse dokumenterer netop en kortvarig nedlukning som håndtering af en potentiel teknisk sikkerhedsrisiko, ikke et bekræftet kompromis i den offentliggjorte tekst. Begreberne bør holdes adskilt i intern og ekstern kommunikation.

Hvad gør jeg, hvis løsningen bruger en gammel PHP-version?
Find først ud af, hvem der vedligeholder pakken. PHP 8.1 og ældre er ikke længere almindeligt upstream-understøttet, men PHP-teamet publicerede i denne ekstraordinære situation minimale source-backports til 7.4, 8.0 og 8.1, og distributions-/LTS-leverandører kan have yderligere backports. Brug leverandørens officielle pakke, hvis der findes en understøttet vej, og planlæg samtidig migration til en understøttet PHP-gren. At en nødbackport eksisterer, gør ikke en gammel gren langsigtet sund.

Hvad betyder nedetid for annoncering, SEO og tracking?
Det afhænger af varighed og teknisk respons. Google anbefaler 503 ved kortvarig fuld nedlukning og advarer mod at bruge permanente fejlstatusser eller noindex som nødgreb. Google Ads kan afvise annoncer, hvis destinationen ikke fungerer, og client-side analytics kan ikke registrere normale sidevisninger på sider, der ikke bliver leveret. Der findes ingen seriøs kilde, der kan love “ingen SEO-effekt under X timer” for alle sites. Fokus bør være korrekt statuskode, kortest mulig sikker nedetid, kampagnestyring og efterfølgende kontrol i Search Console, Ads og Analytics.

Hvad bør en driftsaftale indeholde?
Som minimum: system- og komponentansvar, hvem der følger advisories, hvem der må patche og genstarte, krav til backup og restore-test, logging og logopbevaring, staging/test, responstid og eskalation ved kritiske sårbarheder, ansvar for tredjepartsplatforme, kommunikation ved nedetid, dokumentation af ændringer og procedure ved mistanke om kompromittering. Aftalen bør også sige, hvordan leverandøren dokumenterer en backport eller security release. “Vi holder siden opdateret” er for upræcist, når en kritisk fejl ligger under selve CMS’et.

Konklusion

PHP-sagen er alvorlig, men den rigtige reaktion er præcision frem for panik. To kritiske fejl i PHP core har fået officielle rettelser, og der er rapporteret aktive exploit-forsøg. Det betyder, at virksomheder bør verificere deres faktiske web-runtime nu, få den patched eller korrekt backportet, genstarte alle berørte processer og kontrollere både funktion og sikkerhed bagefter. Det betyder ikke, at enhver PHP-side er kompromitteret, eller at alle websites bør lukkes. Det konkrete næste skridt er at få én navngiven teknisk ansvarlig til skriftligt at besvare: Hvilke af vores systemer bruger PHP, hvilken rettelse kører de nu, hvornår blev den aktiveret, og hvad har vi kontrolleret bagefter?

Kilder

• The PHP Group: Security advisory: Critical remote code execution vulnerabilities, update now, 21. oktober 2026. php.net, News Archive 2026↗
• PHP / GitHub Security Advisory: RCE via OOM corruption, CVE-2026-109618, 21. oktober 2026. GHSA-w8hw-w9fx-j79w↗
• PHP / GitHub Security Advisory: RCE via stale global state, CVE-2026-109619, 21. oktober 2026. GHSA-6wmf-4rv5-p3rp↗
• The PHP Foundation: Today's PHP Security Release, and How We're Strengthening PHP Security, 21. oktober 2026. The PHP Foundation↗
• CERT-EU: Security Advisory 2026-018: Critical Vulnerabilities in PHP, 21. oktober 2026. CERT-EU↗
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching, 21. oktober 2026. CISA↗
• NCSC-NL: php2shell: Operational information regarding the 2026 php2shell vulnerabilities, status kontrolleret 22. oktober 2026. NCSC-NL GitHub↗
• OpenAI: Patch the Planet: global response coordination as agents uncover critical vulnerabilities, 21. oktober 2026. OpenAI↗
• Dansk Industri / DI Digital: Kritiske huller i PHP: Opdatér jeres webløsninger nu, 21. oktober 2026. Dansk Industri↗
• DMI: DMI.DK er åben, 21. oktober 2026, opdateret kl. 18.20. DMI↗
• Canonical / Ubuntu: USN-8948-1: PHP vulnerabilities, 21. oktober 2026. Ubuntu Security↗
• Canonical / Ubuntu: USN-8948-2: PHP vulnerabilities, 21. oktober 2026. Ubuntu Security↗
• Debian Security: DSA-6574-1: php8.4 security update, 21. oktober 2026. Debian Security Tracker↗
• PHP Project: Supported Versions, kontrolleret 22. oktober 2026. PHP Supported Versions↗
• Cloudflare, Daniele Molteni, Dan Jones og Kuber Nandwani: Cloudflare deploys protections against php2shell vulnerability, 21. oktober 2026. Cloudflare↗
• Huntress: php2shell, Leaked Critical PHP Vulnerabilities, 21. oktober 2026. Huntress↗
• Tenable: php2shell: Frequently Asked Questions about Critical PHP Remote Code Execution, opdateret 22. oktober 2026. Tenable↗
• Google Search Central: Temporarily Pause Or Disable Website, kontrolleret 22. oktober 2026. Google Search Central↗
• Google Search Central: Troubleshoot Google Search Crawling Errors, opdateret dokumentation kontrolleret 22. oktober 2026. Google Search Central↗
• Google Ads: Fix a disapproved ad or appeal a policy decision, kontrolleret 22. oktober 2026. Google Ads Help↗
• Google Analytics: Troubleshoot tag setup on your website, kontrolleret 22. oktober 2026. Google Analytics Help↗
• Datatilsynet: Anmeld sikkerhedsbrud, kontrolleret 22. oktober 2026. Datatilsynet↗