PHP sem patch é uma porta aberta. Nós fechamo-la.
Assistência de emergência remota para empresas na Europa: aplicar patches ao PHP, verificar vestígios de intrusão, remover código malicioso, reforçar a segurança do servidor. De imediato, com parceiros especializados, até o incidente estar concluído e documentado.
$ php -v PHP 8.3.35 (cli) (built: Sep 30 2026) ! Estado antes do patch de 21/10/2026 $ phpsos pruefen --ziel produktion Modo de operação .. php-fpm CVE-2026-109618 .. aberto CVE-2026-109619 .. aberto Reinício dos workers .. pendente $ phpsos absichern [ok] Pacote 8.3.36 instalado [ok] todos os workers reiniciados [ok] Sistema de ficheiros verificado quanto a webshells [ok] Relatório para a administração elaborado
- Made in GermanySegurança informática da Alemanha, com trabalho conforme o direito europeu de proteção de dados.
- Mais de 25 anosEspecializados há mais de 25 anos em segurança informática e operação de servidores, com a nossa rede de parceiros.
- Rede de parceirosProfissionais de cibersegurança especializados em forense digital, testes de intrusão e reforço de servidores, coordenados através de um único interlocutor.
Está afetado? Ligue-nos. Nós ajudamos.
Atacado, bloqueado, web shell encontrada ou dúvidas sobre se o PHP2Shell o afeta: contacte-nos agora. Assumimos o caso desde a primeira mensagem, remotamente e sem deslocações.
O seu PHP já tem o patch aplicado?
Introduza a sua versão do PHP. O teste compara-a com os avisos de segurança do php.net e indica o que fazer a seguir. Importante: mesmo uma versão com patch não prova que nada aconteceu antes da atualização.
Quão urgente é a sua situação?
Quatro perguntas, uma classificação, os primeiros passos e uma mensagem de WhatsApp preparada para nós. No nível 3 aplica-se: não apagar nada, não reinstalar nada, preservar os vestígios.
Do pedido de socorro ao servidor reforçado
Assumimos a parte técnica e fornecemos os comprovativos de que a administração, a proteção de dados e a seguradora precisam.
Ajuda imediata PHP2Shell: assistência na vulnerabilidade do PHP
Corrigimos o PHP2Shell nos seus servidores web remotamente: levantamento, patch ou medida provisória, reinício de todos os workers e comprovativo por escrito.
Ler mais →02Site comprometido, o que fazer? Assistência de emergência remota
O seu site foi comprometido ou comporta-se de forma invulgar? Assumimos remotamente a contenção, a preservação de vestígios, a limpeza e a documentação.
Ler mais →03Serviço de patches PHP: atualização com reinício e comprovativo
Instalamos a atualização do PHP nos seus servidores, reiniciamos todos os processos PHP e entregamos um comprovativo escrito da versão, do estado do pacote e do reinício.
Ler mais →04Hardening de servidor para servidores web PHP
Reforçamos os seus servidores web PHP segundo um plano fixo: isolamento por site, configuração segura do PHP, permissões de ficheiros, acessos, registos e cópias de segurança.
Ler mais →05Remover malware e webshells de um site
Removemos código malicioso, webshells e backdoors de sites e servidores, reconstruímos a partir de fontes fiáveis e fechamos a porta de entrada.
Ler mais →06Resposta a incidentes em ataques a servidores
Tratamento estruturado de incidentes em ataques a servidores web: panorama da situação, contenção, eliminação, recuperação e balanço, com funções definidas.
Ler mais →Como trabalhamos em caso de emergência
Passos claros, um único interlocutor, tudo remoto. Especialistas da nossa rede de parceiros juntam-se quando são necessários perícia forense ou testes de intrusão.
Avaliar a situação
Escreva-nos por WhatsApp ou ligue. Esclarecemos o sistema, a versão do PHP, o fornecedor de alojamento e as observações.
Preservar e fechar
Preservar vestígios, aplicar patch ao PHP ou medidas provisórias, reiniciar todos os workers, comprovar o nível de patch.
Verificar e limpar
Verificar ficheiros, base de dados, contas e registos quanto a vestígios de intrusão. Remover webshells e backdoors.
Reforçar e reportar
Reforçar a configuração, configurar a monitorização, elaborar o relatório para a administração, a proteção de dados e a seguradora.
Ainda não é possível aplicar o patch? Medidas provisórias
O php.net indica definições que dificultam as vias de ataque conhecidas até a atualização estar instalada. Escolha o seu modo de operação, copie as linhas e reinicie depois todos os processos PHP.
O BSI (Gabinete Federal Alemão para a Segurança da Informação) recomenda: se a atualização não for possível de imediato, desligar temporariamente o servidor web da rede.
Medidas provisórias segundo o php.net, não substituem a atualização. memory_limit=-1 apenas em conjunto com um limite de memória através de contentor ou cgroup. Faça antes uma cópia de segurança da configuração.
Quem faz o quê? A lacuna entre o fornecedor de alojamento e a agência
Muitas empresas confiam em que “alguém” aplica o patch. Em regra, a distribuição é a seguinte:
| Tarefa | Fornecedor de alojamento (alojamento partilhado) | Agência / web design | PHP SOS |
|---|---|---|---|
| Atualizar o pacote PHP | normalmente sim | normalmente não | sim, ou com o seu fornecedor de alojamento |
| Reiniciar todos os workers e comprová-lo | em parte | não | sim, com comprovativo |
| Verificar se houve intrusão antes do patch | em regra, não | em parte | sim |
| Remover webshells e backdoors | em regra, não | em parte | sim |
| Relatório para a administração, a proteção de dados e a seguradora | não | raramente | sim |
| Hardening e monitorização contínua | em parte | em parte | sim |
O que está comprovado e o que deve fazer agora
Factos extraídos dos avisos do php.net e do BSI, preparados para a administração e para os administradores de sistemas.
O que é o PHP2Shell? A vulnerabilidade explicada de forma simples
O PHP2Shell são duas vulnerabilidades críticas no próprio PHP, através das quais os atacantes podem executar código em servidores web sem autenticação. A situação em palavras claras.
Ler mais →CVE-2026-109618: RCE através de um estado de falta de memória
A CVE-2026-109618 é uma das duas vulnerabilidades do PHP2Shell: um estado de falta de memória pode interromper o PHP a meio do processamento do pedido. Corrigida a partir do PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
Ler mais →CVE-2026-109619: RCE através de estado global obsoleto
A CVE-2026-109619 é a segunda vulnerabilidade do PHP2Shell: o estado interno de um pedido pode persistir após a libertação da memória e ser usado pelo pedido seguinte no mesmo worker.
Ler mais →CVE-2026-115560: aviso sobre o session upload progress
A CVE-2026-115560 é um aviso do php.net de 23/10/2026: possível execução de código apenas numa configuração de sessão invulgar. Solução até à próxima versão: session.upload_progress.enabled=0.
Ler mais →Que versões do PHP estão afetadas?
O PHP2Shell está corrigido no PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Para o PHP 8.1 e anteriores já não existem atualizações oficiais. A tabela mostra o estado por ramo.
Ler mais →Verificar corretamente a versão do PHP e o nível de patch
A versão do PHP apresentada, por si só, não diz se o PHP2Shell está fechado. O decisivo são o estado do pacote, os backports e se os processos novos estão realmente em execução.
Ler mais →Para a sua plataforma e o seu servidor
Onde se esconde o código malicioso no WordPress, no Shopware ou no TYPO3 e como aplicar realmente o patch em Plesk, cPanel ou num contentor.
Plataformas
Servidores e alojamento
Cada setor tem dados diferentes a perder
Dados de saúde, segredo profissional, dados de pagamento: orientamos a verificação e o relatório de acordo com as suas obrigações.
10 passos antes de assumirmos o caso
Marque o que já está feito. A lista fica guardada no seu navegador.
As marcações são guardadas apenas no seu navegador.
72 horas, NIS2, seguro
Orientação geral para a administração. Não constitui aconselhamento jurídico.
Dever de notificação segundo o RGPD: 72 horas após o incidente
Depois de um ataque a um servidor web, pode existir o dever de notificar a autoridade de controlo. Aqui explica-se, em termos gerais, quando começam as 72 horas e o que faz parte.
Ler mais →NIS2 e segurança dos servidores web
A NIS2 obriga muitas empresas a gerir riscos e a notificar incidentes. Aqui explica-se, em termos gerais, o que isso significa para os servidores web e onde encontrar informações fiáveis.
Ler mais →Seguro ciber: o que conta em caso de sinistro
Num ataque, a informação precoce à seguradora, as provas preservadas e passos combinados decidem muitas vezes a prestação. Aqui explicam-se, em termos gerais, os pontos típicos.
Ler mais →Responsabilidade da gerência por vulnerabilidades de segurança informática
A segurança informática é tarefa da direção. Aqui explicam-se, em termos gerais, os deveres de diligência e como os gerentes tomam decisões comprováveis perante vulnerabilidades como o PHP2Shell.
Ler mais →Artigos técnicos para administradores e programadores
Cronologia do PHP2Shell: de 17 a 25 de outubro de 2026
Todas as datas comprovadas do PHP2Shell numa só vista, da primeira tentativa de ataque observada até ao estado de 25/10/2026, e o que daí decorre para a sua verificação.
Ler mais →Confirmação da atualização PHP do alojamento: como perguntar pelo estado do patch
Após o PHP2Shell, a versão do PHP apresentada prova pouco. Com este modelo, pede ao seu fornecedor de alojamento uma confirmação que pode documentar.
Ler mais →Detetar e remover uma webshell
Como encontrar backdoors em servidores web PHP sem destruir vestígios, e porque é que apagar raramente basta.
Ler mais →Encontrar backdoor no WordPress: detetar backdoors de forma sistemática
Onde as backdoors se escondem tipicamente no WordPress e como os administradores as detetam de forma sistemática com o WP-CLI e poucos comandos.
Ler mais →Configurar o php.ini com segurança
Que definições do php.ini reduzem a superfície de ataque, como as proteger contra substituição e o que se aplica adicionalmente após o PHP2Shell.
Ler mais →Usar corretamente o PHP disable_functions
Com o disable_functions bloqueia funções PHP arriscadas. Como definir a lista de acordo com a sua aplicação sem paralisar o site.
Ler mais →Situação, instruções, apoio à decisão
Do nível de alerta do BSI aos registos de alterações dos pacotes, até à questão de reinstalar ou limpar. Cada artigo com fontes.
PHP2Shell: o que está comprovado e o que não está
Uma verificação de factos sobre o PHP2Shell: que afirmações vêm de fontes primárias, quais vêm de notícias dos media e que alegações não se sustentam.
Ler mais →Alterar a versão do PHP na área de cliente do alojamento
Como mudar a versão do PHP na área de cliente do seu fornecedor de alojamento, que versão escolher e o que verificar antes e depois.
Ler mais →Sinal de alerta: o servidor web inicia uma shell
Se um processo PHP-FPM ou do servidor web inicia uma shell, é um dos sinais de alerta mais fortes de uma intrusão. Como verificar a árvore de processos, enquadrar as exceções e vigiar o padrão de forma duradoura.
Ler mais →Isolar pools PHP-FPM por site
Um pool próprio por site é o início, não o fim. Como verificar os pools existentes e reforçar sockets, extensões, páginas de estado, recursos e registos.
Ler mais →Guardar palavras-passe em PHP com segurança: usar corretamente o password_hash
Como os programadores guardam palavras-passe em PHP com password_hash e password_verify, escolhem o procedimento adequado e substituem hashes MD5 ou SHA-1 antigos sem repor a palavra-passe de todos os utilizadores.
Ler mais →Contratos com prestadores de serviços de TI: regular com clareza as obrigações de segurança
O PHP2Shell mostrou como é muitas vezes pouco claro quem tem de aplicar os patches. Que obrigações de segurança devem constar dos contratos com agência, fornecedor de alojamento e prestador de TI.
Ler mais →A linguagem de programação PHP, explicada de forma clara
Como o PHP gera uma página, o que são SAPI, PHP-FPM e OPcache e porque é precisamente isso que decide a segurança. Inclui ainda um glossário com todos os termos técnicos.
O que é o PHP2Shell?
PHP2Shell designa duas vulnerabilidades críticas no próprio PHP (CVE-2026-109618 e CVE-2026-109619, CVSS 9,2). Podem permitir que atacantes executem código malicioso no servidor sem autenticação. Existem patches desde 21/10/2026.
Que versões do PHP são seguras?
As correções estão incluídas no PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Os fornecedores de alojamento e as distribuições aplicam por vezes backports sem alterar o número da versão. O que conta é o estado do pacote ou a confirmação escrita do fornecedor.
Basta uma atualização do WordPress ou da loja?
Não. A vulnerabilidade está no PHP, não no CMS. Uma atualização do CMS não a corrige. E um patch do PHP não remove código malicioso que já tenha sido introduzido antes.
Com que rapidez podem ajudar?
Trabalhamos remotamente e começamos assim que os acessos estiverem disponíveis. Envie-nos por WhatsApp o sistema, a versão do PHP e o que observou. Depois esclarecemos diretamente como proceder.
Trabalham também para agências e clientes de fornecedores de alojamento?
Sim. Trabalhamos diretamente para empresas, nos bastidores por conta de agências e em articulação com o seu fornecedor de alojamento, quando é este que gere o servidor.
Temos de notificar o incidente?
Se puderem estar em causa dados pessoais, aplica-se em regra, nos termos do Art. 33 do RGPD, um prazo de notificação de 72 horas a contar do conhecimento. Se se aplica no seu caso, esclareça-o com o seu encarregado da proteção de dados. Nós fornecemos a documentação técnica para esse efeito.
Cada hora conta. Escreva-nos agora.
Descreva brevemente o sistema, a versão do PHP e o que observou. Entramos em contacto consigo, esclarecemos a situação e trabalhamos remotamente até o incidente estar concluído e documentado.