# Emergência PHP? Ligue ou use o WhatsApp: nós ajudamos

> Servidor PHP em baixo, sobrecarregado ou com comportamento estranho? Fale diretamente com um especialista. Ligue ou escreva-nos por WhatsApp.

Fonte: https://phpsos.de/pt/soforthilfe/php-notfall-hilfe/  
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 o seu servidor PHP dá problemas e quer falar diretamente com um especialista, ligue ou escreva-nos por WhatsApp. Está afetado? Ligue-nos. Nós ajudamos. Esclarecemos remotamente se por trás está uma falha, uma configuração errada ou um ataque, e assumimos o caso desde a primeira mensagem, até o incidente estar encerrado e documentado.

> **Agir de imediato:**
> **Não apague nada nem reinstale nada agora.** Também um reinício ou um rollback pode apagar vestígios. Descreva-nos primeiro o que vê. [Comunicar uma emergência](https://phpsos.de/pt/notfall/); depois definimos o passo seguinte.

## Está afetado? Estas perturbações são um caso para nós

Nem toda a perturbação é um ataque, mas nestes dias vale a pena verificar. Contacte-nos se no seu sistema PHP ocorrer o seguinte:

- Os processos PHP ou o servidor web falham, reiniciam-se repetidamente ou são terminados pelo sistema (estado de saída 137).
- A carga sobe sem motivo aparente ou a memória se esgota.
- As páginas devolvem respostas vazias, erros 500 ou mensagens de erro que antes não existiam.
- Sob o servidor web ou o PHP-FPM correm processos que iniciam uma shell.
- Na pasta de uploads ou de cache há ficheiros PHP que não conhece.
- Depois de uma atualização do PHP, uma aplicação deixou de funcionar.
- O seu fornecedor de alojamento bloqueou o acesso ou desligou o site.

A diferença entre falha e ataque só se vê, na maioria das vezes, nos registos. Os primeiros indícios do que importa descreve-os o artigo [O servidor web inicia uma shell](https://phpsos.de/pt/blog/webserver-startet-shell/).

## O que fazer já

1. **Observar antes de intervir.** Anote a hora, as mensagens de erro e o que foi alterado por último (atualização, plugin, configuração).
2. **Preservar os registos.** Copie os registos do servidor web, do PHP e do sistema antes de rodarem. A imprensa especializada aconselha a conservar os registos a partir de 20/10/2026.
3. **Não reiniciar às cegas.** Um reinício resolve algumas falhas, mas destrói vestígios voláteis. Reinicie se a operação o exigir e anote o que fez.
4. **Ponderar a disponibilidade.** Se suspeita de um ataque, isolar ou desligar é muitas vezes o correto. O BSI aconselha-o quando a atualização não é possível de imediato.
5. **Determinar a versão do PHP.** `php -v` mostra a versão, mas nem sempre a do ambiente de execução do servidor web.
6. **Ligar ou escrever.** Quanto mais exatamente puder descrever a situação, mais depressa chegamos ao essencial.

## Como ajuda concretamente a PHP SOS?

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

1. **Levantar a situação:** na primeira conversa, ouvimos e perguntamos de forma dirigida: sistemas, modo de operação do PHP, momento, últimas alterações. Depois fica a saber se vemos uma falha ou uma suspeita de ataque.
2. **Preservar e fechar:** preservamos o estado, resolvemos a causa e, se necessário, fechamos a vulnerabilidade com atualização, reinício e medidas provisórias.
3. **Verificar e limpar:** se se confirmar uma intrusão, removemos o código malicioso e verificamos acessos e segredos. Caso contrário, documentamos a causa e deixamos a operação a funcionar de forma limpa.
4. **Reforçar e relatar:** recebe um relatório breve e recomendações para que a perturbação não se repita.

Se houver mais por trás, passamos à [ajuda de emergência para sites hackeados](https://phpsos.de/pt/leistungen/website-gehackt-notfallhilfe/) ou à [resposta a incidentes](https://phpsos.de/pt/leistungen/incident-response/) estruturada.

## Memória, falhas e o novo limite

Desde as versões de segurança de 21/10/2026 (8.5.12, 8.4.27, 8.3.36, 8.2.35) existe a diretiva `memory_hard_limit_percent`. Desde então, o `memory_limit` é um limite suave. Sem definição própria, o limite rígido é o dobro do `memory_limit` até 1G e, acima disso, o `memory_limit` mais 1G. Se for excedido, o processo termina de imediato com o estado de saída 137. Uma operação que antes da atualização corria perto do limite pode, por isso, passar a mostrar falhas de repente. Isso não é um ataque, mas uma consequência da correção, e a solução é ajustar corretamente a aplicação ou o limite, e não reverter a atualização.

Inversamente, vale que quem vê processos falhados e ainda não aplicou o patch não deve descartá-lo como acaso, porque a vulnerabilidade CVE-2026-109618 está relacionada com um estado de falta de memória (Out of Memory). Se isso tem importância no seu caso, mostram-no os registos. Pode encontrar informação de fundo sobre a gestão de memória em [Out of Memory no PHP](https://phpsos.de/pt/php/out-of-memory/) e possíveis sinais de intrusão em [Processos suspeitos no Linux](https://phpsos.de/pt/blog/verdaechtige-prozesse-linux/).

## Quando o fornecedor de alojamento intervém

Alguns fornecedores bloqueiam contas ou colocam sites offline por precaução. Isso não significa automaticamente que foi hackeado, mas pode ser consequência de anomalias. Pergunte pelo motivo e pelo momento, peça os registos e anote o que o fornecedor exige. Articulamo-nos com o seu fornecedor de alojamento, se o desejar. É útil esclarecer previamente quem, no fornecedor, pode tomar decisões e se aí existem registos do servidor que você próprio não pode consultar. Esses dados, por exemplo acessos ao nível da rede, podem mais tarde ser decisivos para delimitar o momento de uma possível intrusão.

## O que nos deve enviar

- breve descrição: o que falhou ou chama a atenção, desde quando?
- tipo de sistema (servidor próprio, pacote de alojamento, contentor) e fornecedor de alojamento
- resultado de `php -v`, modo de operação e servidor web, na medida do conhecido
- mensagens de erro ou excertos dos registos
- momento da última atualização do PHP e das últimas alterações
- pessoa de contacto com poder de decisão para reinícios

## 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. Fala com um interlocutor fixo, e não com um sistema de tickets. Trabalhamos remotamente, documentamos o que vemos e fazemos, e dizemos abertamente o que está comprovado e o que não está. Para casos agudos em torno da vulnerabilidade existe ainda a [ajuda urgente PHP2Shell](https://phpsos.de/pt/leistungen/php2shell-soforthilfe/).

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

Se o seu servidor PHP dá problemas, não espere pela próxima falha. Ligue ou escreva-nos por WhatsApp. Assumimos o caso desde a primeira mensagem. [Comunicar já uma emergência](https://phpsos.de/pt/notfall/).


## Perguntas frequentes

**O meu servidor PHP ficou de repente lento ou falha: é um ataque?**  
Não necessariamente. As falhas têm muitas vezes causas banais, como falta de memória, uma atualização defeituosa ou sobrecarga. Só uma vista de olhos aos registos e aos processos mostra se é um ataque; são sinais de alerta, por exemplo, processos de shell sob o servidor web ou novos ficheiros PHP desconhecidos.

**O que significa o estado de saída 137 nos processos PHP?**  
O estado 137 indica um processo terminado de imediato. Segundo o manual do PHP, um processo termina com 137 quando ultrapassa o limite rígido de memória da nova diretiva memory_hard_limit_percent; mas também pode ter sido terminado pelo sistema por falta de memória. A causa esclarece-se nos registos.

**Posso falar ao telefone com um especialista antes de alterar alguma coisa?**  
Sim, a ajuda de emergência existe precisamente para isso. Ligue ou escreva-nos por WhatsApp e descreva o que chama a atenção. Dizemos-lhe o que deve deixar e o que pode fazer sem perigo.

**Devo simplesmente reiniciar o serviço PHP?**  
Um reinício pode resolver uma falha, mas apaga indícios na memória. Se for possível uma intrusão, preserve antes os registos e aconselhe-se. Depois de uma atualização do PHP, em contrapartida, o reinício é obrigatório.

**Também trabalham se o meu servidor estiver num fornecedor de alojamento?**  
Sim, trabalhamos remotamente com o acesso que tem e, se necessário, articulamo-nos com o seu fornecedor de alojamento. As verificações possíveis dependem dos seus direitos.

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [Manual do PHP: configuração do núcleo (ini.core)](https://www.php.net/manual/en/ini.core.php)
- [BSI: Gabinete Federal Alemão para a Segurança da Informação](https://www.bsi.bund.de/)