Kort sagt: En webshell känner ni igen på nya eller ändrade PHP-filer på ovanliga platser, på främmande processer som körs under webbserverns användare och på ovanliga förbindelser. Säkra spåren innan ni raderar något och återställ koden från en ren källa. En patch ensam tar inte bort någon bakdörr.
Varför webshells är ett ämne efter PHP2Shell
Sårbarheterna CVE-2026-109618 och CVE-2026-109619 i själva PHP gör det möjligt att köra skadlig kod på distans utan inloggning. Ett naturligt mål efter ett lyckat angrepp är en bestående bakdörr, alltså en webshell. Den finns kvar även om PHP numera är uppdaterat.
Enligt mediarapporter observerades ett första angreppsförsök redan den 17 oktober 2026, patcharna följde den 21 oktober. Den som var sårbar under den perioden bör titta efter riktat. Bekräftade Indicators of Compromise har hittills inte publicerats. Sökningen bygger därför på avvikande beteende, inte på en färdig lista.
Om ni hittar en webshell på en server med kunduppgifter: radera ingenting förhastat. Säkra först bevis, isolera sedan servern och planera det fortsatta arbetet.
Så upptäcker ni en webshell: granska filer
De flesta webshells är PHP-filer i webbkatalogen. Misstänkta är filer som skapats eller ändrats efter den 17 oktober, PHP-filer i uppladdnings- och cachemappar samt filer med förvrängd kod. Följande kommandon ändrar ingenting, de listar bara:
# PHP-filer som har ändrats sedan 17.10.2026
find /var/www -type f -name "*.php*" -newermt "2026-10-17" -ls
# PHP-filer i uppladdnings-, cache- eller tmp-mappar
find /var/www -type f -name "*.php*" \( -path "*upload*" -o -path "*cache*" -o -path "*tmp*" \) -ls
# Typisk förvrängning: eval i kombination med avkodning
grep -rlE "eval\s*\(\s*(base64_decode|gzinflate|str_rot13|gzuncompress)" /var/www --include="*.php"
# Ovanligt långa rader tyder ofta på packad kod
grep -rlE ".{3000,}" /var/www --include="*.php"
Träffar är indicier, inte bevis. Vissa tillägg använder legitimt kodad kod. Jämför misstänkta filer med tillverkarens originalpaket. Mest tillförlitligt är en jämförelse mot kontrollsummor eller ett versionshanteringssystem som Git:
# Avvikelser från senast kända läge i Git-förvaret
git -C /var/www/projekt status --porcelain
En tidsstämpel kan vara förfalskad. Förlita er därför inte enbart på en fils ändringsdatum.
Vilka kännetecken som gör en fil misstänkt
| Kännetecken | Varför det sticker ut |
|---|---|
| PHP-fil i en uppladdnings- eller bildmapp | Där ska det bara finnas media |
Dubbel ändelse som .jpg.php eller .php.png |
Förklädnad som harmlös fil |
| Mycket långa rader utan radbrytning | Typiskt för packad eller krypterad kod |
| Filnamn som liknar en kärnfil men inte finns i originalpaketet | Kamouflage i en känd miljö |
| Ägare eller rättigheter avviker från grannfilerna | Filen har skapats på annat sätt |
Ju fler kännetecken som sammanfaller, desto större är sannolikheten för ett fynd. Öppna misstänkta filer bara som text, aldrig via webbläsaren, för ett anrop via webbplatsen skulle köra koden.
Granska processer, förbindelser och cronjobb
En aktiv webshell lämnar ofta spår utanför filsystemet. Webbserverns användare, till exempel www-data, apache eller nginx, startar normalt inga skal, nätverksverktyg eller kompilatorer.
# Processer för de typiska webbserveranvändarna
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx)"
# Öppna nätverksförbindelser med tillhörande process
sudo ss -tunap | grep -E "php|www-data|apache|nginx"
# Schemalagda uppgifter för webbserverns användare
sudo crontab -u www-data -l
ls -la /etc/cron.d /var/spool/cron 2>/dev/null
Misstänkta är bestående utgående förbindelser till okända mål, processer med kryptiska namn och cronjobb som hämtar filer från internet. Granska dessutom åtkomstloggarna efter anrop till filer som inte fanns tidigare. Hur det går till beskriver guiden Analysera webbserverloggar efter ett angrepp.
Säkra spåren innan ni tar bort något
Den som raderar först förlorar svaret på de viktigaste frågorna: Hur kom angriparen in, vad har angriparen sett, vilka uppgifter berörs? De svaren behöver ni för en möjlig GDPR-anmälan, för försäkringsgivare och för beslutet om fler system är utsatta.
Förnuftig ordning:
- Dokumentera tillståndet: processlista, nätverksförbindelser, inloggade användare.
- Kopiera misstänkta filer och loggar med kontrollsumma, utan att öppna eller köra dem.
- Om möjligt, skapa en avbild av systemet eller en ögonblicksbild av den virtuella maskinen.
- Ta servern offline eller begränsa åtkomsten kraftigt.
För system med känsliga uppgifter eller en möjlig rättstvist bör säkringen göras forensiskt korrekt. Bakgrund finns under IT-forensik efter ett angrepp mot webbservern.
Ta bort webshells på rätt sätt
Att radera en enskild fil är sällan slutet. Angripare lägger ofta upp flera åtkomstvägar: fler filer på dolda platser, poster i konfigurationsfiler som .htaccess eller .user.ini, nya adminkonton i applikationen eller cronjobb. En tillförlitlig sanering följer de här stegen:
- Uppgradera PHP till en åtgärdad nivå (8.5.12, 8.4.27, 8.3.36, 8.2.35 eller bekräftad backport) och starta om alla PHP-processer.
- Sätt upp applikationskoden på nytt från en ren källa i stället för att reparera enskilda filer.
- Ta bara över granskat innehåll som uppladdningar och databas, och sök där riktat efter insmugglad kod.
- Byt alla inloggningsuppgifter: databas, SSH, FTP, adminkonton, API-nycklar.
- Begränsa webbserverns skrivrättigheter till det nödvändiga och förhindra PHP-körning i uppladdningsmappar.
För WordPress finns egna typiska gömställen, som guiden Hitta bakdörrar i WordPress beskriver. Efteråt bör webbplatsen övervakas närmare en tid för att tidigt upptäcka ett nytt intrång.
Hur hjälper PHP SOS konkret?
- Vi säkrar loggar, filer och systemtillstånd spårbart innan något ändras.
- Vi söker efter bakdörrar i filer, databas, cronjobb och konfiguration och bedömer fynden.
- Vi sätter upp applikationen på nytt från en ren källa, byter åtkomstuppgifter och härdar servern.
- Vi dokumenterar incidenten tills den är avslutad, som underlag för anmälningar och försäkringsgivare.
Förloppet vid en sanering beskrivs i tjänsten Låt ta bort skadlig kod och webshells.
Vanliga frågor
Vad är en webshell?
En webshell är en insmugglad fil, oftast i PHP, som angripare kan styra servern på distans med. Den döljer sig ofta som en harmlös fil med ett oansenligt namn och förblir aktiv även efter en uppdatering.
Hittar ett virusprogram varje webshell?
Nej. Skannrar känner igen kända mönster, nya eller starkt förvrängda varianter slinker igenom. För PHP2Shell finns dessutom inga publicerade, bekräftade Indicators of Compromise, därför är beteendeanalys viktigare än en signaturlista.
Räcker det att radera den filen som hittats?
Oftast inte. Angripare lägger ofta upp flera åtkomstvägar, till exempel fler filer, cronjobb eller nya adminkonton. Utan orsaksanalys och byte av alla inloggningsuppgifter är ett nytt intrång sannolikt.
Måste jag anmäla något efter ett webshell-fynd?
Om personuppgifter kan ha påverkats kan det finnas en anmälningsskyldighet enligt GDPR, i regel inom 72 timmar. Klarlägg det med ert dataskyddsombud eller en advokat; detta är inte juridisk rådgivning.