Kritiske PHP-sårbarheder (CVE-2026-109618 og CVE-2026-109619): hvad der skete, og hvad du skal gøre

Den 21. oktober 2026 udgav PHP-projektet rettelser til to kritiske sårbarheder, og CERT-EU offentliggjorde samme dag sikkerhedsadvarslen 2026-018. Begge er vurderet til 9,2, og begge beskrives som kodekørsel på afstand uden autentificering. Hvis du driver et WordPress-site, en webshop eller en anden PHP-applikation, vedrører det dig, og løsningen er en opdatering, ikke en indstilling. Denne artikel forklarer, hvad der er kendt, hvordan angrebet kommer ind, og hvad du bør gøre. Status: 22. oktober 2026, baseret på version 1.1 af CERT-EU's advarsel.

Hvad der skete

PHP varslede en sikkerhedsversion den 20. oktober og udgav rettelserne den 21. oktober kl. 13:30 UTC. CERT-EU kalder sin advarsel „Critical Vulnerabilities in PHP“ og opregner to CVE'er: CVE-2026-109618 og CVE-2026-109619, hver med vurderingen 9,2. CERT-EU skriver desuden, at de tekniske detaljer nu drøftes offentligt, og at de første eksempler på kode, der beviser sårbarheden (proof of concept), er begyndt at cirkulere. Advarslen bekræfter ikke angreb i det fri, men siger, at det gør det mere sandsynligt, at angribere allerede udnytter sårbarhederne. Behandl det som haster.

Hvem er ramt

Ramt er enhver PHP-version under den rettede i en understøttet gren samt enhver gren, der har nået slutningen af sin levetid.

CERT-EU nævner PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP og LiteSpeed. Ifølge PHP-teamet er mod_php den største risiko. Produkter, der indlejrer PHP, kan også være ramt; CERT-EU henviser til en liste fra det hollandske NCSC i slutningen af denne artikel. Enhver installation, der betjener webforespørgsler, tæller, uanset om den har en upload-formular eller ej.

Hvordan en angriber når den første sårbarhed

Ingen behøver at logge ind. Ifølge CERT-EU viser et demonstreret angreb, at en enkelt forespørgsel uden login er nok til at udløse angrebet, før nogen applikationskode kører. Det overser de fleste: Det er ligegyldigt, om dit WordPress er opdateret, om dine plugins er rettet, eller om din kontaktformular er beskyttet. Forespørgslen rammer først PHP-motoren.

Den første sårbarhed, CVE-2026-109618, virker sådan:

1. En forespørgsel når en adresse, som PHP betjener. Intet login, ingen konto.
2. PHP begynder at læse forespørgslens indhold. CERT-EU nævner behandlingen af formularbaserede filuploads som eksempel.
3. PHP håndhæver sin memory_limit med longjmp(). Hvis grænsen overskrides, springer PHP ud af det, den var i gang med, og afslutter forespørgslen.
4. Sker det midt under opbygningen af interne forespørgselsdata, er disse data kun halvt opbygget.
5. Oprydningen bagefter behandler de ugyldige data som gyldige og frigiver hukommelse, der aldrig blev initialiseret. Den hukommelse kan stadig indeholde data fra tidligere allokeringer, som angriberen havde kontrol over.
6. Herfra beskriver advarslen kodekørsel på serveren.

Hvordan en angriber styrer det sidste trin, beskriver vi bevidst ikke. Det er nok at vide, at indgangen ikke er din applikation, og derfor kan intet inde i din applikation stoppe den.

Den anden sårbarhed: tilstand, der overlever sin hukommelse

CVE-2026-109619 er en anden mekanisme med samme resultat. PHP holder en intern tilstand for hver forespørgsel. Efter visse fejl, for eksempel en alvorlig fejl (fatal error), kan denne tilstand blive stående, selvom hukommelsen under den er frigivet. Den næste forespørgsel, som den samme worker behandler, kan så bruge den forældede tilstand, før den nulstilles på normal vis. Angriberen skal bruge to forespørgsler, der lander på den samme worker; CERT-EU vurderer resultatet som ved den første sårbarhed: kodekørsel på afstand.

Hvad du bør gøre i dag

1. Find ud af, hvilken PHP-version der faktisk betjener dit site. php -v på kommandolinjen viser kommandolinjens version, som kan afvige fra din webservers. Tjek php-fpm -v, dit hostingpanel eller en side, der kalder phpinfo(). Ved shared hosting spørger du din udbyder.
2. Opdater til en rettet version: 8.5.12, 8.4.27, 8.3.36 eller 8.2.35. Distributioner overfører ofte rettelser til ældre versioner uden at ændre versionsnummeret; led derfor efter CVE-numrene i din leverandørs sikkerhedsmeddelelse. I containere bygger du forfra ud fra et opdateret basisbillede. PHP-teamet gør opmærksom på, at rpms.remirepo.net ikke havde nogen opdateringer på udgivelsesdagen, og anbefaler pakker fra distributionen eller en bygning fra kildekoden.
3. Genstart hver PHP-worker. En opdatering på disken ændrer ikke processer, der allerede kører. Genstart PHP-FPM eller webserveren, og kontrollér derefter den kørende version igen.
4. Hvis du ikke kan opdatere i dag, så afbryd serveren fra offentlige netværk, indtil rettelsen er installeret og kontrolleret. CERT-EU er tydelig: Kun en opdatering løser disse sårbarheder fuldt ud.
5. Hvis du bruger PHP 8.1 eller ældre, så spørg din leverandør om tilbageporteringen, eller skift til en understøttet gren. Disse versioner får ingen almindelige opdateringer.

Afhjælpninger, der mindsker risikoen, men ikke løser problemet

CERT-EU opregner foranstaltninger, der gør et angreb sværere. Advarslen siger udtrykkeligt, at de ikke gør en installation sikker. Brug dem, mens du forbereder opdateringen, ikke i stedet for den.

• Mod CVE-2026-109618: Sæt memory_limit=-1 på en måde, så applikationer ikke kan overskrive det, for eksempel med php_admin_value i FPM-poolen, og kontrollér, at ingen pool-, mappe- eller applikationspost igen sætter en endelig grænse. Sæt en lav post_max_size (8M uden uploads, 32M med), og hold upload_max_filesize under den. Begræns forespørgslens størrelse, antal felter, multipart-dele, antal headere og indlejringsdybde på webserveren eller proxyen. Brug en hukommelsesgrænse på containeren eller cgroup'en som tilgængelighedsgrænse, men ikke RLIMIT_AS eller RLIMIT_DATA, som kan udløse den sårbare allokeringsfejl.
• Mod CVE-2026-109619: Sæt session.upload_progress.enabled=0 i php.ini, i FPM-poolen eller i en serverkonfiguration, der virker før forespørgslen behandles (ikke med ini_set() eller .user.ini), og genstart alle workers. Sæt på PHP 8.5 desuden fatal_error_backtraces=0. Fjern ugyldige eller forældede indstillinger pr. forespørgsel, der udskriver meddelelser før initialiseringen, og ret alvorlige fejl og tidsoverskridelser, som en angriber kan nå.

Hvad SilentShield kan og ikke kan her

Det er ikke et bot-problem, og det siger vi hellere, end at en produktside lader noget andet antyde. Angrebet rammer PHP-motoren, før noget fra os, en CAPTCHA, et plugin eller en firewallregel inde i din applikation ser forespørgslen. En bot-beskyttelse på en formular stopper det ikke, og ingen bør fortælle dig, at den gør. Den eneste fuldstændige løsning er PHP-opdateringen.

SilentShield-API'en og dashboardet er ikke skrevet i PHP. WordPress-pluginet og PHP-SDK'et kører i din egen PHP, så her skal opdateringen ske på din server. Efter opdateringen er den sædvanlige beskyttelse mod bots og formularspam lige så nyttig som før; den var bare aldrig svaret på dette problem.

Kilder

• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• PHP-meddelelse af 20. oktober 2026
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell: produkter, der indlejrer PHP