Kritiska säkerhetshål i PHP (CVE-2026-109618 och CVE-2026-109619): vad som hänt och vad du ska göra

Den 21 oktober 2026 släppte PHP-projektet rättelser för två kritiska säkerhetshål, och CERT-EU publicerade samma dag varningen 2026-018. Båda är bedömda till 9,2, och båda beskrivs som kodkörning på distans utan autentisering. Om du driver en WordPress-webbplats, en webbutik eller någon annan PHP-applikation berör det dig, och åtgärden är en uppdatering, inte en inställning. Den här artikeln förklarar vad som är känt, hur attacken tar sig in och vad du bör göra. Läge: 22 oktober 2026, enligt version 1.1 av CERT-EU:s varning.

Vad som hänt

PHP aviserade en säkerhetsversion den 20 oktober och publicerade rättelserna den 21 oktober kl. 13:30 UTC. CERT-EU kallar sin varning ”Critical Vulnerabilities in PHP” och anger två CVE:er: CVE-2026-109618 och CVE-2026-109619, var och en med bedömningen 9,2. CERT-EU skriver dessutom att de tekniska detaljerna nu diskuteras offentligt och att de första exemplen på kod som bevisar sårbarheten (proof of concept) har börjat spridas. Varningen bekräftar inga attacker i det fria, men säger att det gör det mer sannolikt att angripare redan utnyttjar hålen. Behandla det som brådskande.

Vilka som berörs

Berörd är varje PHP-version under den rättade i en gren som stöds, samt varje gren som nått slutet på sin livstid.

CERT-EU nämner PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP och LiteSpeed. Enligt PHP-teamet är risken störst med mod_php. Även produkter som bäddar in PHP kan beröras; CERT-EU hänvisar till en lista från den nederländska NCSC i slutet av den här artikeln. Varje installation som hanterar webbförfrågningar räknas, oavsett om den har ett uppladdningsformulär eller inte.

Hur en angripare når det första hålet

Ingen behöver logga in. Enligt CERT-EU visar en demonstrerad attack att en enda begäran utan inloggning räcker för att utlösa attacken innan någon applikationskod körs. Det är det de flesta missar: det spelar ingen roll om din WordPress är uppdaterad, om dina tillägg är lagade eller om ditt kontaktformulär är skyddat. Begäran når PHP-motorn först.

Det första hålet, CVE-2026-109618, fungerar så här:

1. En begäran kommer till en adress som PHP betjänar. Ingen inloggning, inget konto.
2. PHP börjar läsa begärans innehåll. CERT-EU nämner hanteringen av formulärbaserade filuppladdningar som exempel.
3. PHP upprätthåller sin memory_limit med longjmp(). Överskrids gränsen hoppar PHP ur det den höll på med och avslutar begäran.
4. Om det sker mitt i uppbyggnaden av interna begärandata är dessa data bara halvt uppbyggda.
5. Städningen efteråt behandlar de ogiltiga uppgifterna som giltiga och frigör minne som aldrig initierats. Det minnet kan fortfarande innehålla data från tidigare tilldelningar som angriparen kontrollerat.
6. Därifrån beskriver varningen kodkörning på servern.

Hur en angripare styr det sista steget beskriver vi medvetet inte. Det räcker att veta att ingången inte är din applikation, och därför kan inget inuti din applikation stoppa den.

Det andra hålet: tillstånd som överlever sitt minne

CVE-2026-109619 är en annan mekanism med samma resultat. PHP håller ett internt tillstånd för varje begäran. Efter vissa fel, till exempel ett allvarligt fel (fatal error), kan tillståndet finnas kvar trots att minnet under det frigjorts. Nästa begäran som samma worker hanterar kan då använda det föråldrade tillståndet innan det återställs på normalt sätt. Angriparen behöver två begäranden som hamnar på samma worker; CERT-EU bedömer resultatet som vid det första hålet: kodkörning på distans.

Vad du bör göra i dag

1. Ta reda på vilken PHP-version som faktiskt betjänar din webbplats. php -v på kommandoraden visar kommandoradens version, som kan skilja sig från din webbservers. Kontrollera php-fpm -v, din hostingpanel eller en sida som anropar phpinfo(). Vid delat webbhotell frågar du din leverantör.
2. Uppdatera till en rättad version: 8.5.12, 8.4.27, 8.3.36 eller 8.2.35. Distributioner för ofta över rättelser till äldre versioner utan att ändra versionsnumret; leta därför efter CVE-numren i din leverantörs säkerhetsmeddelande. I containrar bygger du om från en uppdaterad basavbild. PHP-teamet påpekar att rpms.remirepo.net inte hade några uppdateringar på utgivningsdagen och rekommenderar paket från distributionen eller ett bygge från källkoden.
3. Starta om varje PHP-worker. En uppdatering på disken ändrar inte processer som redan körs. Starta om PHP-FPM eller webbservern och kontrollera sedan den körande versionen igen.
4. Om du inte kan uppdatera i dag, koppla bort servern från offentliga nät tills rättelsen är installerad och kontrollerad. CERT-EU är tydligt: bara en uppdatering åtgärdar hålen helt.
5. Om du kör PHP 8.1 eller äldre, be din leverantör om bakporten eller byt till en gren som stöds. Dessa versioner får inga vanliga uppdateringar.

Skyddsåtgärder som sänker risken men inte åtgärdar hålet

CERT-EU anger åtgärder som gör en attack svårare. Varningen säger uttryckligen att de inte gör en installation säker. Använd dem medan du förbereder uppdateringen, inte i stället för den.

• Mot CVE-2026-109618: Sätt memory_limit=-1 på ett sätt som applikationer inte kan åsidosätta, till exempel med php_admin_value i FPM-poolen, och kontrollera att ingen pool-, katalog- eller applikationspost sätter en ändlig gräns igen. Sätt ett lågt post_max_size (8M utan uppladdningar, 32M med) och håll upload_max_filesize under det. Begränsa begärans storlek, antal fält, multipart-delar, antal rubriker och nästlingsdjup i webbservern eller proxyn. Använd en minnesgräns på containern eller cgroup som tillgänglighetsgräns, men inte RLIMIT_AS eller RLIMIT_DATA, som kan utlösa det sårbara allokeringsfelet.
• Mot CVE-2026-109619: Sätt session.upload_progress.enabled=0 i php.ini, i FPM-poolen eller i en serverkonfiguration som gäller innan begäran bearbetas (inte med ini_set() eller .user.ini), och starta om alla workers. Sätt dessutom fatal_error_backtraces=0 på PHP 8.5. Ta bort ogiltiga eller föråldrade inställningar per begäran som skriver ut meddelanden före initieringen, och åtgärda allvarliga fel och tidsgränsöverskridanden som en angripare kan nå.

Vad SilentShield kan och inte kan göra här

Det här är inget botproblem, och det säger vi hellre än att låta en produktsida antyda något annat. Attacken träffar PHP-motorn innan något från oss, en CAPTCHA, ett tillägg eller en brandväggsregel i din applikation ser begäran. Ett botskydd på ett formulär stoppar den inte, och ingen bör säga till dig att det gör det. Den enda fullständiga åtgärden är PHP-uppdateringen.

SilentShields API och instrumentpanel är inte skrivna i PHP. WordPress-tillägget och PHP-SDK:n körs i din egen PHP, så där måste uppdateringen ske på din server. Efter uppdateringen är det vanliga skyddet mot bottar och formulärspam lika användbart som förut; det var bara aldrig svaret på det här problemet.

Källor

• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• PHP-meddelande från 20 oktober 2026
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell: produkter som bäddar in PHP