Kort sagt: En PHP-fil i upload-mappen er et alvorligt advarselstegn, for dér bør der kun ligge billeder og dokumenter. Åbn aldrig filen i browseren, men læs den som tekst, kontrollér tidsstempler og ejer, og søg filnavnet i adgangslogs. Harmløse er som regel kun tomme pladsholdere som en index.php uden indhold; alt andet behandler I som et muligt indbrud.
Hvorfor PHP ikke har noget at gøre i upload-mappen
Upload-mapper er til indhold, som besøgende eller redaktører uploader: billeder, PDF'er, videoer. Webserverbrugeren må skrive dér, ellers virker uploads ikke. Netop det gør disse mapper attraktive for angribere. Den, der via en sårbarhed kan skrive filer, lægger dem dér, hvor det er tilladt at skrive.
Nye PHP-filer i upload- eller cache-mapper hører ifølge de rapporter, vi har foran os, til de generelle advarselstegn efter et indbrud. For PHP2Shell findes der ingen bekræftede indicators of compromise; et fund siger altså intet om, via hvilken sårbarhed filen kom. Hvordan upload-funktioner bygges sikkert, beskriver Gennemfør filuploads i PHP sikkert.
Om en sådan fil kan gøre skade, afgør webserverens konfiguration. Udfører den PHP-filer i upload-mappen, bliver hver fil, der er lagt dér, til en mulig fjernstyring. Er udførelsen spærret dér, forbliver filen et fremmedlegeme, men foreløbig uden virkning. Mange installationer har aldrig sat denne spærring op.
Hvordan kommer en PHP-fil ind i upload-mappen?
Til vurderingen hjælper det at kende de mulige veje. Hver fører til andre opfølgende spørgsmål.
| Vej | Typisk baggrund | Opfølgende spørgsmål |
|---|---|---|
| Usikker upload-formular | kontrol kun af endelsen eller af den type, browseren melder | Hvilke formularer modtager filer? |
| Sårbarhed i et plugin eller tema | kendt svaghed i en forældet udvidelse | Hvilke udvidelser er forældede? |
| Stjålne adgangsdata | admin-, FTP- eller hostingkonto | Hvilke logins var der for nylig? |
| Kodeudførelse via en sårbarhed | f.eks. i fortolkeren, som muligt ved PHP2Shell | Var PHP sårbar i perioden? |
| Legitimt plugin | pladsholdere, sjældent cachefiler | Hører filen til den oprindelige pakke? |
Flere veje kan komme sammen. En angriber, der udfører kode via en sårbarhed, lægger måske filen blot for senere at vende bekvemmere tilbage.
Opregn fundsteder systematisk
Før I vurderer en enkelt fil, skaffer I jer et overblik. Kommandoerne læser kun. Stierne er eksempler for WordPress; ved andre systemer tilpasser I upload-stien.
# PHP-lignende filer i upload-mappen med størrelse, ejer, mtime og 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'
# Bestem filtype efter indhold i stedet for endelse (billeder med PHP-indhold falder i øjnene)
find /var/www/html/wp-content/uploads -type f -newermt "2026-10-17" -exec file {} + | grep -viE "image|pdf|video|audio"
Andre systemer bruger andre skrivemapper, f.eks. fileadmin ved TYPO3, images ved Joomla eller mediemappen under public ved Shopware 6. Dertil kommer applikationens cache- og temp-mapper. Ved multisite-installationer og flere websites på én server findes der tilsvarende mange upload-mapper; hver hører med i søgningen.
Også .htaccess- og .user.ini-filer i upload-mappen er mistænkelige. Med dem kan udførelsen af PHP i denne mappe slås til igen, eller konfigurationen ændres.
PHP-fil i uploads-mappen: tolk fundet korrekt
Ikke ethvert fund er lige alvorligt. Følgende inddeling hjælper ved den første vurdering. Den erstatter ikke en nøje undersøgelse.
| Fund | Første vurdering |
|---|---|
index.php med nul bytes eller kun en kommentar |
som regel pladsholder mod visning af mappeindhold, afstem med pluginet |
| PHP-fil med indhold i en månedsmappe | stærk mistanke |
Dobbelt endelse som bild.jpg.php eller .php.png |
stærk mistanke, typisk camouflage |
Billede, der ifølge file indeholder PHP-kode |
stærk mistanke, kan udføres via indbinding |
.htaccess eller .user.ini i upload-mappen |
mistanke, kontrollér konfigurationen |
| Filen tilhører webserverbrugeren, ctime efter den 17.10. | passer til et indbrud via websitet |
Læs mistænkelige filer kun som tekst, f.eks. med head -c 2000 datei.php eller less. Påfaldende er meget lange linjer, kodede tegnstrenge og funktionsnavne som eval eller base64_decode. Hvordan I genkender tilsløret kode, viser Genkend tilsløret PHP-kode.
Blev filen kaldt? Et kig i loggen
Det vigtigste spørgsmål efter fundet lyder: Har nogen brugt filen? Svaret står i webserverens adgangslogs. Søg efter filnavnet, også i arkiverede logs.
# Kald af den mistænkelige fil i aktuelle og pakkede logs (navnet er et eksempel)
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
# Kun vellykkede kald med IP-adresse og tidspunkt
grep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log* | awk '$9 == 200 {print $1, $4, $6, $7}'
Mange vellykkede POST-forespørgsler fra få adresser peger på aktiv brug som webshell. Ingen fund betyder ikke automatisk fuld afblæsning, for logs kan være roteret, slettet eller ufuldstændige. Ligger websitet bag et CDN eller en proxy, findes der yderligere logs dér; ved shared hosting stiller hostingudbyderen som regel adgangslogs til rådighed i kundeområdet. Vær desuden opmærksom på forespørgsler til andre nye filer fra de samme adresser, for de fører ofte til yderligere bestanddele. Opbevar logs fra og med den 20. oktober. Hvordan I analyserer logs grundigt, står i vejledningen Analysér webserver-logs efter et angreb.
Viser loggen vellykkede kald af en ukendt PHP-fil, så gå ud fra et indbrud. Sikr fil og logs, begræns adgangen til serveren, og kontrollér, om personoplysninger kan være berørt.
Efter vurderingen: den rette rækkefølge
- Sikr: Kopiér filen med kontrolsum og tidsstempler, sikr logs.
- Afklar oprindelsen: Kontrollér upload-formularer, plugins og perioden før fundet.
- Søg yderligere bestanddele: ekstra filer, cronjobs, nye admin-konti.
- Spær udførelsen: Forbyd PHP i upload-mappen på webserverniveau, som beskrevet i indlægget Forbyd PHP-udførelse i upload-mapper.
- Ryd op og skift adgange: først derefter fjernes filen, og alle adgangskoder fornyes.
Hvordan hjælper PHP SOS konkret?
- Vurdér fundet: Vi kontrollerer filen uden at udføre den og vurderer den.
- Afklar brugen: Vi analyserer logs og rekonstruerer, hvem der har kaldt filen hvornår.
- Ryd fuldstændigt op: Med malwarefjernelsen søger vi alle bestanddele, lukker årsagen og skifter adgangene.
- Forhindr gentagelse: Vi spærrer PHP-udførelsen i skrivemapper og overvåger nye filer.
Ofte stillede spørgsmål
Er enhver PHP-fil i upload-mappen farlig?
Ikke enhver. Nogle plugins lægger en tom index.php, så mappens indhold ikke bliver vist som liste. Alt andet, især filer med indhold, usædvanligt navn eller dobbelt endelse, bør I behandle som mistanketilfælde.
Må jeg åbne den mistænkelige fil i browseren?
Nej. Et kald via websitet udfører koden. Læs kun filen som tekst på serveren eller i en kopi, f.eks. med less eller head.
Hvordan finder jeg ud af, om filen er blevet brugt?
Søg filnavnet i webserverens adgangslogs. Forespørgsler med status 200 og POST-metoden viser, at filen er blevet kaldt. De tilhørende IP-adresser og tidspunkter hjælper ved den videre undersøgelse.
Er det nok at slette filen og spærre PHP i upload-mappen?
Begge dele er nødvendige, men ikke tilstrækkelige. Afklar desuden, hvordan filen kom derhen, søg efter yderligere bestanddele, og skift adgangsdata. Ellers kommer angriberen tilbage ad samme vej.