# Servidor hackeado pelo PHP2Shell? Ligue-nos. Nós ajudamos.

> Suspeita de ataque PHP2Shell? Preservamos os vestígios, fechamos a vulnerabilidade e limpamos o servidor. Ligue ou escreva-nos por WhatsApp.

Fonte: https://phpsos.de/pt/soforthilfe/php2shell-gehackt/  
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:** se suspeita de que o seu servidor foi hackeado através do PHP2Shell, contacte-nos agora. Está afetado? Ligue-nos. Nós ajudamos. Desde a primeira mensagem, tratamos da contenção, preservamos os vestígios, fechamos a vulnerabilidade, removemos o código malicioso e documentamos o incidente até ao seu encerramento.

> **Agir de imediato:**
> **Não apague nada nem reinstale nada agora.** Os ficheiros apagados e os registos substituídos são os vestígios que mostram se, e como, alguém entrou. Se necessário, desligue o servidor da rede, mas deixe-o inalterado. [Comunicar uma emergência](https://phpsos.de/pt/notfall/); dizemos-lhe qual é o passo seguinte.

## Está afetado? Sinais de que o PHP2Shell já foi explorado

PHP2Shell é o nome de duas vulnerabilidades críticas no próprio PHP, com as quais os atacantes podem executar código malicioso remotamente, sem autenticação. Até agora não existe uma impressão digital inequívoca. Por isso, conta o que o servidor faz, e não o que um scanner encontra. São indícios de uma intrusão:

- Processos do servidor web ou do PHP-FPM que iniciam uma shell como `sh` ou `bash`. É um sinal de alerta forte.
- Ficheiros PHP novos ou alterados em pastas de uploads, de cache ou temporárias, que ninguém criou.
- Cronjobs, serviços ou chaves SSH que não conhece.
- Ligações de saída para destinos desconhecidos, carga subitamente elevada ou tráfego de dados invulgar.
- Pedidos nos registos a partir de 17/10/2026, em especial uploads e pedidos de sessão invulgares antes de o patch ser aplicado.
- Avisos do fornecedor de alojamento, do navegador ou do motor de pesquisa sobre spam, software malicioso ou redirecionamentos.

Encontra mais informação em [Já fui comprometido?](https://phpsos.de/pt/php2shell/bin-ich-gehackt-anzeichen/). A ausência de qualquer sinal não é prova de que o servidor está limpo. Significa apenas que, até agora, nada chamou a atenção.

## O que fazer já

1. **Não alterar nada.** Não apagar ficheiros, não repor cópias de segurança, não reinstalar antes de se ter feito a preservação.
2. **Preservar os registos.** Peça ao seu fornecedor de alojamento ou à sua equipa de TI que não substituam os registos de acesso, de erros e do sistema. A imprensa especializada aconselha a conservar os registos a partir de 20/10/2026.
3. **Decidir sobre a disponibilidade.** Se houver fuga de dados ou se os visitantes puderem estar em risco, retire o site da rede ou ponha-o em modo de manutenção.
4. **Reunir os acessos.** Anote quem tem acesso ao servidor, ao painel, ao CMS e à base de dados. As palavras-passe só devem ser alteradas após acordo connosco e a partir de um dispositivo limpo.
5. **Informar as pessoas certas.** A gerência, o encarregado da proteção de dados e, se existir apólice, a seguradora.
6. **Ligar-nos ou escrever-nos.** Quanto mais cedo conhecermos a situação, mais fica demonstrável.

## Como ajuda concretamente a PHP SOS?

Trabalhamos remotamente, sem deslocações, em toda a Alemanha e na Europa.

1. **Levantar a situação:** esclarecemos que sistemas estão em funcionamento, que modo de operação do PHP está em uso, o que chamou a atenção e que dados podem estar afetados.
2. **Preservar e fechar:** preservamos ficheiros, base de dados e registos e documentamos o estado antes de qualquer alteração. Depois fechamos a vulnerabilidade com o patch ou, se este ainda não for possível, com medidas provisórias, e reiniciamos todos os processos PHP.
3. **Verificar e limpar:** procuramos webshells, backdoors, cronjobs e acessos alheios e removemo-los, ou reconstruímos o sistema a partir de fontes fiáveis. O procedimento está descrito em [Remoção de malware e webshells](https://phpsos.de/pt/leistungen/malware-entfernung/).
4. **Reforçar e relatar:** alteramos os segredos afetados, reforçamos as medidas de proteção e entregamos um relatório que separa o que está comprovado, o que é provável e o que é desconhecido.

Se o incidente se estender para além de um servidor, passamos a uma [resposta a incidentes](https://phpsos.de/pt/leistungen/incident-response/) estruturada. Se forem necessárias provas que resistam em tribunal, recorremos à [perícia forense informática](https://phpsos.de/pt/leistungen/it-forensik/).

## Porque é que um patch, por si só, não basta depois de um ataque

As vulnerabilidades estão no interpretador PHP, não no CMS. O projeto PHP publicou a 21/10/2026 as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Quem atualizou depois disso e reiniciou todos os workers está protegido contra novos ataques por esta via. Mas o que um atacante deixou antes continua lá: uma webshell, uma conta adicional, uma tarefa agendada. É precisamente por isso que os dias entre 17 e 21/10 são especialmente importantes.

Há ainda um segundo ponto: uma webshell é muitas vezes apenas o primeiro passo. Quem conseguiu executar código no servidor web também pôde ler ficheiros de configuração e deles retirar acessos à base de dados, ao correio e a APIs. Esses segredos têm de ser substituídos; caso contrário, a porta continua aberta, embora o PHP esteja com o patch aplicado. O guia sobre como [reconhecer webshells](https://phpsos.de/pt/ratgeber/webshell-erkennen/) descreve como verificar de forma útil ficheiros e datas.

## Dever de notificação e documentação

Se dados pessoais puderem ter sido afetados, pode tornar-se necessária uma notificação à autoridade de controlo no prazo de 72 horas. O relógio corre a partir do conhecimento, não a partir do fim da investigação. Se o seu caso está sujeito a notificação, decidem-no o encarregado da proteção de dados ou um advogado; não prestamos aconselhamento jurídico. A nossa documentação fornece a base para isso. Encontra mais sobre o prazo em [Notificação RGPD em 72 horas](https://phpsos.de/pt/compliance/dsgvo-meldepflicht-72-stunden/) e sobre os passos seguintes na [lista de verificação após um hack](https://phpsos.de/pt/ratgeber/checkliste-nach-dem-hack/).

## O que nos deve enviar

- Descrição do que chama a atenção, desde quando e quem o notou
- Tipo de servidor: servidor próprio, servidor gerido ou pacote de alojamento, e o fornecedor
- Resultado de `php -v` e, se for conhecido, o modo de operação (PHP-FPM, mod_php, LiteSpeed)
- Momento da atualização do PHP, se já tiver sido aplicada
- Acesso ao servidor ou autorização para falarmos com o seu fornecedor de alojamento
- Pessoa de contacto com poder de decisão para desligar e reiniciar

## Porquê a PHP SOS

Trabalhamos com qualidade Made in Germany e, há mais de 25 anos, estamos especializados em segurança informática com a nossa rede de parceiros de profissionais de cibersegurança. Tem um interlocutor que o acompanha desde a primeira mensagem até ao encerramento. Tudo o que fazemos fica documentado, para que o possa comprovar perante a gerência, a seguradora e as autoridades. Não prometemos nada que ninguém possa cumprir: se faltarem registos, dizemo-lo abertamente e indicamos o que está comprovado e o que continua a ser suposição.

## Está afetado? Ligue-nos. Nós ajudamos.

Não espere que a suspeita se torne certeza. Ligue ou escreva-nos por WhatsApp. Assumimos o caso desde a primeira mensagem e ficamos até o incidente estar encerrado e documentado. [Comunicar já uma emergência](https://phpsos.de/pt/notfall/).


## Perguntas frequentes

**Basta atualizar o PHP se o meu servidor já tiver sido hackeado?**  
Não. A atualização fecha a vulnerabilidade, mas não remove software malicioso já introduzido e não prova que nada aconteceu antes. Depois do patch, é preciso verificar se o servidor apresenta vestígios de uma intrusão.

**Como reconheço um ataque PHP2Shell bem-sucedido?**  
Não existem indicadores de comprometimento (IOC) confirmados e publicados. A deteção baseia-se no comportamento: processos do servidor web que iniciam uma shell, novos ficheiros PHP em pastas de uploads ou de cache, cronjobs ou chaves SSH desconhecidos e ligações de saída invulgares.

**Devo desligar o servidor da rede se suspeitar de uma intrusão?**  
Muitas vezes é o correto: o BSI (Gabinete Federal Alemão para a Segurança da Informação) aconselha mesmo, quando a atualização não é possível de imediato, a retirar temporariamente os servidores web da rede. O importante é não apagar nada e conservar os registos e os ficheiros, para que o incidente possa ser esclarecido.

**Tenho de informar a autoridade de proteção de dados depois de um ataque PHP2Shell?**  
Se dados pessoais puderem estar afetados, pode ser necessária uma notificação no prazo de 72 horas. A decisão é tomada com o seu encarregado da proteção de dados ou com um advogado; nós fornecemos os factos técnicos para isso.

**Já houve mesmo servidores hackeados através do PHP2Shell?**  
Segundo notícias dos meios de comunicação, houve as primeiras tentativas de ataque observadas a partir de 17/10/2026, e a Cloudflare relatou tentativas de ataque observadas. O BSI não comunicou, para já, ataques bem-sucedidos confirmados em larga escala. Num caso concreto, isso só se esclarece no próprio servidor.

## Fontes

- [BSI: Gabinete Federal Alemão para a Segurança da Informação](https://www.bsi.bund.de/)
- [php.net: avisos de segurança](https://www.php.net/)
- [RGPD Art. 33: notificação à autoridade de controlo](https://dsgvo-gesetz.de/art-33-dsgvo/)