Kort sagt: Om ni misstänker att er server har hackats via PHP2Shell, hör av er nu. Berörs ni? Ring oss. Vi hjälper er. Från första meddelandet tar vi hand om begränsningen, säkrar spåren, stänger sårbarheten, tar bort skadlig kod och dokumenterar incidenten tills den är avslutad.
Radera ingenting och installera inte om något nu. Raderade filer och överskrivna loggar är de spår som visar om och hur någon tagit sig in. Ta vid behov servern offline, men låt den vara oförändrad. Anmäl nödläge, så talar vi om för er nästa steg.
Berörs ni? Tecken på att PHP2Shell redan har utnyttjats
PHP2Shell är namnet på två kritiska sårbarheter i själva PHP, som låter angripare köra skadlig kod på distans utan inloggning. Något entydigt fingeravtryck finns hittills inte. Därför är det serverns beteende som räknas, inte vad en skanner hittar. Tecken på ett intrång är:
- Webbserver- eller PHP-FPM-processer som startar ett skal som
shellerbash. Det är en stark varningssignal. - Nya eller ändrade PHP-filer i uppladdnings-, cache- eller temp-mappar som ingen har skapat.
- Cronjobb, tjänster eller SSH-nycklar som ni inte känner till.
- Utgående förbindelser till okända mål, plötsligt hög belastning eller ovanlig datatrafik.
- Förfrågningar i loggarna från och med den 17 oktober 2026, särskilt avvikande uppladdningar och sessionsförfrågningar innan patchen installerades.
- Meddelanden från webbhotellet, webbläsaren eller sökmotorn om skräppost, skadlig kod eller omdirigeringar.
Mer om detta finns under Är jag redan komprometterad?. Om inget av tecknen finns är det inget bevis för en ren server. Det betyder bara att inget har märkts hittills.
Det här gör ni direkt
- Ändra ingenting. Radera inga filer, återställ ingen säkerhetskopia och installera inte om något innan allt har säkrats.
- Säkra loggarna. Be ert webbhotell eller er IT att inte skriva över åtkomst-, fel- och systemloggar. Fackpressen rekommenderar att loggar sparas från och med den 20 oktober 2026.
- Besluta om tillgängligheten. Om data kan läcka ut eller besökare kan utsättas för fara, ta webbplatsen offline eller sätt den i underhållsläge.
- Samla åtkomsterna. Notera vem som har åtkomst till server, panel, CMS och databas. Byt lösenord först efter överenskommelse och från en ren enhet.
- Informera berörda. Ledningen, dataskyddsombudet och, om ni har en försäkring, försäkringsbolaget.
- Ring eller skriv till oss. Ju tidigare vi känner till läget, desto mer går att belägga.
Hur hjälper PHP SOS konkret?
Vi arbetar på distans, utan resor, i hela Europa.
- Kartlägga läget: Vi klarlägger vilka system som körs, vilket PHP-driftläge som används, vad som har uppmärksammats och vilka uppgifter som kan vara berörda.
- Säkra och stänga: Vi säkrar filer, databas och loggar och dokumenterar läget före varje ändring. Därefter stänger vi sårbarheten med patchen eller, om den ännu inte är möjlig, med tillfälliga åtgärder, och startar om alla PHP-processer.
- Granska och rensa: Vi söker efter webshells, bakdörrar, cronjobb och främmande åtkomster och tar bort dem eller bygger upp läget på nytt från tillförlitliga källor. Tillvägagångssättet beskrivs i Ta bort skadlig kod och webshells.
- Härda och rapportera: Vi byter ut de berörda hemligheterna, kompletterar skyddsåtgärderna och levererar en rapport som skiljer mellan belagt, sannolikt och okänt.
Växer incidenten utöver en enskild server går vi över till strukturerad incidenthantering. Behövs bevis som håller i domstol kopplar vi in IT-forensik.
Varför en patch ensam inte räcker efter ett angrepp
Sårbarheterna finns i PHP-tolken, inte i CMS:et. PHP-projektet publicerade den 21 oktober 2026 versionerna 8.5.12, 8.4.27, 8.3.36 och 8.2.35. Den som har uppdaterat därefter och startat om alla workers är skyddad mot nya angrepp den vägen. Det en angripare har lagt ut tidigare ligger dock kvar: en webshell, ett extra konto, ett schemalagt jobb. Just därför är dagarna mellan den 17 och den 21 oktober särskilt viktiga.
Dessutom finns en andra punkt: En webshell är ofta bara det första steget. Den som kunde köra kod på webbservern kunde också läsa konfigurationsfiler och därifrån ta över åtkomst till databas, e-post och API. De hemligheterna måste bytas ut, annars förblir dörren öppen trots att PHP är patchad. Hur ni granskar filer och tidpunkter på ett vettigt sätt beskrivs i guiden om att upptäcka webshells.
Anmälningsskyldighet och dokumentation
Om personuppgifter kan ha påverkats kan en anmälan till tillsynsmyndigheten inom 72 timmar bli nödvändig. Tiden löper från det att ni fick kännedom, inte från att utredningen är klar. Om ert fall är anmälningspliktigt avgör dataskyddsombudet eller en jurist; vi ger ingen juridisk rådgivning. Vår dokumentation ger underlaget till det. Mer om fristen finns under Anmälningsskyldighet inom 72 timmar enligt GDPR, och stegen därefter i checklistan efter en hackning.
Det här bör ni skicka till oss
- Beskrivning av vad som har uppmärksammats sedan när, och vem som märkte det
- Typ av server: egen server, managed server eller webbhotellspaket, samt webbhotell
- Resultatet av
php -voch, om det är känt, driftläget (PHP-FPM, mod_php, LiteSpeed) - Tidpunkt för PHP-uppdateringen, om den redan har installerats
- Åtkomst till servern eller tillstånd att tala med ert webbhotell
- Kontaktperson med beslutsbefogenhet för avstängning och omstarter
Varför PHP SOS
Vi arbetar Made in Germany och är sedan över 25 år, tillsammans med vårt partnernätverk av cyberproffs, specialiserade på IT-säkerhet. Ni har en kontaktperson som följer er från första meddelandet till avslutet. Allt vi gör dokumenteras, så att ni kan belägga det gentemot ledning, försäkringsbolag och myndigheter. Vi lovar inget som ingen kan hålla: Om loggar saknas säger vi det öppet, och vi anger vad som är belagt och vad som förblir en gissning.
Berörs ni? Ring oss. Vi hjälper er.
Vänta inte tills misstanken blir visshet. Ring eller skriv via WhatsApp. Vi tar över från första meddelandet och finns kvar tills incidenten är avslutad och dokumenterad. Anmäl nödläge nu.
Vanliga frågor
Räcker det att uppdatera PHP om min server kanske redan har hackats?
Nej. Uppdateringen stänger sårbarheten men tar inte bort skadlig programvara som redan förts in, och den bevisar inte att inget hände tidigare. Efter patchen måste servern granskas efter spår av intrång.
Hur ser jag att ett PHP2Shell-angrepp har lyckats?
Det finns inga publicerade, bekräftade Indicators of Compromise. Upptäckten bygger på beteende: webbserverprocesser som startar ett skal, nya PHP-filer i uppladdnings- eller cachemappar, okända cronjobb eller SSH-nycklar och ovanliga utgående förbindelser.
Ska jag ta servern offline om jag misstänker ett intrång?
Det är ofta rätt, eftersom BSI (den tyska federala myndigheten för informationssäkerhet) rekommenderar att webbservern tillfälligt tas offline även när uppdateringen inte kan göras direkt. Viktigt är att inte radera något och att bevara loggar och filer, så att incidenten kan utredas.
Måste jag informera dataskyddsmyndigheten efter ett PHP2Shell-angrepp?
Om personuppgifter kan ha påverkats kan en anmälan inom 72 timmar vara nödvändig. Beslutet fattar ni tillsammans med ert dataskyddsombud eller en jurist; vi levererar de tekniska fakta till det.
Har servrar verkligen redan hackats via PHP2Shell?
Enligt medierapporter observerades de första angreppsförsöken från och med den 17 oktober 2026, och Cloudflare rapporterade om observerade angreppsförsök. BSI rapporterade till en början inga bekräftade lyckade angrepp i bredd. I enskilda fall går det bara att klarlägga på själva servern.