PHP:s kritiska CVE-2026-109618: Vad vi gjorde samma dag och vad du bör kontrollera

Den 21 oktober 2026 släppte PHP-projektet en akut säkerhetsuppdatering. Den åtgärdade två kritiska sårbarheter, CVE-2026-109618 och CVE-2026-109619, som kan låta en angripare köra egen kod på en webbserver utan att ens logga in. Båda har fått allvarlighetsgraden 9.2 (kritisk). Alla PHP-versioner från 5.4 upp till 8.5.11 påverkades.

PHP driver en enorm andel av webben, däribland WordPress, Laravel-applikationer, de flesta delade webbhotell och många av företagswebbplatserna i Bangladesh. När ett sådant hål öppnas börjar angripare skanna inom några timmar. Därför väntade vi inte på att kunderna skulle höra av sig. Här är vad vi gjorde, i tur och ordning, och vad det innebär om du driver en webbplats.

Vad var det för sårbarhet i PHP?

Båda bristerna finns i själva PHP-motorn, inte i WordPress eller i något tillägg. Enligt Google Clouds analys beror den ena på hur PHP hanterar att minnet tar slut mitt i en förfrågan, och den andra på förfrågningsdata som finns kvar efter att minnet har frigjorts. En angripare kan utlösa dem med specialbyggda HTTP-förfrågningar, till exempel överstora uppladdningar, och på så sätt köra kod på servern.

PHP:s egna versionsanteckningar var rakt på sak: ”Det finns inga fullständiga skyddsåtgärder, att uppdatera är det enda säkra valet.”

• Åtgärdade versioner: PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35
• Ingen åtgärd alls: PHP 8.1 och äldre har inte längre stöd (end-of-life), så de webbplatserna måste flyttas till 8.2 eller senare

Vad gjorde vi när säkerhetsmeddelandet kom?

Vi behandlade det som en incident, inte som en punkt i ett nyhetsbrev.

1. Vi informerade alla samma dag. Det innebar varje pågående kund och varje tidigare kund vars webbplats vi har byggt eller fortfarande driftar, plus de företag vi fortfarande förde samtal med. Vi väntade inte med att först reda ut om de var ”vårt” ansvar. Även en potentiell kund som inte har skrivit på något bör få veta att deras webbplats är exponerad.
2. Vi gick igenom varje PHP-version vi ansvarar för. Vi listade varje server och webbplats, dess PHP-version och om den förvaltades av oss, av ett webbhotell eller av kunden själv.
3. Vi patchade och startade om. Vi uppgraderade PHP till den åtgärdade versionen och startade sedan om PHP-FPM och webbservern. Det steget är viktigt, eftersom en paketuppgradering på disken, som Google påpekar, lämnar den gamla sårbara koden kvar i minnet tills arbetsprocesserna startas om.
4. Vi flyttade gamla webbplatser från PHP-versioner utan stöd. Webbplatser som fortfarande körde PHP 8.1 eller äldre får ingen åtgärd, så vi uppgraderade dem till en version med stöd och testade webbplatsen efteråt så att inget gick sönder.
5. Vi uppdaterade samtidigt WordPress-kärnan, teman och tillägg. För tydlighetens skull: att uppdatera WordPress åtgärdar inte en brist i PHP. Men en webbplats med en exponerad PHP-version har ofta gamla tillägg också, och vi tänkte inte stänga en dörr och lämna nästa öppen.
6. Vi härdade det vi kunde. På servrar som fick vänta på ett webbhotell tillämpade vi de tillfälliga inställningarna från säkerhetsmeddelandena, till exempel att stänga av session upload progress och strama åt gränserna för uppladdningar och indata, tills den åtgärdade versionen var på plats.
7. Vi bekräftade och återrapporterade. Varje kund fick en kort redogörelse med sin PHP-version före och efter, vad vi hade uppdaterat och vad som eventuellt återstod för webbhotellet att göra.

Varför kontakta tidigare kunder och potentiella kunder också?

För att en webbplats inte slutar vara sårbar när fakturan är betald. Många av de webbplatser vi byggde för flera år sedan körs fortfarande exakt som när vi lämnade över dem, och ägarna har ingen anledning att följa PHP:s versionsanteckningar. Om vi känner till ett kritiskt hål i något vi har byggt är det inte ett alternativ att tiga.

Detsamma gäller potentiella kunder. Ett företag som pratade med oss förra månaden om en ny webbplats kör fortfarande sin gamla i dag. Att berätta det kostar oss ett telefonsamtal. Att låta bli kan kosta dem deras kunddata.

Tidigare den här månaden skrev vi om säkerhetshålen vi gång på gång hittar på företagswebbplatser. Föråldrad serverprogramvara låg högt upp på den listan, och det här är just det problemet, i skarpt läge.

Påverkas min webbplats av CVE-2026-109618?

Om din webbplats körs på PHP, vilket gäller alla WordPress-webbplatser, utgå från att svaret är ja tills du har kontrollerat. Så gör du:

• WordPress: gå till Verktyg → Webbplatsens hälsa → Info → Server (Tools → Site Health → Info → Server på engelska) och titta på PHP-versionen
• cPanel eller annat webbhotell: leta efter ”Select PHP Version” eller ”MultiPHP Manager”
• Egen server: kör php -v, och glöm inte att starta om PHP-FPM eller Apache efter uppgraderingen

Om versionen är lägre än 8.2.35, 8.3.36, 8.4.27 eller 8.5.12 inom sin gren behöver du agera. Om den börjar på 7 eller 8.0/8.1 kommer det inte att komma någon patch, och då behöver du uppgradera.

Hur ser proaktivt underhåll ut i praktiken?

För det mesta ser det ut som ingenting alls. Webbplatsen fortsätter att ladda, beställningarna fortsätter att komma in och du hör aldrig ordet ”CVE”. Arbetet sker innan du hinner märka problemet.

Det är vad vi menar med att ta hand om våra kunder. Vi är ett mjukvaruföretag med bas i Saidpur och arbetar med företag i hela Rangpur-divisionen, i övriga Bangladesh och utomlands. Är du osäker på om din webbplats har patchats? Fråga oss. Vi kontrollerar den kostnadsfritt och berättar ärligt vad vi hittar.