PHP2Shell: Anledningen till att webbplatser slogs ut och vad man ska göra nu

En brist i en av internets vanligaste byggstenar tvingade organisationer att stänga ner sina webbplatser. Här beskrivs vad som hände, varför det är viktigt och vad organisationerna bör göra härnäst.

Onsdagen den 21 oktober stängdes myndigheters webbplatser, kommunala webbplatser, bibliotek och nätbutiker över hela Europa och även utanför kontinenten ner med några timmars mellanrum – inte för att de hade blivit hackade, utan som en försiktighetsåtgärd för att skydda sig själva.

Orsaken var en allvarlig säkerhetsbrist i PHP, det programmeringsspråk som ligger till grund för de flesta av världens webbplatser. Besökarna ser det aldrig, men det är just detta som gör att en webbplats fungerar genom att hantera inloggningar, varukorgar, formulär och anslutningen till databasen bakom dem. Säkerhetsbristen, som kallas PHP2Shell, kunde göra det möjligt för en angripare att ta kontroll över en webbserver utan lösenord. Eftersom detaljerna läckte ut innan någon patch blivit klar rekommenderade säkerhetsmyndigheter i flera länder organisationer att stänga av sårbara tjänster tills de kunde uppdatera dem.

Säkerhetsbrister upptäcks hela tiden, men de flesta berör bara en enskild produkt eller ett enskilt företag. Den här bristen finns i en programvara som miljontals webbplatser använder gemensamt, vilket innebär att alla dessa webbplatser plötsligt blev sårbara.

Patchen släpptes senare på onsdagen, och även om många tjänster redan är tillbaka online kommer det att ta dagar eller till och med veckor att återställa andra.

Varför detta är viktigt även bortom den här veckan

Säkerhetsforskare från Calif, Wiz och OpenAI upptäckte säkerhetsbristen i augusti med hjälp av AI-verktyg inom ramen för ett OpenAI-initiativ för att hitta svagheter i vanligt förekommande programvara. Problemet hade funnits i PHP i flera år, men ansågs vara för komplicerat att utnyttja tills AI gjorde arbetet betydligt enklare. Planen var att publicera detaljerna tillsammans med en en färdig patch, för att ge organisationer tid att uppdatera, men informationen läckte ut innan patchen var klar.

Samma AI-verktyg hjälper nu både forskare och angripare att upptäcka sårbarheter snabbare än någonsin, och vi förväntar oss att antalet upptäckter kommer att fortsätta öka. Därför bör organisationer vara beredda att reagera snabbt när nästa sårbarhet upptäcks.

Organisationerna ställde sig samma frågor: Påverkas vi?

Om din organisation använder något som är byggt på PHP, bör du utgå från att så är fallet tills du har kontrollerat det. Svårigheten ligger i att ta reda på var PHP används, eftersom det sällan begränsar sig till den publika webbplatsen utan kan förekomma i interna applikationer, en webbutik, ett intranät eller programvara som köpts från en leverantör och som du inte kan uppdatera själv.

De flesta organisationer vet hur man åtgärdar en sårbar komponent när de väl vet var den finns, så det verkliga problemet är bristen på insyn, eftersom många företag helt enkelt inte vet om de är sårbara.

Har vi utsatts för ett dataintrång?

Det här är den fråga vi har hört oftast den här veckan, och att installera uppdateringen ger inget svar på den. Angripare försökte redan utnyttja sårbarheten innan patchen släpptes, vilket innebär att ett system som uppdaterades på onsdagen ändå kan ha utsatts för angrepp redan tidigare. Om du inte har kontinuerlig säkerhetsövervakning på plats, be din IT-avdelning eller webbhotell att granska dina system för att se om det förekommit någon ovanlig aktivitet under de senaste veckorna.

Vårt säkerhetsoperationscenter (SOC) har övervakat kundernas miljöer i mer än ett decennium, vilket ger oss en tydlig bild av var sårbara PHP-komponenter finns i de system vi övervakar och om något ovanligt har inträffat i dem. Under den tiden har vi vid flera tillfällen sett hur utbredd programvara utnyttjats i stor skala, och vår detekteringsfunktion är utformad för att upptäcka attacker mot sårbarheter i webbapplikationer som denna.

Vad ska vi göra nu?

De exakta stegen beror på din konfiguration, men arbetsordningen är densamma för alla:

• Ta reda på var PHP används inom er organisation, inklusive interna system och leverantörsprogramvara.
• Uppdatera till en patchad version. Äldre versioner (PHP 8.1 och tidigare) uppdateras inte längre av PHP-projektet självt, men många operativsystems- och webbhotellsleverantörer har släppt patchar. Om ingen sådan finns tillgänglig för din installation krävs en mer omfattande uppgradering.
• Starta om alla tjänster som använder PHP, så att den gamla, sårbara koden inte längre körs.
• Fråga dina leverantörer om den programvara de tillhandahåller har uppdaterats.
• Kontrollera om era system visar tecken på tidigare intrång, och börja med de som är synliga på internet.

För IT-team gäller sårbarheterna CVE-2026-109618 och CVE-2026-109619, som har åtgärdats i PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. Om du använder PHP från din operativsystemleverantör bör du kontrollera leverantörens säkerhetsmeddelande, eftersom uppdaterade paket ofta behåller sitt gamla versionsnummer.

Varför är vissa webbplatser fortfarande nere?

Ju längre en webbplats är nere, desto mer omfattande brukar arbetet bakom den vara. Långa driftstopp tyder oftast på föråldrade programvaruversioner och en stor uppdateringsskuld, vilket innebär att den tekniska skulden blir synlig.