Den 21 oktober 2026 täppte PHP-projektet till två kritiska säkerhetsluckor som lät angripare ta över andras webbservrar utan lösenord. I praktiken berördes varje PHP-installation som går att nå från internet, även många webbplatser, webbutiker och kundportaler hos små och medelstora företag. Luckorna hittades med hjälp av kraftfulla AI-modeller. Den som driver webbapplikationer i dag bör därför kunna svara på två frågor: Är uppdateringen installerad? Och hur snabbt reagerar ert företag på nästa varning?

Luckorna har beteckningarna CVE-2026-109618 och CVE-2026-109619. I fackmedier kallas de tillsammans ”PHP2Shell”. Båda är klassade som kritiska, med 9,2 av 10 på den vanliga CVSS-skalan. Tyska BSI, den federala myndigheten för informationssäkerhet, och CERT-EU, EU-institutionernas säkerhetsteam, varnade samma dag.

Berörs era system?

Ange er domän eller serverns IP-adress. Vi hämtar startsidan en gång och läser av den PHP-version som servern uppger.

Vill ni ha visshet eller hjälp med uppdateringen? Vi går igenom era system noggrant och hjälper snabbt.

Begär en kontroll

PHP-versionerna 8.5.12, 8.4.27, 8.3.36 och 8.2.35 eller nyare är säkra. För PHP 8.1 och äldre publicerar PHP-projektet inga rättelser längre. Där hjälper bara uppdateringar från er Linux-distribution eller en övergång till en aktuell version.

För kunder hos AI Værk: ingen anledning till oro

Att skydda våra kunder har högsta prioritet för oss. Alla system vi tar hand om har vi under ständiga säkerhetskontroller. Vid PHP2Shell var de redan skyddade innan uppdateringen kom: där det behövdes stängde vi tillfälligt av berörda funktioner. En minut efter att uppdateringen publicerats var våra kunders system uppdaterade och online igen. Så arbetar vi vid varje nödläge: vi stänger ute faran direkt och åtgärdar sedan problemet på riktigt.

Varför luckorna räknas som kritiska

PHP är grunden för en stor del av internet. WordPress, Drupal, de flesta e-handelssystem och många administrationsverktyg som phpMyAdmin körs på det. En lucka i själva PHP drabbar därför inte en enskild applikation, utan allt som bygger på den.

Tre saker avgör den höga klassningen. En angripare behöver inget användarkonto och inget lösenord. Ingen i företaget behöver klicka på en länk eller öppna en bilaga. En PHP-sida som går att nå från internet räcker som ingång. Lyckas angreppet kan angriparen köra egna kommandon på servern, läsa data, placera skadlig kod eller använda servern för fler angrepp.

Enligt dem som hittade luckorna berörs varje PHP-version från de senaste tio åren av minst en av dem, tillbaka till PHP 5.4. Detaljerna läckte dessutom redan den 20 oktober, en dag före den officiella uppdateringen. BSI råder därför att installera uppdateringarna omedelbart.

De två felen förklarade

Minnesfel när minnesgränsen nås (CVE-2026-109618). Varje anrop till en PHP-server får bara använda en fast mängd arbetsminne. När gränsen nås avbryter PHP anropet. Det var just vid avbrottet som minnet skadades. En angripare kan framkalla det här läget med flit, till exempel med mycket stora eller djupt nästlade formulär- och uppladdningsanrop. Via det skadade minnet går det sedan att föra in egen programkod.

Gamla data mellan två anrop (CVE-2026-109619). En webbserver besvarar många anrop efter varandra, ofta i samma process. Däremellan måste PHP nollställa sina interna mellanlägen helt. Det skedde inte alltid. Ett nytt anrop kunde därför komma åt rester från ett tidigare, och även det gick att bygga ut till att köra främmande kod. Det är bekräftat bland annat för den inbyggda förloppsindikatorn vid filuppladdning. En annan orsak är felmeddelanden som PHP skriver ut innan ett anrop är helt förberett.

Båda felen sitter i delar av programmet som bara körs i undantagslägen. Just därför har de förblivit oupptäckta så länge: i normal drift märks de inte, och vid manuella granskningar får sådana kantfall sällan den uppmärksamhet de behöver.

Kraftfull AI hittar luckor som förbisetts i åratal

Kritiska fel i PHP har funnits förut. Det nya är hur de här hittades. Säkerhetsföretaget Wiz uppger att de upptäckte luckorna med hjälp av AI-modellerna Gemini 4 Argon och GPT-5.6 Sol. Modellerna hittade inte bara felet. De byggde också ett fungerande angrepp, anpassade det till olika PHP-versioner och kontrollerade senare rättelsen.

Även OpenAI rapporterar om luckorna. Säkerhetsteamet Calif hittade en av dem med GPT-5.6 Sol inom OpenAI:s initiativ ”Patch the Planet”, som hjälper förvaltare av öppen källkod att åtgärda sådana fynd. OpenAI samordnade arbetet under två månader med PHP:s utvecklare, Wiz, Cloudflare och myndigheter, och kallar PHP2Shell ett av de mest omfattande säkerhetsproblemen på länge. Enligt OpenAI hittade AI luckorna innan angripare gjorde det. Det gav tid att förbereda rättelser och skydd.

Tidslinjen visar hur snabbt det gick. Den 19 augusti hittade forskarna den första luckan, den 20 augusti fungerade angreppet mot Drupal och den 21 augusti mot WordPress. Wiz skriver att en enda forskare på en vecka klarade det som tidigare skulle ha tagit ett team i världsklass flera månader.

PHP-luckorna är inget enskilt fall. Under året hittas allt fler allvarliga fel i gammal, spridd programvara med hjälp av AI. OpenAI skriver att man redan har hittat fler allvarliga luckor och räknar med att sådana fynd ökar kraftigt de kommande månaderna. För företag får det två följder:

  • Säkerhetsvarningarna blir fler. Fel som legat i koden i åratal blir nu synliga i tät följd.
  • Tiden mellan offentliggörande och angrepp blir kortare. När detaljer sprids redan före rättelsen, som vid PHP2Shell, är en uppdatering som installeras först vid nästa veckas underhåll för sent.

Varför försvaret behöver samma verktyg

När angripare med kraftfull AI klarar på dagar det som tidigare tog månader räcker inte årliga granskningar och manuella rutiner längre. Samma modeller som hittar luckor kan också hjälpa till att täppa till dem snabbare. Vid PHP2Shell fungerade just det: luckorna hittades, rapporterades och rättades innan de utnyttjades i stor skala.

För ett litet eller medelstort företag kan det översättas till fyra steg.

  1. Kartlägg vad som går att nå från internet. Vilka servrar, applikationer och programversioner är öppna utåt? En AI-stödd inventering håller översikten aktuell, i stället för att den ligger i ett kalkylark en gång om året.
  2. Bedöm varningar på minuter i stället för dagar. När BSI eller CERT-EU varnar måste det snabbt stå klart om och var ni berörs. Ett AI-system kan jämföra varningen med er miljö och föreslå omedelbara åtgärder, som att stänga av förloppsindikatorn för uppladdningar vid PHP2Shell.
  3. Låt granska er egen kod. Kundportaler, tillägg till webbutiker och äldre interna verktyg innehåller ofta fel som ingen har letat efter. Kraftfulla AI-modeller kan undersöka dessa applikationer riktat, innan en angripare gör det.
  4. Installera uppdateringar snabbt och kontrollerat. Automatiska tester visar om en uppdatering förstör något. Då krymper tiden till installation från veckor till timmar.

Ansvaret ligger kvar hos människor. AI:n läser, jämför, testar och föreslår. Om en server ska tas offline eller en uppdatering installeras utanför kontorstid avgör någon som känner driften.

Det här bör ni kontrollera nu

Fråga er IT-avdelning eller leverantör om alla PHP-installationer körs på någon av de rättade versionerna. Tänk också på mindre synliga ställen: testsystem, äldre mikrosajter, Docker-containrar och enheter med inbyggt PHP, som vissa brandväggar. BSI påpekar uttryckligen att de behöver egna uppdateringar.

Om ett system inte går att uppdatera direkt rekommenderar CERT-EU att det tillfälligt kopplas bort från internet. Kontrollera också om det finns tecken på ett angrepp, till exempel okända filer i webbkatalogen, ovanliga processer eller misstänkta anrop i loggarna.

AI Værk som partner för er cybersäkerhet

Vi arbetar varje dag med kraftfulla AI-modeller och känner därför båda sidor: hur snabbt modellerna hittar svagheter och hur samma hastighet kan användas för försvar. Vid PHP2Shell var våra kunders system skyddade före uppdateringen och uppdaterade en minut efter att den publicerats. Det arbetssättet tar vi med oss till ert företag också.

Om ni är osäkra på om ni berörs: Vi kontrollerar med kort varsel var ni använder PHP, om uppdateringarna är installerade och om det finns spår av ett angrepp. Ni får en tydlig bedömning på begriplig svenska och vet sedan var ni står.

Om något redan har hänt: Vi hjälper till snabbt och utan lång startsträcka. Vi begränsar skadan, rensar drabbade system, hittar orsaken och återställer driften på ett säkert sätt. Ju tidigare vi kommer in, desto mindre går förlorat.

Om ni vill förebygga: Vi tar tillsammans med er fram lösningar som automatiskt jämför säkerhetsvarningar med er miljö, pekar ut berörda system och föreslår motåtgärder. Era egna applikationer granskar vi med samma modeller som i dag hittar luckor. Så får ni veta om en svaghet innan en angripare utnyttjar den.

Det är enkelt att prata med oss: en kort beskrivning av era system räcker. Inloggningsuppgifter eller konfidentiella dokument behöver vi inte för det. Prata om er säkerhetssituation.

Källor och vidare läsning

Vanliga frågor om PHP2Shell

Berörs vår WordPress-webbplats?

Troligen ja, om den kördes på en PHP-version från före uppdateringen den 21 oktober 2026. Luckorna finns i själva PHP, inte i WordPress. En uppdatering av WordPress räcker därför inte. Det avgörande är PHP-versionen på servern.

Räcker det att vårt webbhotell installerar uppdateringen?

Vid vanligt webbhotell sköter leverantören oftast PHP-versionen. Fråga ändå om och när uppdateringen installerades. För egna servrar, virtuella servrar eller containrar ansvarar ni eller er leverantör själva.

Hur ser vi om vår server har angripits?

Typiska tecken är okända PHP-filer i webbkatalogen, nyskapade användarkonton, ovanliga processer eller misstänkta, mycket stora anrop i åtkomstloggarna. Att allt ser normalt ut är dock inget bevis. Vid osäkerhet bör en sakkunnig granska systemet.

Vad gör vi om vi kör PHP 8.1 eller äldre?

För dessa versioner finns ingen rättelse från PHP-projektet. Kontrollera om er Linux-distribution erbjuder en uppdaterad version. Annars behövs en övergång till en aktuell PHP-version. Till dess bör systemet inte gå att nå från internet.

Kan AI granska vår egen programvara också?

Ja. Kraftfulla AI-modeller kan undersöka källkod, konfigurationer och beroenden riktat efter svagheter. Resultaten behöver bedömas av experter, eftersom inte varje fynd är en verklig lucka och inte varje lucka är lika brådskande.