Em resumo: Um ficheiro PHP na pasta de upload é um sinal de alerta sério, porque aí só deviam estar imagens e documentos. Nunca abra o ficheiro no navegador, leia-o como texto, verifique carimbos de data/hora e proprietário e procure o nome do ficheiro nos registos de acesso. Em regra só são inofensivos marcadores vazios, como um index.php sem conteúdo; tudo o resto trate como possível intrusão.
Porque é que o PHP não tem nada que fazer na pasta de upload
As pastas de upload servem para conteúdos que visitantes ou redatores carregam: imagens, PDFs, vídeos. O utilizador do servidor web pode escrever aí, caso contrário os uploads não funcionam. É precisamente isso que torna estas pastas atrativas para os atacantes. Quem consegue escrever ficheiros através de uma vulnerabilidade guarda-os onde a escrita é permitida.
Novos ficheiros PHP em pastas de upload ou de cache contam, segundo os relatos de que dispomos, entre os sinais de alerta gerais após uma intrusão. Para o PHP2Shell não existem Indicators of Compromise confirmados; um achado não diz portanto nada sobre a vulnerabilidade através da qual o ficheiro chegou. Como construir funções de upload de forma segura descreve-o Implementar uploads de ficheiros em PHP em segurança.
Se um ficheiro destes pode causar danos, decide-o a configuração do servidor web. Se ele executar ficheiros PHP na pasta de upload, qualquer ficheiro aí guardado passa a ser um possível controlo remoto. Se a execução aí estiver bloqueada, o ficheiro continua a ser um corpo estranho, mas inicialmente sem efeito. Muitas instalações nunca configuraram este bloqueio.
Como chega um ficheiro PHP à pasta de upload?
Para a avaliação, ajuda conhecer os caminhos possíveis. Cada um leva a outras perguntas seguintes.
| Caminho | Contexto típico | Pergunta seguinte |
|---|---|---|
| Formulário de upload inseguro | verificação apenas da extensão ou do tipo comunicado pelo navegador | Que formulários aceitam ficheiros? |
| Vulnerabilidade num plugin ou tema | vulnerabilidade conhecida numa extensão desatualizada | Que extensões estão desatualizadas? |
| Credenciais roubadas | conta de administrador, FTP ou alojamento | Que autenticações houve recentemente? |
| Execução de código através de uma vulnerabilidade | por exemplo no interpretador, como é possível com o PHP2Shell | O PHP estava vulnerável nesse período? |
| Plugin legítimo | marcador, raramente ficheiros de cache | O ficheiro pertence ao pacote original? |
Vários caminhos podem juntar-se. Um atacante que executa código através de uma vulnerabilidade talvez só guarde o ficheiro para regressar mais comodamente mais tarde.
Listar sistematicamente os locais de achado
Antes de avaliar um ficheiro isolado, faça um levantamento. Os comandos só leem. Os caminhos são exemplos para WordPress; noutros sistemas adapte o caminho de upload.
# Ficheiros semelhantes a PHP na pasta de upload com tamanho, proprietário, mtime e 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'
# Determinar o tipo de ficheiro pelo conteúdo e não pela extensão (imagens com conteúdo PHP dão nas vistas)
find /var/www/html/wp-content/uploads -type f -newermt "2026-10-17" -exec file {} + | grep -viE "image|pdf|video|audio"
Outros sistemas usam outras pastas de escrita, como fileadmin no TYPO3, images no Joomla ou a pasta de multimédia em public no Shopware 6. Acrescem os diretórios de cache e temporários da aplicação. Em instalações multisite e com vários sites num servidor há outras tantas pastas de upload; cada uma pertence à pesquisa.
Também os ficheiros .htaccess e .user.ini na pasta de upload são suspeitos. Com eles pode voltar a ligar-se a execução do PHP nessa pasta ou alterar-se a configuração.
Ficheiro PHP na pasta de uploads: interpretar bem o achado
Nem todo o resultado é igualmente sério. O enquadramento seguinte ajuda na primeira avaliação. Não substitui uma investigação rigorosa.
| Resultado | Primeiro enquadramento |
|---|---|
index.php com zero bytes ou apenas um comentário |
em regra marcador contra a listagem de diretórios, comparar com o plugin |
| Ficheiro PHP com conteúdo numa pasta mensal | suspeita elevada |
Dupla extensão como bild.jpg.php ou .php.png |
suspeita elevada, camuflagem típica |
Imagem que, segundo o file, contém código PHP |
suspeita elevada, pode ser executada por inclusão |
.htaccess ou .user.ini na pasta de upload |
suspeita, verificar a configuração |
| O ficheiro pertence ao utilizador do servidor web, ctime depois de 17/10 | coincide com uma intrusão através do site |
Leia os ficheiros suspeitos apenas como texto, por exemplo com head -c 2000 datei.php ou less. Chamam a atenção linhas muito longas, cadeias de caracteres codificadas e nomes de funções como eval ou base64_decode. Como reconhecer código ofuscado mostra-o Reconhecer código PHP ofuscado.
O ficheiro foi chamado? Um olhar ao registo
A pergunta mais importante depois do achado é: alguém usou o ficheiro? A resposta está nos registos de acesso do servidor web. Procure o nome do ficheiro, também em registos arquivados.
# Chamadas ao ficheiro suspeito em registos atuais e comprimidos (nome como exemplo)
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
# Apenas chamadas bem-sucedidas com endereço IP e momento
grep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log* | awk '$9 == 200 {print $1, $4, $6, $7}'
Muitos pedidos POST bem-sucedidos de poucos endereços indicam uso ativo como webshell. A ausência de resultados não significa automaticamente que está tudo bem, porque os registos podem ter sido rodados, apagados ou estar incompletos. Se o site corre atrás de uma CDN ou de um proxy, há mais registos aí; no alojamento partilhado, o fornecedor disponibiliza em regra os registos de acesso na área de cliente. Atenção também a pedidos a outros ficheiros novos dos mesmos endereços, porque levam muitas vezes a outros componentes. Conserve os registos a partir de 20 de outubro. Como avaliar registos a fundo está no guia Analisar os registos do servidor web após um ataque.
Se o registo mostrar chamadas bem-sucedidas a um ficheiro PHP desconhecido, parta do princípio de que houve uma intrusão. Guarde o ficheiro e os registos, restrinja o acesso ao servidor e verifique se podem estar afetados dados pessoais.
Depois da avaliação: a ordem certa
- Guardar: copiar o ficheiro com soma de verificação e carimbos de data/hora, guardar os registos.
- Esclarecer a origem: verificar formulários de upload, plugins e o período anterior ao achado.
- Procurar outros componentes: ficheiros adicionais, cronjobs, novas contas de administrador.
- Bloquear a execução: proibir o PHP na pasta de upload ao nível do servidor web, como descrito no artigo Proibir a execução de PHP em pastas de upload.
- Limpar e mudar os acessos: só então remover o ficheiro e renovar todas as palavras-passe.
Como ajuda concretamente a PHP SOS?
- Avaliar o achado: verificamos o ficheiro sem o executar e enquadramo-lo.
- Esclarecer a utilização: analisamos os registos e reconstituímos quem chamou o ficheiro e quando.
- Limpar por completo: com a remoção de malware, procuramos todos os componentes, fechamos a causa e mudamos os acessos.
- Evitar a repetição: bloqueamos a execução de PHP em pastas de escrita e vigiamos novos ficheiros.
Perguntas frequentes
Todo o ficheiro PHP na pasta de upload é perigoso?
Nem todos. Alguns plugins guardam um index.php vazio, para que o conteúdo da pasta não seja listado. Tudo o resto, em especial ficheiros com conteúdo, nome invulgar ou dupla extensão, deve ser tratado como caso suspeito.
Posso abrir no navegador o ficheiro suspeito?
Não. Um acesso através do site executa o código. Leia o ficheiro apenas como texto no servidor ou numa cópia, por exemplo com less ou head.
Como descubro se o ficheiro foi usado?
Procure o nome do ficheiro nos registos de acesso do servidor web. Pedidos com estado 200 e método POST mostram que o ficheiro foi chamado. Os endereços IP e os momentos associados ajudam na investigação seguinte.
Basta apagar o ficheiro e bloquear o PHP na pasta de upload?
Ambas as coisas são necessárias, mas não suficientes. Esclareça além disso como o ficheiro lá chegou, procure outros componentes e mude as credenciais. Caso contrário, o atacante regressa pelo mesmo caminho.