Alerta de segurança do PHP: o que os proprietários de servidores domésticos e NAS precisam de saber

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Se executar aplicações baseadas em PHP num servidor doméstico ou NAS, identifique o ambiente de execução efetivamente utilizado por cada aplicação e aplique a atualização de segurança indicada pelo fornecedor. As divulgações de falhas críticas do PHP exigem medidas nas implementações afetadas; ter o hardware não atualiza automaticamente o software dentro de uma aplicação ou contentor.

Mantenha cópias de segurança dos dados e da configuração da aplicação que possam ser recuperados, atualize o pacote ou a imagem corretos e verifique o serviço substituto. Consulte o aviso do responsável pela manutenção ou da distribuição para ter em conta os ramos afetados e as correções incorporadas em versões anteriores, em vez de se basear apenas na versão de PHP da linha de comandos do anfitrião.

O que aconteceu no incidente de segurança do PHP?

O projeto PHP lançou atualizações de segurança a 21 de outubro de 2026. Os seus anúncios de lançamento e dois avisos sobre o ambiente de execução descrevem falhas que podem permitir a execução remota de código. A sua gravidade justifica verificar uma pequena instalação doméstica, mesmo que sirva apenas algumas pessoas.

  • CVE-2026-109618 diz respeito a um estado de memória inválido após o tratamento de uma situação de falta de memória interromper o processamento do pedido.
  • CVE-2026-109619 diz respeito ao estado relacionado com pedidos que é retido depois de a memória subjacente ter sido libertada e posteriormente acedido por um processo de trabalho.

Estas falhas afetam o ambiente de execução. Atualizar um tema ou instalar um plugin de uma aplicação não prova que o PHP subjacente tenha sido corrigido. Os avisos distinguem as interfaces e configurações do servidor; não se deve presumir que a exploração seja igualmente viável em todas as implementações.

Que versões do PHP incluem as correções?

As versões de emergência indicadas pelo PHP são:

Ramo do PHP Versão de segurança
8.2 8.2.35
8.3 8.3.36
8.4 8.4.27
8.5 8.5.12

Utilize estas versões ou uma versão posterior compatível no mesmo ramo com suporte. Os fornecedores de distribuições podem incluir correções em versões anteriores, mantendo uma cadeia de versão aparentemente mais antiga: confirme se o pacote instalado corresponde ao aviso de segurança desse fornecedor. Para ramos que chegaram ao fim da vida útil, passe para um ambiente de execução com suporte ou obtenha confirmação explícita de que o fornecedor mantém uma correção. Não presuma que uma instalação sem suporte está protegida.

Isto afeta o seu NAS ou servidor doméstico?

Comece por fazer um inventário das aplicações. Um site WordPress, uma instalação do Nextcloud ou outra ferramenta baseada em PHP merece ser analisada; o nome, por si só, não prova que a instalação atual seja vulnerável. Verifique o ambiente de execução efetivamente incluído no pacote ou contentor. Por outro lado, uma aplicação que não seja baseada em PHP não deve ser considerada afetada apenas por funcionar no mesmo dispositivo.

Mapeie cada serviço relevante ao longo de três fronteiras:

  • Acessibilidade: encaminhamento do router, IPv6 público, proxies inversos, túneis e controlos de acesso.
  • Execução: o serviço PHP, a imagem do contentor, a origem do pacote e os processos de trabalho em execução.
  • Permissões: montagens de armazenamento com permissão de escrita, acesso à base de dados, segredos e privilégios administrativos.

Este esquema ajuda a dar prioridade às atualizações e a compreender as potenciais consequências do comprometimento de uma aplicação. Um proxy inverso que encaminha pedidos públicos para PHP não elimina automaticamente a exposição. Uma via de acesso exclusiva através de VPN pode reduzir a exposição pública quando está corretamente configurada, mas não corrige um ambiente de execução vulnerável.

O que devem fazer primeiro os proprietários?

1. Restringir o acesso se não for possível aplicar uma correção imediatamente

A CERT-EU recomenda a aplicação imediata de correções e que se considere isolar as aplicações acessíveis a partir da Internet quando isso não for viável. Reveja todas as vias de acesso à aplicação, incluindo túneis e IPv6, antes de considerar que a remoção de um redirecionamento de portas garante o isolamento. Mantenha disponível um método de acesso fiável para manutenção.

2. Preservar as opções de recuperação

Antes de alterar uma pilha de aplicações, preserve a configuração, os dados persistentes e uma cópia de segurança consistente da base de dados. Registe a etiqueta da imagem ou a versão do pacote atual. Mantenha uma cópia de segurança independente que a aplicação Web não possa substituir. Um instantâneo ou uma matriz RAID, por si só, não garante que consiga recuperar de um comprometimento ao nível da aplicação.

3. Atualizar o componente que contém efetivamente o PHP

No caso de um pacote NAS gerido pelo fornecedor, siga o aviso do responsável pela manutenção do pacote. Numa implementação com contentores, obtenha uma imagem da aplicação corrigida ou reconstrua a sua imagem personalizada com uma imagem de base PHP corrigida e, em seguida, recrie o serviço afetado, preservando os volumes documentados. A atualização do anfitrião não atualiza necessariamente o PHP dentro dos contentores. Reiniciar um contentor antigo não instala uma imagem nova.

As orientações de resposta da Google Cloud também salientam a importância de reconstruir e voltar a implementar imagens de contentores geridas pelo cliente com um ambiente de execução corrigido. Verifique cada implementação que utiliza a imagem, em vez de atualizar apenas um modelo para futuras instalações.

4. Verificar o serviço em execução

Uma verificação da versão no terminal é uma pista útil, mas o binário da linha de comandos pode ser diferente do utilizado pelo processo de trabalho Web. Confirme o ambiente de execução em cada contentor ou serviço relevante e certifique-se de que os processos de trabalho antigos foram substituídos. Não deixe uma página de diagnóstico pública online. Em seguida, teste o início de sessão, os carregamentos, as tarefas em segundo plano e o acesso aos ficheiros através das funções normais da aplicação.

O aviso do Laravel Forge também destaca os processos de longa duração: uma atualização bem-sucedida do pacote não substitui todos os processos que já estão a executar PHP. Utilize o procedimento de reinício documentado pela aplicação.

O que significa isto para uma nuvem pessoal ZimaCube 2?

O ZimaCube 2 oferece uma plataforma para armazenamento privado e aplicações alojadas por si. Se o utilizar para executar aplicações, considere as atualizações das aplicações, o acesso à rede e as permissões de armazenamento como parte da gestão dessa nuvem pessoal.

Este artigo não determina que o ZimaOS ou uma instalação específica do ZimaCube 2 estejam afetados. Verifique cada aplicação instalada e o respetivo ambiente de execução. A expansão de hardware e a capacidade de armazenamento são aspetos distintos da aplicação de correções ao software.

Uma prática operacional útil consiste em conceder a cada aplicação apenas acesso às pastas e permissões de que necessita, documentar a origem das atualizações e guardar uma cópia de recuperação fora do alcance de escrita da aplicação. Assim, será mais fácil avaliar futuros avisos de segurança sem interromper todos os serviços do dispositivo.

Perguntas frequentes

Alterar a minha palavra-passe corrige estas vulnerabilidades do PHP?

Não. Instale um ambiente de execução corrigido. A alteração das palavras-passe pode fazer parte da recuperação de um incidente, mas não substitui a atualização do PHP.

É seguro ignorar uma aplicação PHP acessível apenas pela rede local?

Não. A acessibilidade limitada reduz a exposição, mas outros dispositivos ou utilizadores nessa rede poderão continuar a aceder-lhe. Mantenha o software suportado atualizado.

A instalação da correção prova que o servidor nunca foi comprometido?

Não. A aplicação de correções resolve a vulnerabilidade para o futuro. Se suspeitar de uma intrusão, isole o serviço, preserve os registos relevantes e investigue antes de restabelecer o acesso. Reveja as credenciais expostas a partir de um sistema de confiança e, quando se justificar, reconstrua o serviço a partir de imagens de confiança.

A prioridade imediata: identifique os serviços que usam PHP, restrinja os acessos desnecessários, aplique a correção relevante do fornecedor e verifique o ambiente de execução que processa os pedidos reais.

Fontes e âmbito das atualizações

Verificado em 22 de outubro de 2026. Esta é uma visão geral preventiva, não uma confirmação de comprometimento nem um aviso de vulnerabilidade específico de um produto. Os avisos dos fornecedores podem mudar à medida que a investigação prossegue.

Explore a série sobre segurança do PHP

Escolha um guia para o próximo passo na manutenção do seu servidor doméstico:

Centro de Tecnologia e IA

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.