Perguntas frequentes

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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