O seu WordPress está atualizado. Mas quem confirmou que o PHP do alojamento também está corrigido?
A pergunta ganhou urgência com as correções de segurança publicadas pelo projeto PHP em 21 de outubro de 2026. O aviso oficial do WordPress esclarece uma diferença decisiva: estas falhas pertencem ao PHP, não ao WordPress, e não há uma atualização do WordPress destinada a resolvê-las. Carregar em «Atualizar» no painel do site não substitui a intervenção no alojamento. (wordpress.org)
Em Portugal, a Host TugaTech anunciou uma resposta que ajuda a perceber onde começa a responsabilidade de cada interveniente. Para serviços geridos, assumiu a aplicação das correções; para servidores não geridos, atribuiu essa tarefa ao administrador do servidor. A distinção consta do comunicado de 20 de outubro, posteriormente atualizado. (clientes.host.tugatech.com.pt)
Para o seu negócio, a decisão não é escolher uma versão de PHP por tentativa. É identificar quem intervém, que confirmação deve entregar e quem verifica o funcionamento do website depois.
Uma decisão de alojamento com consequências para o site
No plano anunciado, a Host TugaTech incluiu alojamento partilhado, revenda e servidores com gestão ativa na intervenção da sua equipa. Para VPS e servidores dedicados não geridos, indicou que a atualização cabia a quem administra o sistema. Numa atualização do comunicado, informou também que tinha iniciado a implementação de regras de proteção na firewall de aplicações e que as atualizações completas dos pacotes de PHP decorreriam nas horas seguintes. (clientes.host.tugatech.com.pt)
Há um limite importante: esse comunicado descreve medidas iniciadas e previstas; não comprova que um website específico já ficou corrigido. A atualização do texto não apresenta uma data própria nem uma confirmação individual por serviço. (clientes.host.tugatech.com.pt)
Não se deve, por isso, transformar «o fornecedor está a tratar» em «o nosso site está resolvido». A nossa recomendação é encerrar o assunto apenas quando houver uma resposta associada ao serviço concreto da empresa.
Este caso também não permite concluir que outros alojamentos seguem o mesmo modelo. Use-o para esclarecer o seu contrato, não para presumir o que está incluído nele.
PHP: a parte que não se atualiza no painel do WordPress
O PHP é uma das linguagens em que o WordPress assenta. O alojamento determina as versões disponíveis e pode disponibilizar um seletor para alterar a versão usada pelo website. Isso é diferente de atualizar os ficheiros do WordPress, os temas ou os plugins. (wordpress.org)
Uma analogia simples: atualizar o WordPress é intervir no equipamento que utiliza; corrigir o PHP é intervir numa parte do sistema que o faz funcionar. As duas tarefas estão relacionadas, mas não são a mesma operação.
O aviso de 21 de outubro identifica duas vulnerabilidades, CVE-2026-109618 e CVE-2026-109619, que podem permitir execução remota de código sem autenticação. As versões publicadas para as corrigir foram PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. O projeto recomenda atualização imediata e indica que algumas distribuições e fornecedores de suporte prolongado disponibilizam correções nos seus próprios pacotes. (php.net)
Isto significa que a resposta «temos PHP 8» é insuficiente. É preciso identificar a versão completa e, quando se trata de um pacote corrigido pelo fornecedor, a referência que comprova essa correção. Não rejeite nem aceite um pacote apenas pelo número visível: confirme a documentação aplicável. (php.net)
Quem deve assumir cada parte da intervenção?
Propomos separar a execução técnica da confirmação funcional. Uma pessoa pode coordenar ambas, mas as duas responsabilidades devem ficar explícitas.
A tabela seguinte é um instrumento para organizar essa conversa, não uma descrição universal dos contratos de alojamento.
| Situação do seu negócio | Responsabilidade a confirmar | Resultado que deve ficar registado |
|---|---|---|
| Alojamento partilhado com gestão do PHP pelo fornecedor | Quem aplica os pacotes e confirma a versão usada pelo domínio | Resposta associada ao serviço, com correção aplicada e data |
| Servidor gerido | Se a gestão contratada abrange esta atualização e todos os ambientes relevantes | Âmbito da intervenção e eventuais exceções |
| VPS ou dedicado sem gestão | Nome da pessoa ou equipa que administra o sistema | Responsável identificado e execução confirmada |
| Agência mantém o WordPress, outra empresa gere o servidor | Quem coordena a intervenção e quem valida o website | Uma sequência acordada, sem tarefas por atribuir |
| Ninguém consegue identificar quem gere o PHP | Quem tem acesso e capacidade para assumir a intervenção | Atribuição urgente da responsabilidade, antes de considerar o assunto resolvido |
A pergunta mais útil para começar é: «O vosso serviço inclui aplicar esta correção ao PHP que executa o nosso domínio, ou apenas disponibilizar uma versão corrigida?»
Depois, escolha uma pessoa para acompanhar o assunto até ao fim. Evite uma troca de mensagens em que cada fornecedor responde apenas pela sua parte e ninguém confirma o resultado conjunto.
Num exemplo hipotético, uma empresa de formação contrata uma agência para manter o WordPress, mas conserva um VPS administrado por um antigo prestador. A agência pode confirmar que o site está atualizado sem ter acesso ao sistema operativo. A primeira decisão da direção deve ser atribuir a gestão do servidor, não contratar outra atualização de plugins.
«Protegido pela firewall» não significa «corrigido»
Uma proteção temporária pode fazer parte da resposta, mas não deve ser confundida com o encerramento da intervenção. O NCSC dos Países Baixos explica que as medidas de mitigação disponíveis limitam determinados caminhos de ataque e não substituem a instalação da atualização de segurança. (ncsc.nl)
Para acompanhar o caso, sugerimos estes estados internos:
- Por confirmar: ainda não existe evidência sobre o serviço usado pelo website.
- Mitigado temporariamente: há uma medida identificada, mas a atualização continua pendente.
- Corrigido, por validar: a intervenção no PHP foi confirmada; falta verificar o funcionamento do website.
- Concluído: a correção e a validação funcional estão documentadas, sem pendências conhecidas dentro do âmbito acordado.
São rótulos de trabalho, não garantias absolutas de segurança. Servem para impedir que uma mensagem vaga encerre uma tarefa incompleta.
Se a atualização imediata não for possível, a decisão sobre restringir ou suspender o acesso deve ser tomada com a equipa técnica. O aviso do WordPress remete para orientações de autoridades de cibersegurança que admitem retirar sistemas de funcionamento quando não é possível resolver ou mitigar adequadamente a exposição. Não é uma decisão para adiar até aparecerem sintomas no site. (wordpress.org)
A verificação tem de considerar os avisos posteriores
A informação não terminou no lançamento de 21 de outubro. Em 23 de outubro, o projeto PHP publicou uma orientação adicional sobre uma combinação pouco habitual de configuração e código relacionada com o progresso de carregamento de ficheiros em sessões. Recomendou desativar essa funcionalidade nas condições indicadas enquanto se aguarda a correção prevista. (php.net)
O responsável da empresa não precisa de interpretar esses parâmetros. Precisa de incluir uma pergunta na confirmação técnica: «Foram considerados os avisos posteriores ao pacote inicialmente instalado que se aplicam ao nosso ambiente?»
Esta pergunta evita tratar uma lista de versões como um certificado permanente. Também mantém a decisão no lugar certo: quem administra o servidor avalia a configuração; quem dirige o negócio acompanha a resolução.
Uma mensagem para obter uma resposta utilizável
Pode adaptar o seguinte pedido e enviá-lo em conjunto ao alojamento e à equipa de manutenção:
> Precisamos de confirmar o estado do PHP que executa o domínio [domínio]. Indiquem quem é responsável pela intervenção, qual a versão ou pacote corrigido em utilização e quando foi aplicado. Confirmem também se existe alguma mitigação temporária, pendência ou aviso posterior aplicável. A equipa responsável pelo WordPress deverá indicar quem verifica o funcionamento do website após a intervenção.
Antes de enviar, acrescente os subdomínios ou outros websites que também quer incluir. Não deixe que «o nosso site» seja interpretado de formas diferentes pelos intervenientes.
No WordPress, a versão de PHP pode ser consultada em Ferramentas → Saúde do site → Informação → Servidor. Essa informação ajuda a formular o pedido, mas deve ser confrontada com a confirmação do alojamento, sobretudo quando existem pacotes corrigidos pelo fornecedor. (wordpress.org)
Para a validação funcional, escolha tarefas reais do seu negócio. No exemplo hipotético da empresa de formação, seriam consultar uma formação, concluir uma inscrição de teste e confirmar o respetivo registo. Não é necessário transformar esta intervenção numa revisão completa do website; é necessário verificar o percurso que não pode ficar interrompido.
O que aprovar se houver trabalho adicional
Se surgir uma proposta de intervenção, peça que separe a correção do servidor, a eventual resolução de incompatibilidades e a validação do website. Alterar a versão de PHP pode exigir verificar temas e plugins; a documentação do WordPress recomenda avaliar essa compatibilidade antes da mudança. (wordpress.org)
A nossa recomendação é não aprovar uma «atualização geral» sem saber qual destas tarefas está incluída. Também não há razão para decidir já uma mudança de alojamento apenas porque recebeu um alerta: primeiro, apure se o fornecedor consegue corrigir o ambiente e demonstrar o que fez.
Se ninguém assume a gestão do PHP, existe uma lacuna concreta no serviço de manutenção. Resolver essa lacuna pode exigir coordenação entre prestadores ou contratação de gestão técnica adicional. O resultado a procurar é simples: um responsável identificado, uma correção comprovada e um website cujo funcionamento foi verificado — não apenas mais uma mensagem a dizer que está tudo atualizado.