Kort sagt: En PHP-fil i uppladdningsmappen är en allvarlig varningssignal, för där ska bara bilder och dokument ligga. Öppna aldrig filen i webbläsaren, utan läs den som text, kontrollera tidsstämplar och ägare och sök efter filnamnet i åtkomstloggarna. Ofarliga är oftast bara tomma platshållare som en index.php utan innehåll; behandla allt annat som ett möjligt intrång.
Varför PHP inte hör hemma i uppladdningsmappen
Uppladdningsmappar är till för innehåll som besökare eller redaktörer laddar upp: bilder, PDF:er, videor. Webbserveranvändaren får skriva där, annars fungerar inte uppladdningarna. Just det gör mapparna attraktiva för angripare. Den som via en sårbarhet kan skriva filer lägger dem där skrivning är tillåten.
Nya PHP-filer i uppladdnings- eller cachemappar hör enligt de rapporter vi har tillgång till till de allmänna varningssignalerna efter ett intrång. För PHP2Shell finns inga bekräftade Indicators of Compromise; ett fynd säger alltså ingenting om via vilken sårbarhet filen kom. Hur uppladdningsfunktioner byggs säkert beskrivs i Genomför filuppladdningar i PHP säkert.
Om en sådan fil kan orsaka skada avgör webbserverns konfiguration. Kör den PHP-filer i uppladdningsmappen blir varje fil som läggs där en möjlig fjärrstyrning. Är körningen spärrad där förblir filen ett främmande föremål, men till en början utan verkan. Många installationer har aldrig satt upp den spärren.
Hur kommer en PHP-fil in i uppladdningsmappen?
För bedömningen hjälper det att känna till de möjliga vägarna. Var och en leder till andra följdfrågor.
| Väg | Typisk bakgrund | Följdfråga |
|---|---|---|
| Osäkert uppladdningsformulär | kontroll bara av ändelsen eller av typen som webbläsaren anger | Vilka formulär tar emot filer? |
| Sårbarhet i ett plugin eller tema | känd svaghet i ett föråldrat tillägg | Vilka tillägg är föråldrade? |
| Stulna inloggningsuppgifter | admin-, FTP- eller hostingkonto | Vilka inloggningar har gjorts nyligen? |
| Kodkörning via en sårbarhet | till exempel i tolken, som möjligt vid PHP2Shell | Var PHP sårbart under perioden? |
| Legitimt plugin | platshållare, sällan cachefiler | Tillhör filen originalpaketet? |
Flera vägar kan sammanfalla. En angripare som kör kod via en sårbarhet lägger kanske filen bara för att senare lättare kunna komma tillbaka.
Lista fyndplatserna systematiskt
Innan ni bedömer en enskild fil skaffar ni er en överblick. Kommandona läser bara. Sökvägarna är exempel för WordPress; för andra system anpassar ni uppladdningssökvägen.
# PHP-liknande filer i uppladdningsmappen med storlek, ägare, mtime och ctime
find /var/www/html/wp-content/uploads -type f \
\( -iname "*.php*" -o -iname "*.phtml" -o -iname "*.phar" -o -iname ".htaccess" -o -iname ".user.ini" \) \
-printf '%s Bytes %u m:%T+ c:%C+ %p\n'
# Bestäm filtyp efter innehåll i stället för ändelse (bilder med PHP-innehåll sticker ut)
find /var/www/html/wp-content/uploads -type f -newermt "2026-10-17" -exec file {} + | grep -viE "image|pdf|video|audio"
Andra system använder andra skrivmappar, till exempel fileadmin hos TYPO3, images hos Joomla eller mediamappen under public hos Shopware 6. Dessutom finns applikationens cache- och temp-kataloger. Vid multisite-installationer och flera webbplatser på en server finns motsvarande många uppladdningsmappar; var och en hör hemma i sökningen.
Även .htaccess- och .user.ini-filer i uppladdningsmappen är misstänkta. Med dem kan körning av PHP i den mappen slås på igen eller konfigurationen ändras.
PHP-fil i uppladdningsmappen: tolka fyndet rätt
Inte varje träff är lika allvarlig. Indelningen nedan hjälper vid den första bedömningen. Den ersätter ingen noggrann undersökning.
| Fynd | Första bedömning |
|---|---|
index.php med noll byte eller bara en kommentar |
oftast platshållare mot kataloglistning, stäm av mot pluginet |
| PHP-fil med innehåll i en månadsmapp | hög misstanke |
Dubbel ändelse som bild.jpg.php eller .php.png |
hög misstanke, typisk förklädnad |
Bild som enligt file innehåller PHP-kod |
hög misstanke, kan köras via inbindning |
.htaccess eller .user.ini i uppladdningsmappen |
misstanke, kontrollera konfigurationen |
| Filen tillhör webbserveranvändaren, ctime efter den 17.10. | passar till ett intrång via webbplatsen |
Läs misstänkta filer bara som text, till exempel med head -c 2000 datei.php eller less. Uppseendeväckande är mycket långa rader, kodade teckensträngar och funktionsnamn som eval eller base64_decode. Hur ni känner igen förvrängd kod visar Känn igen förvrängd PHP-kod.
Anropades filen? En titt i loggen
Den viktigaste frågan efter fyndet är: har någon använt filen? Svaret finns i webbserverns åtkomstloggar. Sök efter filnamnet, även i arkiverade loggar.
# Anrop av den misstänkta filen i aktuella och packade loggar (namnet som exempel)
grep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log* 2>/dev/null
zgrep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log*.gz 2>/dev/null
# Bara lyckade anrop med IP-adress och tidpunkt
grep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log* | awk '$9 == 200 {print $1, $4, $6, $7}'
Många lyckade POST-förfrågningar från få adresser tyder på aktiv användning som webbshell. Inga träffar betyder inte automatiskt att faran är över, eftersom loggar kan ha roterats, raderats eller vara ofullständiga. Körs webbplatsen bakom ett CDN eller en proxy finns fler loggar där; vid delad hosting ställer hostern oftast åtkomstloggarna till förfogande i kundområdet. Se också efter förfrågningar till andra nya filer från samma adresser, för de leder ofta till fler delar. Spara loggar från och med den 20 oktober. Hur ni utvärderar loggar noggrant står i guiden Utvärdera webbserverloggar efter ett angrepp.
Visar loggen lyckade anrop av en okänd PHP-fil, utgå från ett intrång. Säkra filen och loggarna, begränsa åtkomsten till servern och kontrollera om personuppgifter kan vara berörda.
Efter bedömningen: rätt ordning
- Säkra: Kopiera filen med kontrollsumma och tidsstämplar, säkra loggar.
- Klargör ursprunget: Kontrollera uppladdningsformulär, plugins och tiden före fyndet.
- Sök fler delar: ytterligare filer, cronjobb, nya adminkonton.
- Spärra körning: Förbjud PHP i uppladdningsmappen på webbservernivå, som beskrivs i inlägget Förbjud PHP-körning i uppladdningsmappar.
- Sanera och byt åtkomster: först därefter tar ni bort filen och förnyar alla lösenord.
Hur hjälper PHP SOS konkret?
- Bedöma fyndet: Vi granskar filen utan att köra den och placerar den.
- Klargöra användningen: Vi utvärderar loggarna och rekonstruerar vem som anropade filen och när.
- Sanera fullständigt: Med skadeprogramborttagningen söker vi alla delar, stänger orsaken och byter åtkomsterna.
- Förhindra upprepning: Vi spärrar PHP-körning i skrivmappar och övervakar nya filer.
Vanliga frågor
Är varje PHP-fil i uppladdningsmappen farlig?
Inte varje. Vissa plugins lägger en tom index.php så att mappens innehåll inte listas. Allt annat, särskilt filer med innehåll, ovanligt namn eller dubbel ändelse, bör ni behandla som misstanke.
Får jag öppna den misstänkta filen i webbläsaren?
Nej. Ett anrop via webbplatsen kör koden. Läs filen bara som text på servern eller i en kopia, till exempel med less eller head.
Hur tar jag reda på om filen har använts?
Sök efter filnamnet i webbserverns åtkomstloggar. Förfrågningar med status 200 och POST-metod visar att filen har anropats. De tillhörande IP-adresserna och tidpunkterna hjälper vid den fortsatta undersökningen.
Räcker det att radera filen och spärra PHP i uppladdningsmappen?
Båda behövs, men räcker inte. Klargör dessutom hur filen kom dit, sök efter fler delar och byt inloggningsuppgifterna. Annars kommer angriparen tillbaka samma väg.