# Perguntas frequentes sobre o PHP2Shell e a assistência de emergência

> Respostas a perguntas frequentes sobre o PHP2Shell e a assistência de emergência remota.

Fonte: https://phpsos.de/pt/faq/  
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

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

## O PHP2Shell é uma vulnerabilidade do WordPress?

Não. As vulnerabilidades estão no PHP, ou seja, na linguagem de programação em que correm o WordPress, o Shopware, o TYPO3 e muitos outros sistemas. Uma atualização do CMS não as corrige, por isso. O decisivo é o nível do PHP no servidor.

## Como cliente de um fornecedor de alojamento, tenho de fazer alguma coisa?

No alojamento partilhado, é em regra o fornecedor que instala a atualização do PHP. Deve, ainda assim, pedir confirmação por escrito de que a versão do PHP que utiliza tem o patch aplicado e foi reiniciada. Se algo aconteceu antes do patch, a atualização não o esclarece.

## De onde vem o nome PHP2Shell?

O nome descreve a consequência: através do PHP, um atacante pode, na pior das hipóteses, obter uma linha de comandos, ou seja, uma shell, no servidor. As designações oficiais são os números CVE-2026-109618 e CVE-2026-109619.

## O meu site já foi atacado se foi colocado offline?

Não necessariamente. Alguns fornecedores desligaram sites da rede por precaução, como recomenda o BSI (Gabinete Federal Alemão para a Segurança da Informação) quando uma atualização não é possível de imediato. É uma medida de proteção e não uma prova de um ataque.

## Basta o meu fornecedor de alojamento ter atualizado o PHP?

Pode bastar, se o fornecedor confirmar por escrito o estado do pacote e todos os processos PHP tiverem sido reiniciados. O número de versão apresentado, por si só, não é prova, porque as distribuições aplicam backports. Se o servidor já tinha sido atacado antes, um patch não o esclarece, de qualquer modo.

## O meu site tem de ficar offline para a ajuda imediata?

Não necessariamente. O BSI (Gabinete Federal Alemão para a Segurança da Informação) recomenda desligar temporariamente os servidores web da rede quando a atualização não for possível de imediato. Se isso é necessário no seu caso, decidimos em conjunto depois do levantamento.

## Uma atualização do WordPress ou do Shopware protege contra o PHP2Shell?

Não. O PHP2Shell está no próprio PHP, não no CMS. Uma atualização do CMS continua a fazer sentido, mas não corrige esta vulnerabilidade.

## O que acontece com o PHP 8.1 ou anterior?

Para estas versões já não existem atualizações oficiais do projeto PHP, apenas backports mínimos do código-fonte para 7.4, 8.0 e 8.1. Protegemos o servidor a título provisório e planeamos consigo a mudança para uma versão suportada.

## Quando começam a contar as 72 horas?

Segundo o Art. 33 do RGPD, a partir do momento em que o responsável pelo tratamento tomou conhecimento da violação. Quando isso se deve considerar verificado num caso concreto é uma avaliação jurídica. Documente por isso com exatidão quando é que quem teve que informação.

## É preciso notificar todas as vulnerabilidades de segurança?

Não. Uma vulnerabilidade, por si só, ainda não é uma violação da proteção de dados pessoais. A notificação pode tornar-se obrigatória quando existem indícios de que pessoas não autorizadas tiveram ou puderam ter acesso a esses dados e daí resulta um risco para os titulares.

## E se, passadas 72 horas, ainda não souber tudo?

O Art. 33, n.º 4, do RGPD permite fornecer as informações por fases, quando não for possível prestá-las todas ao mesmo tempo. Uma notificação tardia tem de ser fundamentada. Esperar por total clareza não é, por isso, em regra, motivo para deixar o prazo expirar.

## Quem notifica, se o fornecedor de alojamento foi afetado?

O dever de notificação cabe ao responsável pelo tratamento, ou seja, em regra a empresa que opera o site. Um subcontratante, como o fornecedor de alojamento, tem de informar o responsável sem demora injustificada, nos termos do Art. 33, n.º 2, do RGPD.

## Onde notifico uma violação de dados?

À autoridade de controlo competente em matéria de proteção de dados; no caso das empresas, em regra a autoridade do estado federado alemão em que têm sede. A maioria das autoridades disponibiliza formulários em linha para o efeito.