Vulnerabilidade de segurança do PHP 2026: como verificar e aplicar correções aos serviços web em risco

Interpretar corretamente o aviso de alarme

A afirmação de que uma falha de segurança no PHP poderia afetar „metade da Internet“ é um argumento sensacionalista, mas não constitui uma estimativa comprovada. Não há provas de que metade de todos os serviços da Internet esteja vulnerável ou já tenha sido comprometida. O risco real é, no entanto, considerável, uma vez que o PHP é utilizado como ambiente de execução em muitos sites, lojas online, APIs e interfaces de gestão.

O que é decisivo não é se um site utiliza PHP, mas sim qual a versão do PHP que processa os seus pedidos web. As atualizações de segurança de 21 de outubro de 2026 afetam, em princípio, as instalações sem patches das ramificações suportadas, desde que estas processem pedidos através de um serviço web. Por conseguinte, um PHP local destinado a tarefas de desenvolvimento deve ser avaliado de forma diferente de um portal de clientes acessível a partir do exterior.

O Visibilidade na Internet A urgência é um fator determinante. Uma loja acessível ao público, com formulários e funcionalidades de upload, oferece mais pontos de contacto potenciais do que um serviço interno isolado. No entanto, nem mesmo um serviço interno é automaticamente seguro: acessos via VPN, contas comprometidas ou outros sistemas na rede podem torná-lo acessível. Por isso, o alcance, por si só, não substitui uma avaliação técnica dos riscos.

Igualmente importantes são o modo de funcionamento e Suporte para remendos. O PHP pode ser executado, por exemplo, através do PHP-FPM, como módulo do Apache, via php-cgi ou incorporado num produto. Vários domínios no mesmo servidor podem, neste contexto, ter versões e métodos de atualização diferentes. Uma declaração genérica de que todos os sites PHP estão a salvo seria tão errada quanto a suposição de que todas as instalações estão imediatamente vulneráveis a ataques.

O que as vulnerabilidades do PHP permitem, do ponto de vista técnico

A Execução remota de código (RCE) significa que, em determinadas condições, um atacante pode executar código num sistema remoto. De acordo com o comunicado de segurança, estas vulnerabilidades do PHP não requerem autenticação prévia. O código seria inicialmente executado com os direitos do processo web, e não automaticamente com direitos de administrador ilimitados. As possíveis consequências dependem, portanto, em grande medida dos direitos de acesso aos ficheiros, dos dados de acesso e da segregação do servidor.

A vulnerabilidade CVE-2026-109618 diz respeito a falhas de segurança em Escassez de espaço de armazenamento. Se o PHP interromper uma solicitação devido a uma situação de falta de memória, as estruturas de dados internas podem ficar incompletas. Se essas estruturas forem reutilizadas durante a limpeza da solicitação, pode ocorrer danificação da memória. A descrição oficial refere, em particular, as solicitações multiparte, os uploads de ficheiros e o consumo de memória durante a análise de entradas aninhadas como contextos técnicos relevantes.

Por outro lado, a CVE-2026-109619 diz respeito a um estado interno associado a um pedido, cuja memória já tinha sido libertada. Se, posteriormente, um worker reutilizado processar outro pedido, o PHP pode aceder a esse estado desatualizado antes de a inicialização normal entrar em vigor. O comunicado de segurança refere, entre outros aspetos, o progresso do upload de sessões e os percursos de erro. Isto descreve a classe de erros, não constitui um guia para a exploração.

• Podem ser afetadas as solicitações Web através do PHP-FPM, do Apache com mod_php, do php-cgi, do FrankenPHP e do LiteSpeed.
• Os erros ocorrem no ambiente de execução do PHP, e não principalmente no WordPress, no Joomla, no Shopware, nos temas ou em plugins específicos.
• Os CMS e as estruturas influenciam as funcionalidades disponíveis, como os uploads, mas não substituem uma atualização do interpretador.

Por que razão nem todas as instalações correm o mesmo risco

O facto de um serviço estar efetivamente em risco depende de vários fatores. Têm prioridade um ambiente de execução PHP na Web sem patches e um serviço Web acessível. Seguem-se o modo de funcionamento, os processos reutilizados, as funcionalidades para uploads ou formulários complexos, bem como os direitos da conta do processo Web. Um serviço com acesso de escrita abrangente a ficheiros web ou acesso a outros serviços pode ter consequências mais graves do que um projeto estritamente isolado.

No Apache com mod_php O projeto PHP destaca especialmente esta questão de risco: um ataque documentado pode ser desencadeado antes mesmo da execução do código da aplicação propriamente dito. Um CMS bem mantido não protege, então, contra a vulnerabilidade em tempo de execução. Isso não significa que o PHP-FPM, o php-cgi, o FrankenPHP ou o LiteSpeed sejam considerados inofensivos; caso não tenham sido atualizados, devem também ser verificados com prioridade.

Além disso, os produtos com PHP incorporado. Isso pode incluir imagens de contentores, dispositivos pré-configurados, sistemas de gestão de NAS ou produtos de rede cuja interface utilize PHP internamente. Nesses casos, um comando executado no anfitrião muitas vezes não indica o tempo de execução efetivamente utilizado. A atualização do sistema operativo também não corrige automaticamente um componente PHP vulnerável numa imagem ou num produto do fabricante.

Uma firewall, uma firewall de aplicações web ou limites restritivos de upload podem dificultar as solicitações individuais e limitar a superfície de ataque. No entanto, não substituem a correção, uma vez que não corrigem a gestão defeituosa da memória e do estado no interpretador. Mesmo um CMS sem erros depende de um ambiente de execução seguro. Por isso, é fundamental verificar e atualizar o nível de patches do PHP que efetivamente processa as solicitações Web.

Comparar o estado de atualizações e o estado do suporte

No que diz respeito a estas duas falhas de segurança, o que importa, em primeiro lugar, é o estado das correções na ramificação do PHP utilizada. O projeto PHP indica versões corrigidas específicas para as séries suportadas. As versões anteriores da mesma série são consideradas afetadas; a atualização para a versão indicada ou para uma versão mais recente desta ramificação constitui a solução completa prevista.

A Atualização de patch mantém-se na mesma linha de desenvolvimento, por exemplo, da versão 8.3.35 para a 8.3.36. Destina-se a disponibilizar a correção de segurança e tem um âmbito de compatibilidade mais restrito do que uma mudança da versão 8.2 para a 8.4. Esta última é uma migração: as dependências, as extensões, o código da aplicação e, se for caso disso, a implementação têm de ser verificados separadamente para esse efeito.

O PHP 8.2 continua a poder ser utilizado para a correção imediata, desde que esteja a ser executada, pelo menos, a versão 8.2.35. No entanto, esta ramificação chegará ao fim do suporte a 31 de dezembro de 2026. Por isso, a operação não deve ficar limitada a esta versão de atualização imediata: planeie a migração para uma ramificação com suporte mais prolongado, após ter verificado a compatibilidade da aplicação num ambiente adequado.

No caso do PHP 8.1 e versões anteriores, é necessário ter um cuidado especial. O projeto PHP não disponibiliza nenhuma versão regular e atualizada para este fim; os backports mínimos do código-fonte não são equivalentes a um pacote mantido e disponível ao público em geral. Um backport de segurança documentado pelo fornecedor do sistema operativo pode ser adequado, mas requer comprovação no aviso de segurança ou no registo de alterações do pacote. Na ausência dessa comprovação, é necessária uma migração, em vez de uma mera atualização cosmética da versão.

Verificar o tempo de execução real na Web

A verificação da versão começa com um levantamento da situação, mas não deve limitar-se ao shell. Num servidor autogerido, os comandos seguintes mostram a versão do comando PHP executado nesse servidor e os ficheiros de configuração encontrados por essa execução. Não alteram nem os pacotes nem a configuração, pelo que são adequados como primeiro passo de verificação, com baixo risco.

php -v
php --ini

A saída descreve apenas o comando que foi executado através deste comando da shell Tempo de execução da CLI. Por outro lado, um site pode ser executado através do PHP-FPM, do Apache com o mod_php, do php-cgi ou de um contentor. Este ambiente de execução web pode utilizar uma versão diferente do PHP e ficheiros de configuração distintos dos utilizados pelo comando php -v no servidor. Para a avaliação de segurança, o processo determinante é aquele que processa os pedidos HTTP reais.

Na hospedagem gerida, deve, por isso, verificar no painel do cliente a versão de PHP selecionada por projeto ou domínio e, se necessário, consultar o estado das atualizações do serviço disponibilizado. No caso de vários domínios, cada atribuição deve ser verificada individualmente: um domínio principal pode já estar a utilizar a versão atualizada, enquanto uma loja online, uma instância de teste ou um subdomínio ainda utiliza um interpretador mais antigo.

Em servidores com PHP-FPM, a configuração do serviço, o conjunto de pacotes e a documentação de implementação devem ser considerados em conjunto. Em ambientes de contentores, deve verificar adicionalmente a imagem efetivamente implementada e não apenas um manifesto de compilação local. O que é determinante é qual a revisão que aceita os pedidos Web no pod ou contentor em execução; uma imagem base atualizada não protege uma instância mais antiga que já esteja em execução.

Planear os percursos de atualização de acordo com o modo de funcionamento

A forma adequada de atualização depende de quem fornece o interpretador e do local onde este é executado. Só quando esta área de responsabilidade estiver clara é que se poderá decidir com fiabilidade se é necessária uma mudança de painel, uma atualização de pacote, uma nova imagem ou uma atualização do fabricante. A classificação que se segue distingue estes casos, sem equiparar os modos de funcionamento em termos de risco.

No caso do alojamento partilhado, o fornecedor deve disponibilizar o nível de patches de segurança para a versão do PHP selecionada; o operador verifica, em seguida, a aplicação. No caso do PHP-FPM ou do mod_php, a administração atualiza, normalmente, os pacotes e, em seguida, reinicia de forma controlada o serviço efetivamente responsável. Uma simples reinicialização sem a aplicação da correção não substitui a atualização.

As distribuições Linux disponibilizam frequentemente correções de segurança como Backport. Nesse caso, o número da versão do pacote visível pode diferir das versões publicadas no php.net, apesar de a correção estar incluída. Por isso, não se limite a comparar cadeias de caracteres como „8.4.26“, mas leia o comunicado de segurança e o registo de alterações do distribuidor. O projeto PHP salienta que as distribuições e os fornecedores de LTS podem receber patches.

Os contentores exigem um processo específico: compilar uma imagem corrigida ou obtê-la junto do fornecedor, implementá-la e substituir as instâncias antigas. No caso de interfaces NAS, dispositivos de rede ou aplicações web prontas a utilizar, a correção cabe, pelo contrário, ao fabricante do produto. Uma correção do sistema operativo do anfitrião não chega necessariamente ao interpretador incorporado; por isso, o inventário e as instruções do fabricante continuam a ser indispensáveis.

Medidas imediatas sem falsa sensação de segurança

No dia da atualização, começa por identificar o teu inventário: domínios, APIs, interfaces de gestão, contentores e produtos que possam ter PHP incorporado. Anota, para cada serviço, o modo de funcionamento na Web, o canal de atualização responsável e o runtime PHP efetivamente utilizado. Em seguida, cada serviço acessível ao público ou crítico para o negócio passa a ter prioridade, e não apenas o servidor com o número de versão mais evidente.

Em seguida, aplique a atualização de segurança disponibilizada pelo fornecedor de alojamento, distribuidor de Linux, criador da imagem ou fabricante do produto. Para as ramificações do PHP suportadas, a atualização para a versão corrigida do patch constitui a solução completa; um WAF, regras de upload ou o reinício do servidor web não a substituem. Planeie o processo de forma a que a atualização do pacote, da imagem ou do fabricante seja documentada de forma compreensível e possa ser rastreada em caso de problemas.

Após a atualização, é necessário todos os antigos trabalhadores devem ser encerrados e substituídos por processos que comprovadamente tenham carregado o tempo de execução corrigido. Utilize uma recarga apenas se a gestão de serviços específica garantir essa substituição completa; caso contrário, é necessária uma reinicialização controlada. Em seguida, verifica os tempos de início dos processos, o estado dos serviços ou o tempo de execução da Web determinado internamente, em vez de simplesmente assumir que a substituição ocorreu. No caso dos contentores, implementa a imagem corrigida e elimina todas as instâncias antigas.

Em seguida, verifique os principais fluxos de trabalho da aplicação, tais como o registo, os formulários, os uploads, o checkout e as APIs. Os testes revelam se a aplicação e as extensões funcionam com as atualizações de patches instaladas; no entanto, por si só, não comprovam nem a substituição completa dos workers nem a ausência de um comprometimento anterior. Estes aspetos devem ser avaliados separadamente através de auditorias operacionais e de segurança.

Caso não seja possível aplicar uma correção a curto prazo, algumas configurações podem limitar as vias de ataque conhecidas, mas não garantem uma segurança total. A desativação da barra de progresso do upload deve estar ativa antes da análise de uma solicitação. Verifique previamente se as aplicações ou interfaces necessitam desta indicação de progresso e, em seguida, reinicie todos os workers PHP relevantes. Verifique depois se nenhum processo antigo continua a funcionar com a configuração anterior.

session.upload_progress.enabled = 0

Limites conservadores para os dados POST e outras opções mencionadas no aviso de segurança também só conseguem reduzir parcialmente a superfície de ataque. Os dados lidos tardiamente .user.ini-ficheiros ou um ini_set() As medidas tomadas no âmbito da aplicação não são suficientes para esta configuração. Considera essas medidas como uma redução temporária do risco e mantém a atualização de segurança como objetivo.

É preciso distinguir isto da gestão normal das sessões guardadas. O artigo sobre a Recolha de resíduos de sessões PHP explica como a limpeza, os acessos aos ficheiros e os workers interagem durante o funcionamento normal. No entanto, esta otimização operacional não corrige as vulnerabilidades aqui abordadas e não substitui nem a versão corrigida do patch do PHP nem a subsequente substituição dos processos em execução.

Após a aplicação da atualização, verificar o funcionamento e detetar eventuais anomalias

Uma atualização de pacotes concluída com sucesso comprova, numa primeira fase, apenas que foram instalados ficheiros ou pacotes. Não confirma que o processo Web tenha carregado o novo ambiente de execução, nem que a aplicação funcione sem erros com o mesmo. Por isso, após o reinício, verifique o ambiente de execução Web relevante para o serviço e registe a hora, a versão, o serviço reiniciado e o resultado do teste de funcionamento.

O teste funcional deve abranger os principais fluxos de trabalho reais: páginas públicas importantes, início e fim de sessão, envio de formulários, carregamento de ficheiros, finalização de compra ou reserva, bem como pontos de extremidade da API e tarefas em segundo plano. Teste apenas as operações para as quais tenha autorização e, no caso de lojas em produção, utilize, sempre que possível, dados de teste específicos para esse fim. Verifique, em paralelo, os registos do servidor web, do PHP e da aplicação para detetar novos erros, falhas recorrentes ou códigos de estado inesperados.

É necessário um novo começo para criar processos sustentáveis e Trabalhador carregar com o código atualizado, mas não gera, por si só, uma correção. Sem a atualização instalada, a vulnerabilidade mantém-se. Em caso de elevada carga de trabalho, a janela de manutenção deve ser definida de forma a que as solicitações possam ser processadas de forma ordenada e os efeitos de um reinício do worker continuem a ser observáveis.

O impacto de um reinício controlado no rendimento depende do número e da carga dos processos PHP. Para efeitos de planeamento, é útil ter em conta as filas, as tarefas em execução e as transações críticas, em vez de encerrar processos de forma descoordenada. O guia Compreender os Workers do PHP explica o papel destes processos em consultas dinâmicas paralelas.

Se surgirem anomalias após a aplicação do patch, distinga entre erros de compatibilidade da aplicação e uma implementação incompleta. Compare a configuração, as extensões ativadas e o ambiente de execução web com o estado anterior à manutenção. Uma reversão não pode fazer com que um serviço acessível ao público permaneça permanentemente na versão vulnerável; nesse caso, defina rapidamente um percurso de atualização compatível e corrigido.

Dar prioridade às instalações antigas e ocultas do PHP

É necessário prestar especial atenção aos sistemas em que o PHP não é visível como um ambiente de execução instalado deliberadamente: imagens Docker, dispositivos virtuais, NAS e interfaces de rede, bem como produtos de software prontos a utilizar. Uma atualização do anfitrião não atualiza automaticamente nem uma imagem de contentor nem o ambiente de execução interno incluído num produto do fabricante. Por isso, deve solicitar especificamente aos fabricantes a sua avaliação e uma atualização de segurança para o produto em questão.

No caso das versões antigas, há três situações que devem ser claramente distinguidas. Uma versão do PHP com suporte regular recebe as atualizações de segurança publicadas pelo projeto PHP. Um backport de distribuição ou de fornecedor pode conter a correção, apesar de o número de versão visível ser diferente, mas tem de ser comprovado pelo comunicado de segurança ou pelo registo de alterações desse fornecedor. Por outro lado, o código-fonte mantido pelo próprio utilizador implica a responsabilidade pela compilação, teste e operação; não constitui um substituto equivalente a um canal de atualizações regular.

O PHP 8.1 e as ramificações mais antigas já não recebem lançamentos regulares do upstream. Embora exista uma versão corrigida disponível para o PHP 8.2, essa ramificação chegará ao fim do suporte no final de 2026. Utilize uma correção disponível para resolver a situação urgente, mas, no caso de versões antigas ou em fim de vida, planeie adicionalmente uma versão testada Migração para um ramo com suporte prolongado.

1. Atualize primeiro os serviços acessíveis ao público com o runtime do PHP sem patches, especialmente se houver funcionalidades de upload ou de gestão acessíveis.
2. Trate imediatamente o Apache com o mod_php e as lojas, APIs ou portais de clientes essenciais para o negócio; o comunicado oficial de segurança destaca um risco particularmente crítico relacionado com o mod_php.
3. Registar contentores, dispositivos e produtos de terceiros com base em imagens, inventário e estado do fabricante; a ausência de pacotes PHP visíveis não significa que não haja motivo de preocupação.
4. Isolar os serviços que não são suportados ou para os quais não é possível aplicar correções atempadamente e restringir o acesso, planeando, em paralelo e de forma obrigatória, a substituição, a atualização ou a migração.

A segmentação da rede, a obrigatoriedade de utilizar uma VPN ou regras de acesso restritivas podem permitir ganhar tempo quando as interfaces de gestão não podem ser corrigidas de imediato. No entanto, estas medidas são apenas Medidas transitórias, uma vez que as contas de utilizador internas, os dispositivos comprometidos e as partilhas mal configuradas podem continuar a constituir vias de ataque. Se não for disponibilizada uma correção para um produto ou se a ramificação do PHP estiver definitivamente fora do período de suporte, a substituição ou a migração constituem a decisão mais segura.