# Ficheiros PHP na pasta de upload: interpretar bem os achados

> Encontrou um ficheiro PHP na pasta de uploads? Como interpretar o achado, verificar acessos no registo, distinguir marcadores inofensivos de webshells e agir bem.

Fonte: https://phpsos.de/pt/blog/php-dateien-im-upload-ordner/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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](https://phpsos.de/pt/ratgeber/datei-upload-sicher/).

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.

```bash
# 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](https://phpsos.de/pt/blog/verschleierter-php-code/).

## 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.

```bash
# 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](https://phpsos.de/pt/ratgeber/logfiles-auswerten/).

> **Agir de imediato:**
> 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

1. **Guardar:** copiar o ficheiro com soma de verificação e carimbos de data/hora, guardar os registos.
2. **Esclarecer a origem:** verificar formulários de upload, plugins e o período anterior ao achado.
3. **Procurar outros componentes:** ficheiros adicionais, cronjobs, novas contas de administrador.
4. **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](https://phpsos.de/pt/blog/php-in-uploads-verbieten/).
5. **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](https://phpsos.de/pt/leistungen/malware-entfernung/), 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.

## Fontes

- [OWASP Cheat Sheet Series (entre outros File Upload)](https://cheatsheetseries.owasp.org/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [php.net: avisos de segurança](https://www.php.net/)