Kort sagt: PHP-säkerhetsluckan PHP2Shell består av två kritiska fel i PHP, grunden för de flesta webbplatser och webbutiker. Via dem kan angripare köra skadlig kod på webbservrar utan lösenord. BSI (den tyska federala myndigheten för informationssäkerhet) varnar med nivå orange och rekommenderar: uppdatera omedelbart, annars ta berörda servrar tillfälligt offline. För ledningen betyder det i dag: klargör ansvaret, kräv uppdatering och bevis, besluta om en avstängning och dokumentera allt.
Läget i tre meningar
Den 21 oktober 2026 publicerade PHP-projektet uppdateringar för två kritiska sårbarheter, kända under namnet PHP2Shell. Berört är PHP självt, inte en viss produkt, alltså potentiellt varje webbplats, varje butik och varje portal som körs med PHP. BSI har utlyst varningsnivå 3 / orange, säkerhetsföretag rapporterar om angreppsförsök, och bekräftade lyckade angrepp i bred skala var enligt BSI inledningsvis inte kända.
Myndigheter som BKA (den tyska federala kriminalpolisen) och flera städer har enligt mediarapporter stängt av sina webbplatser som försiktighetsåtgärd. Det var försiktighet, inget tecken på ett angrepp.
Vad PHP-säkerhetsluckan betyder för ledning och företag
Frågan är inte om ni använder PHP. Nästan varje företag gör det någonstans: webbplats, butik, rekryteringsportal, kundområde, intranät, ärendesystem, byråns mikrosajt. Frågan är om de systemen är uppdaterade och vem som ansvarar för dem.
Lyckas ett angrepp kan angriparen i värsta fall ta över servern. Möjliga följder är dataläckage, manipulerat innehåll, vidarebefordran till bedrägerisidor, att butiken går ner eller att servern missbrukas för ytterligare angrepp. Om personuppgifter kan vara berörda tillkommer anmälningsskyldighet; fristen enligt art. 33 GDPR är i regel 72 timmar. Detaljer står under GDPR-anmälningsskyldighet. Detta är ingen juridisk rådgivning.
Vilka kostnader som typiskt uppstår i skarpt läge placerar inlägget Kostnadsposter vid en hackning in.
Var PHP ofta förbises i företag
Huvudwebbplatsen har de flesta koll på. Det som förbises är snarare systemen i utkanten: rekryteringsportalen hos en extern leverantör, landningssidan från en tidigare kampanj, ett partnerområde för återförsäljare, supportens ärendesystem, ett fillager på egen server eller webbgränssnittet på en nätverkslagring. Även byråers testsystem är ofta publikt nåbara och körs på samma server som den riktiga webbplatsen.
För ledningen är lärdomen enkel: frågan till IT lyder inte ”Är vår webbplats patchad?” utan ”Är alla våra system med PHP patchade, även leverantörernas?”. Skillnaden mellan de två frågorna är ofta just den punkt där ett angrepp lyckas.
Vad läget inte är
Lika viktig är bedömningen nedåt. PHP2Shell är ingen anledning till aktionism som stör driften mer än nödvändigt. Den som styrkt har patchat, startat om alla PHP-processer och inte hittar några avvikelser vid kontrollen kan återgå till normal drift. En tillfällig avstängning är ett alternativ för oklara fall, inget krav för alla.
Fem frågor till er IT eller leverantör
De här frågorna kan ni ställa i dag. Svaren bör komma skriftligt.
- Vilka av våra system körs med PHP? En lista med adress, ändamål och driftansvarig.
- Är varje system patchat? Åtgärdad version 8.5.12, 8.4.27, 8.3.36 eller 8.2.35, eller en backport som leverantören bekräftat.
- Har alla PHP-processer startats om? Utan omstart verkar inte uppdateringen.
- Hur är det med system på PHP 8.1 eller äldre? För dem finns inga officiella uppdateringar. Hur lyder planen?
- Har man kontrollerat om något hände före uppdateringen? Loggar från och med den 20 oktober säkrade, spår eftersökta?
Ligger er webbplats hos ett webbhotell hjälper en formell förfrågan. En mall erbjuder guiden Begära PHP-uppdateringsbekräftelse från webbhotellet.
De beslut som bör fattas i dag
| Beslut | Alternativ | Underlag |
|---|---|---|
| Vem leder? | en ansvarig person internt, en extern partner | ansvaret måste vara entydigt |
| Opatchade system | patcha direkt, tillfälliga åtgärder, tillfälligt stänga av | BSI:s rekommendation, datalägen, omsättningsrelevans |
| Kontroll av spår | internt, externt, bara vid avvikelser | skyddsbehovet för data på servern |
| Kommunikation | informera internt, förbereda kunder, avvakta | läget efter kontrollen |
| Äldre system | planera migrering, isolera, stänga av | PHP 8.1 och äldre utan officiella uppdateringar |
Notera vem som beslutade vad när och på vilket informationsunderlag. En kort, daterad anteckning räcker. Den är i efterhand ofta värd mer än varje efterhandsförklaring gentemot försäkringsbolag, kunder eller tillsynsorgan.
Varför den dokumentationen är viktig för ledningen förklarar sidan Ledningens ansvar vid IT-säkerhetsluckor. Detta är allmän information och ingen juridisk rådgivning.
Vad ni inte bör tro
Tre påståenden hör ledningar just nu ofta, och alla tre är fel:
- ”Vi har uppdaterat WordPress, alltså är vi säkra.” Sårbarheten sitter i PHP, inte i CMS:et. En CMS-uppdatering stänger den inte.
- ”Vi är för små, ingen angriper oss.” Angrepp sker automatiserat. Man söker efter sårbara servrar, inte efter kända namn.
- ”Uppdateringen är på plats, därmed är saken avklarad.” En patch tar inte bort skadlig kod som smugits in tidigare och bevisar inte att inget har hänt.
Hur hjälper PHP SOS konkret?
- Lägesbild för ledningen: Vi tar fram en kort översikt över era PHP-system med status och rekommendation per system.
- Genomförande: Vi patchar, startar om eller sätter tillfälliga åtgärder där en uppdatering ännu inte är möjlig.
- Kontroll: Vi säkrar loggar och söker efter spår av ett angrepp.
- Bevis: Ni får en dokumentation som ni kan använda internt och gentemot tredje part.
Förloppet beskrivs i PHP2Shell-akuthjälpen.
Slutsats
PHP2Shell är en teknisk sårbarhet med en ledningsuppgift. Tekniken sköter fackfolk. Ledningen ser till att någon är ansvarig, att de fem frågorna besvaras och att beslut fattas medvetet och dokumenteras. Det ryms på en förmiddag om det börjar i dag.
Vanliga frågor
Måste företagsledningen själv ta hand om PHP2Shell?
Inte det tekniska genomförandet, men styrningen. Ledningen bör säkerställa att ansvarsområden är tydliga, att BSI:s rekommendation genomförs och att beslut som en tillfällig avstängning fattas medvetet och dokumenteras.
Hur förklarar jag sårbarheten i en mening?
I PHP, programvaran som de flesta webbplatser och butiker körs på, finns två kritiska fel som gör att utomstående kan starta program på servern utan lösenord; en uppdatering finns och måste installeras.
Vad kostar det att inte göra något?
Det går inte att uppskatta schablonmässigt. Möjliga följder av ett lyckat angrepp är driftstopp, dataläckage, anmälningsskyldighet, kostnader för sanering och forensik samt förlorat förtroende hos kunder. En uppdatering med kontroll är i regel betydligt mindre arbete.
Räcker det att webbhotellet tar hand om det?
Vid delat webbhotell installerar webbhotellet i regel uppdateringen. Be om en skriftlig bekräftelse, inklusive omstart av PHP-processerna. Om något hände före uppdateringen besvarar bekräftelsen inte; för det krävs en kontroll av webbplatsen.