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.
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; 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.
O que fazer já
- Observar antes de intervir. Anote a hora, as mensagens de erro e o que foi alterado por último (atualização, plugin, configuração).
- 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.
- 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.
- 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.
- Determinar a versão do PHP.
php -vmostra a versão, mas nem sempre a do ambiente de execução do servidor web. - 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.
- 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.
- 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.
- 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.
- 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 ou à resposta a incidentes 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 e possíveis sinais de intrusão em Processos suspeitos no 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.
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.
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.