PHP2Shell, Next.js och veckan då patchen inte räckte
PHP2Shell är två kritiska sårbarheter i själva PHP som låter en angripare köra egen kod på en webbserver utan att logga in. De läckte innan lagningen fanns och utnyttjas redan. Samma vecka kom kritiska hål i Next.js och ett allvarligt hål i Node.js. Det räcker inte att uppdatera, för nästa hål kommer också före lagningen.
I kväll kom ett mejl från Hetzner, där vi hyr servrar. Två kritiska sårbarheter i PHP, uppdatera så fort som möjligt, håll ögonen öppna efter tecken på intrång. Samma typ av mejl har landat hos väldigt många företag den här veckan. Det intressanta är inte mejlet. Det intressanta är vad man gör i timmen efter.
Vi gick igenom allt vi har byggt, server för server och sajt för sajt. Den här texten är vad vi lärde oss, vad du själv bör kontrollera och hur vi bygger för att ett hål i en enskild komponent inte ska bli ett intrång.
Vad som faktiskt hände
PHP2Shell är namnet på två sårbarheter i PHP, CVE-2026-109618 och CVE-2026-109619, båda bedömda som kritiska med CVSS 9.2. Den första sitter i hur PHP hanterar ett fel när minnet tar slut. Den andra i att PHP behåller tillstånd från en förfrågan efter att minnet bakom det redan lämnats tillbaka, det som kallas use-after-free. Båda leder till samma sak: någon utanför kan få servern att köra kod som angriparen själv har skrivit, utan inloggning.
Det som gör veckan ovanlig är ordningen. Tekniska detaljer läckte ut innan PHP hunnit släppa lagade versioner, och säkerhetsforskare visade upp fungerande attacker mot WordPress, Drupal och Joomla. Enligt watchTowr har attacker setts i det fria sedan den 21 oktober. PHP har släppt 8.5.12, 8.4.27, 8.3.36 och 8.2.35, och CISA uppmanar alla att uppdatera omedelbart. Eftersom felet sitter i PHP självt gäller det allt som körs ovanpå: WordPress, Drupal, Joomla och de flesta webbhotell med kontrollpanel.
Samma vecka kom två andra saker som rör betydligt fler moderna sajter än man tror:
- Next.js släppte den 14 oktober lagningar för två kritiska hål som båda kan ge kodkörning utan inloggning. Ett sitter i bildoptimeringen när den hanterar SVG-filer via biblioteket sharp, och gäller servrar med glibc-baserad Linux. Det andra gäller App Router med Cache Components, i funktioner med
use cachesom returnerar flera typade arrayer. Lagat i 16.4.1 och 15.5.28. Version 14 finns inte bland de lagade versionerna. - Node.js släppte den 21 oktober lagningar för tio sårbarheter. Den allvarligaste är en skrivning utanför minnesgränsen i Brotli-avkodaren, som i värsta fall kan ge kodkörning. Lagat i 22.23.4, 24.22.1 och 26.12.1.
Varför en uppdatering bara är halva svaret
Det naturliga svaret på en sådan vecka är att uppdatera och gå vidare. Det ska man göra. Men tänk på tidslinjen i PHP2Shell. Hålet fanns innan någon kände till det, detaljerna fanns ute innan lagningen fanns, och attackerna började innan de flesta hunnit läsa sin inkorg. Det finns alltså alltid ett fönster då en server är sårbar och det inte finns något att installera.
Det fönstret går inte att patcha bort. Det går bara att bygga runt. Frågan att ställa är därför inte bara "har vi uppdaterat?" utan "vad hade en angripare kommit åt om de hunnit före oss?". Svaret på den frågan avgörs av arkitekturen, inte av hur snabbt någon trycker på uppdatera.
Så tar du reda på om du är drabbad
Börja med en inventering. Det låter tråkigt, men det är där de flesta faller: man vet inte vilka servrar, sajter och tjänster som faktiskt körs, eller vem som byggde dem.
- PHP: kör
php -vpå varje server du själv ansvarar för. Har du ett webbhotell eller en WordPress-sajt hos en byrå, fråga dem rakt ut vilken PHP-version som körs och när den uppdaterades. Ligger du på en version äldre än 8.2 är svaret att byta version, inte att vänta. Kör du distributionens paket, kontrollera leverantörens säkerhetsmeddelande i stället för versionsnumret, eftersom lagningen ofta byggs in utan att numret ändras. - Next.js: kör
npm ls next sharpi projektet. Allt under 16.4.1 eller 15.5.28 ska uppdateras. Står det 14 behöver projektet ett versionslyft, och fram till dess är sharp 0.35.5 eller senare det tillfälliga skyddet mot bildhålet. - Node.js: kör
node -vpå servrarna. Glöm inte maskiner som "bara" kör ett internt skript, de tar ofta emot data utifrån ändå. - Tecken på intrång: leta efter nya filer i webbkatalogen, okända processer, utgående trafik till adresser ni inte känner igen och nya användare eller nycklar. En uppdatering stänger dörren, den kastar inte ut den som redan kommit in.
Så bygger vi för att ett hål inte ska räcka
Vi bygger AI-assistenter som läser i företags system och förbereder arbete åt dem. Det betyder att vi är precis den sortens leverantör en angripare vill åt: en väg in till företags data. Därför utgår vi från att det alltid finns ett hål vi inte känner till ännu, och bygger så att det hålet inte räcker.
Ingen dörr ut mot internet
Servrarna där en kunds assistent körs svarar inte på något från det öppna internet. Brandväggen släpper inte in någon tjänst från det öppna internet, bara trafik i ett privat, krypterat nät där varje enhet är identifierad. En angripare som har ett färskt PHP- eller Node-hål måste först hitta en tjänst att skicka det till, och det finns ingen. Det är skillnaden mellan att hoppas att man hinner patcha och att inte vara nåbar under tiden.
Minsta möjliga yta
Det som inte är installerat kan inte vara sårbart. Vi kör ingen PHP alls, och varje server har bara de komponenter dess uppgift kräver. När vi gick igenom allt i kväll tog det därför minuter i stället för dagar: listan över vad som kunde vara drabbat var kort från början.
En egen server per kund
Varje kund får en egen server i EU. Om något ändå skulle gå sönder på en server stannar det där. En angripare kan inte gå vidare från en kunds miljö till nästa, eftersom miljöerna inte delar något.
Vi läser, vi ändrar inte
Utgångsläget är att vi läser i era system, inte skriver. Det spelar större roll än det låter. Ett intrång i en tjänst som bara kan läsa är allvarligt, men ett intrång i en tjänst som fritt kan skicka betalningar, ändra i bokföringen eller mejla era kunder är en katastrof. Behörighet att ändra något ges bara där en uppgift kräver det, och även då gäller nästa punkt.
Ett ja före varje handling, och en logg som inte går att skriva om
Inget skickas, bokförs eller ändras innan rätt person hos er har sagt ja. Allt som sker skrivs in i en signerad logg där varje post är kedjad till den föregående. Om någon skulle ta sig in och försöka dölja vad de gjort bryts kedjan, och det syns. Den som har kontroll över servern kan alltså inte i efterhand skriva om historien.
Uppdateringar som vana, inte som brandkår
Säkerhetsuppdateringar för operativsystemet installeras automatiskt på våra servrar. Ramverk som Next.js och Node.js uppdaterar vi efter en kontroll: vi bygger om, jämför varje sida mot den som ligger live och släpper först när allt är identiskt. Det gjorde vi i kväll med kapaciti.se, som nu kör Next.js 16.4.1.
Det du kan göra i morgon
Du behöver inte bygga om allt för att bli betydligt säkrare. Tre saker räcker långt:
- Gör en lista över varje sajt, server och tjänst ni har, vem som ansvarar för den och vilken version den kör. Det är grunden för allt annat.
- Stäng det som inte måste vara öppet. Administrationsgränssnitt, databaser och interna verktyg ska inte gå att nå från internet. Ett privat nät eller en VPN kostar lite och tar bort större delen av risken.
- Fråga era leverantörer samma fråga som vi ställde oss själva: vad hade en angripare kommit åt om de hunnit före er? Ett bra svar handlar om arkitektur. Ett dåligt svar handlar bara om hur snabbt de brukar uppdatera.
Nästa kritiska hål kommer, och det kan mycket väl läcka före lagningen igen. Den som byggt för det märker knappt av det.