PHP e Node.js: falhas de segurança exigem actualização dos serviços digitais
O Departamento de Tecnologias de Informação do ISPP-Kilamba explica o risco de cada falha, as versões corrigidas e a orientação adicional do PHP de 23 de Outubro.
Instituto Superior Politécnico Privado do Kilamba
Departamento de Tecnologias de Informação
Boletim de segurança · Fontes verificadas em 23 de Outubro de 2026
Um formulário que deixa de responder pode parecer apenas uma avaria. Mas, em determinadas versões do PHP, um pedido preparado para provocar uma falha de memória pode chegar à execução de código no servidor, mesmo sem iniciar sessão. No Node.js, há também uma falha que pode transformar a descompressão de dados numa porta de entrada. São problemas diferentes, com correcções já publicadas.
O Departamento de Tecnologias de Informação do Instituto Superior Politécnico Privado do Kilamba publica este alerta para ajudar estudantes, famílias, empresas e responsáveis por serviços digitais a compreender o risco e a pedir a intervenção certa. A informação abaixo resulta dos avisos públicos dos projectos PHP e Node.js.
Prioridade: actualizar os serviços expostos à Internet. As duas falhas críticas do PHP foram corrigidas nas versões de 21 de Outubro. Hoje, dia 23, surgiu uma orientação adicional sobre sessões e carregamentos de ficheiros, que deve ser verificada mesmo depois dessa actualização. Consultar os dois avisos oficiais do PHP.
O que são PHP, Node.js e uma vulnerabilidade?
PHP e Node.js executam código que faz funcionar serviços digitais: receber formulários, consultar dados ou responder a uma aplicação. Muitas pessoas utilizam estes serviços sem conhecer a tecnologia que está por trás. A actualização cabe, em regra, a quem administra o servidor ou à empresa de alojamento.
Uma vulnerabilidade é uma falha que pode ser aproveitada para ultrapassar uma protecção. O código CVE identifica uma falha concreta; permite confirmar se o aviso e a correcção se referem ao mesmo problema. Execução remota de código significa que alguém pode conseguir executar instruções na máquina através da rede. O alcance depende das permissões do processo atingido. Uma classificação de gravidade indica o potencial do problema; não demonstra, por si só, que um serviço foi atacado.
PHP: duas falhas críticas, com causas diferentes
As duas vulnerabilidades abaixo foram divulgadas publicamente em 21 de Outubro de 2026, com classificação crítica, CVSS 4.0 de 9,2/10. As fichas oficiais indicam a data de publicação; não apresentam uma data única de descoberta que possamos atribuir com rigor a cada falha. Ficha da primeira falha e ficha da segunda.
CVE-2026-109618 — a memória esgota-se a meio da preparação de um pedido
O PHP pode interromper um pedido por falta de memória enquanto ainda está a preparar estruturas internas. Ao encerrar esse pedido, pode tratar dados incompletos como se estivessem prontos. A falha permite chegar à execução de código sem autenticação; os investigadores demonstraram esse resultado com Apache e mod_php. O aviso também descreve susceptibilidade de outros modos de execução, com condições diferentes.
Na prática: num serviço vulnerável, um pedido dirigido ao servidor pode fazer mais do que provocar uma página de erro: pode comprometer o processo que responde ao site. Corrigir apenas o formulário não elimina a falha do PHP. Detalhes, limites e correcção no aviso oficial.
CVE-2026-109619 — um processo volta a usar memória que já foi libertada
Um processo do servidor pode responder a vários pedidos seguidos. Nesta falha, certos estados de um pedido ficam guardados depois de a memória correspondente ter sido libertada. Um pedido posterior, atendido pelo mesmo processo, pode voltar a usar essa referência inválida. A exploração depende da sequência de operações, da configuração e da aplicação.
Na prática: uma sequência de erros e novos pedidos pode permitir execução de código com as permissões do serviço. Ocultar mensagens de erro não impede o acesso interno à memória inválida. É necessário instalar a correcção. Explicação e condições confirmadas pelo PHP.

Três mecanismos distintos. As duas primeiras situações ajudam a compreender as falhas do PHP; a terceira representa a falha de descompressão Brotli do Node.js. Ilustração explicativa, sem dados de sistemas reais.
Que versão do PHP corrige as duas falhas?
Na tabela, “anteriores” refere-se às versões da mesma série. Os números indicam as primeiras versões oficiais que corrigem estas duas vulnerabilidades; versões posteriores com as correcções também servem. Descargas oficiais e registo das alterações.
| Série utilizada | Versões afectadas | Primeira versão corrigida |
|---|---|---|
| PHP 8.2 | Anteriores à 8.2.35 | 8.2.35 |
| PHP 8.3 | Anteriores à 8.3.36 | 8.3.36 |
| PHP 8.4 | Anteriores à 8.4.27 | 8.4.27 |
| PHP 8.5 | Anteriores à 8.5.12 | 8.5.12 |
O PHP 8.1 e as séries anteriores já não recebem manutenção do projecto. Quem depende de suporte prolongado de uma distribuição deve confirmar, no aviso desse fornecedor, se o pacote recebeu a correcção por backport — aplicação da correcção a uma versão anterior. A série 8.2 termina o suporte de segurança do projecto em 31 de Dezembro de 2026. Calendário oficial de suporte e orientação para versões antigas.
Orientação de 23 de Outubro: verificar também o progresso dos carregamentos
O PHP identificou um cenário adicional, associado à CVE-2026-115560: a aplicação configura session.serialize_handler como php_binary ou php_serialize, muda-o para php durante a execução, antes de session_start(), e mantém activo o progresso de carregamento. É uma combinação pouco habitual, com possível execução remota de código.
O projecto recomenda definir session.upload_progress.enabled=0 até à próxima versão regular de correcções. A alteração deve ser aplicada na configuração que vigora antes de o PHP interpretar o pedido, seguida do reinício de todos os processos PHP. Esta recomendação também interessa a quem já instalou as versões de 21 de Outubro. Aplicações que nunca mudam o serializador durante a execução podem manter a funcionalidade activa, segundo o aviso. Ler “Informational advisory: Session upload progress”, de 23 de Outubro.
Node.js: o que muda em cada uma das dez falhas
O comunicado de 21 de Outubro de 2026 apresenta dez vulnerabilidades: quatro de gravidade alta, três média e três baixa. As datas abaixo são de divulgação no comunicado, não datas de descoberta privada. Cada problema exige as condições descritas; ter Node.js instalado não significa que todos os caminhos de exploração estejam acessíveis. Comunicado oficial e classificação de cada CVE.
Gravidade alta: dados comprimidos, resolução de nomes e certificados
- CVE-2026-111497 · Brotli · séries 22, 24 e 26. Descomprimir dados malformados pode corromper memória, derrubar o processo, expor o seu conteúdo ou permitir execução de código. A exposição depende de a aplicação descomprimir dados fornecidos pelo atacante.
- CVE-2026-105482 · DNS · séries 22, 24 e 26. Um carácter nulo pode cortar o nome consultado. Uma aplicação pode validar um domínio e depois obter o endereço de outro, comprometendo regras de destinos permitidos.
- CVE-2026-105483 · TLS · séries 24 e 26. Dígitos não ASCII na escrita de um endereço IP podem levar à aceitação de um certificado sem a identificação IP correspondente.
- CVE-2026-106069 · TLS · séries 22, 24 e 26. Um IP escrito com zero inicial pode ser interpretado de maneira diferente pela ligação e pela validação do certificado. O serviço pode autenticar o endereço errado.
Fontes: correcções da série 22, correcções da série 24 e condições de exploração no comunicado.
Gravidade média: respostas trocadas, identidade do servidor e valores repetidos
- CVE-2026-105481 · HTTP · séries 22, 24 e 26. Ao reutilizar uma ligação, o cliente pode aceitar uma resposta recebida antes de enviar o novo pedido. A aplicação pode associar essa resposta ao pedido errado.
- CVE-2026-106072 · TLS · séries 22, 24 e 26. Algumas escritas alternativas de IPv4 podem permitir que um certificado com identificação DNS autentique um endereço IP. A exploração exige um certificado e um resolvedor compatíveis com essas condições.
- CVE-2026-106074 · aleatoriedade · séries 22, 24 e 26. Instantâneos de arranque podem guardar valores aleatórios já preparados. Processos iniciados a partir deles podem repetir UUIDs ou números, causando colisões ou previsibilidade quando essas funções foram usadas na criação do instantâneo.
Fontes: notas da versão 24.22.1 e explicação oficial das condições.
Gravidade baixa: leitura de ZIP e permissões sobre ficheiros
- CVE-2026-106070 · ZIP · série 26. Depois de uma validação falhar, a API pode devolver bytes diferentes da entrada pedida. Um verificador pode aprovar conteúdo diferente daquele que outra ferramenta extrai do mesmo arquivo.
- CVE-2026-106071 · permissões · série 26. Regras com caracteres universais podem conceder acesso a caminhos fora do padrão autorizado, em condições específicas da árvore de permissões.
- CVE-2026-106073 · permissões · séries 22, 24 e 26. A função
fs.realpathSync()pode revelar a existência e os caminhos de ficheiros fora das permissões de leitura concedidas.
Fontes: correcções da série 26 e aviso oficial sobre as regras de permissões.
Que versão do Node.js instalar?
| Série | Actualizar versões anteriores a | Pacotes e notas oficiais |
|---|---|---|
| 22.x · LTS | 22.23.4 | Node.js 22.23.4 |
| 24.x · LTS | 24.22.1 | Node.js 24.22.1 |
| 26.x · Current | 26.12.1 | Node.js 26.12.1 |
Quem utiliza uma série sem suporte deve preparar a migração para uma série mantida. Para escolher o instalador adequado ao sistema operativo e à arquitectura, utilize a página oficial de descargas. As páginas de cada versão incluem os pacotes e os valores de verificação. Não basta actualizar as dependências de um projecto com npm update: é preciso corrigir também o próprio executável Node.js.
O que fazer agora, conforme a sua responsabilidade
Se utiliza um site, uma loja ou uma aplicação
Estas correcções não se instalam no navegador de quem visita a página. Se é responsável por contratar o serviço, peça à empresa de alojamento a confirmação da versão activa e da aplicação das correcções. Pode enviar esta pergunta:
“Confirmam que o PHP e/ou o Node.js que executam o nosso serviço receberam as correcções de 21 de Outubro de 2026? Verificaram também a orientação do PHP de 23 de Outubro sobre session.upload_progress.enabled? Os processos foram reiniciados e a versão em execução foi confirmada?”
Se administra o alojamento ou desenvolve o serviço
- Identifique a instalação que realmente atende o público. Inclua servidores, contentores, tarefas e processos persistentes.
php -venode --versionmostram o executável chamado no terminal; isso não prova que o servidor ou o gestor de processos utiliza a mesma instalação. - Escolha o pacote correcto. Use o repositório de confiança da distribuição, o fornecedor do alojamento ou as descargas oficiais indicadas acima. Se o fornecedor aplica backports, confirme a correcção no seu aviso de segurança, em vez de avaliar apenas o número-base da versão.
- Prepare cópia de segurança e teste a compatibilidade. Valide as operações essenciais do serviço, incluindo autenticação, formulários, carregamentos e ligações externas, conforme as funções que a aplicação oferece.
- Actualize e reinicie os processos afectados. Em contentores, reconstrua e volte a publicar as imagens. Reveja os caminhos usados pelo gestor de processos para evitar que continue a arrancar a instalação antiga.
- Confirme a versão em execução e a configuração adicional do PHP. Faça a verificação por meios administrativos. Uma página pública com a configuração completa do servidor expõe informação desnecessária.
- Registe a intervenção e acompanhe os sinais de falha. A actualização fecha estas vulnerabilidades, mas não apaga uma eventual intrusão anterior. Perante indícios concretos, preserve os registos e accione a resposta a incidentes.
Se não conseguir actualizar imediatamente o PHP, consulte as medidas temporárias no aviso de esgotamento de memória e no aviso de estado persistente. Os próprios autores explicam que essas medidas não cobrem todos os caminhos de exploração. Um filtro de tráfego ou uma alteração isolada de configuração não substitui o pacote corrigido.
Datas e fontes: o que foi possível confirmar
- 20 de Outubro: o PHP anunciou antecipadamente a publicação de duas correcções críticas.
- 21 de Outubro: o PHP publicou os avisos das CVE-2026-109618 e CVE-2026-109619 e anunciou as versões corrigidas; o Node.js publicou o comunicado com as dez vulnerabilidades e as suas versões de segurança.
- 23 de Outubro: o PHP publicou a orientação adicional sobre o progresso de carregamentos e indicou que o aviso completo da CVE-2026-115560 acompanhará a próxima versão regular.
As datas de publicação podem ser confirmadas no arquivo oficial do PHP e no comunicado do Node.js. As datas de descoberta e de comunicação privada de cada falha não estão discriminadas nestes comunicados; por isso, não as apresentamos como factos.
Departamento de Tecnologias de Informação
Instituto Superior Politécnico Privado do Kilamba
Artigos Relacionados
← Voltar às Notícias