Correções de emergência visam duas vulnerabilidades em software web amplamente utilizado
A Agência para a Internet e Segurança da Coreia do Sul (KISA) instou os operadores de websites a atualizarem o PHP a 21 de outubro de 2026, depois de terem sido identificadas duas vulnerabilidades de segurança em software usado para gerir páginas de início de sessão, serviços de compras e fóruns de discussão. Os riscos comunicados incluem a possibilidade de atacantes executarem código num servidor sem iniciarem sessão.
Índice
- Correções de emergência visam duas vulnerabilidades em software web amplamente utilizado
- Que versões do PHP precisam de atenção?
- O que as duas falhas podem permitir
- Porque é que o WordPress torna o problema relevante para empresas comuns
- Coreia do Sul contacta empresas através de dois canais de segurança
- Como evoluiu a resposta
- Descoberta com IA e investigação de segurança independente
- Porque é que algumas autoridades recomendaram desligar os sistemas
- O que os operadores devem fazer agora
- Pontos principais
A KISA identificou as vulnerabilidades como CVE-2026-109618, relacionada com o tratamento inadequado de condições excecionais, e CVE-2026-109619, relacionada com a utilização de memória depois de esta ter sido libertada. Os limites de atualização indicados abrangem quatro ramos de versões do PHP: 8.2.35, 8.3.36, 8.4.27 e 8.5.12.
O Ministério da Ciência e das TIC da Coreia do Sul e a KISA emitiram, na noite de 21 de outubro, pedidos de segurança dirigidos a empresas e instituições integradas em redes nacionais de cibersegurança. As autoridades governamentais deram conta dessa iniciativa a 22 de outubro. Estava a ser ponderada a prestação de assistência de emergência para ajudar empresas de menor dimensão a instalar as correções.
As vulnerabilidades, descritas em conjunto como PHP2Shell, motivaram uma resposta internacional. Segundo relatos, algumas instituições governamentais nos Países Baixos e na Finlândia suspenderam os seus websites por precaução, enquanto autoridades de cibersegurança na Europa, no Japão e na Austrália recomendaram atualizações. Segundo relatos, as agências norte-americanas também aconselharam a desligar os sistemas afetados quando não fosse possível instalar imediatamente as correções.
Que versões do PHP precisam de atenção?
As recomendações da KISA estabelecem uma versão mínima diferente para cada ramo do PHP afetado. Um ramo é uma família de versões: por exemplo, um website que utilize PHP 8.3 precisa da versão corrigida dessa família ou de uma versão suportada mais recente adequada.
- PHP 8.2: atualize as versões anteriores à 8.2.35.
- PHP 8.3: atualize as versões anteriores à 8.3.36.
- PHP 8.4: atualize as versões anteriores à 8.4.27.
- PHP 8.5: atualize as versões anteriores à 8.5.12.
A KISA alertou também que o PHP 8.1 e as versões anteriores tinham chegado ao fim do período de suporte oficial de segurança. Os operadores que utilizem essas versões foram aconselhados a passar para uma versão suportada, em vez de continuarem a usar software cujo suporte oficial de segurança terminou.
Para uma empresa, o primeiro passo prático é verificar a versão do PHP que está a correr no servidor do website. O fornecedor de alojamento pode gerir esse software, ou essa responsabilidade pode caber à equipa interna de tecnologia. Atualizar o navegador de um portátil altera uma parte diferente do sistema.
O que as duas falhas podem permitir
A CVE-2026-109618 diz respeito a condições excecionais, ou seja, situações em que o software se depara com algo fora do seu funcionamento normal. Os programas têm de lidar com essas situações de forma segura. Uma falha nesse tratamento pode levar o software a comportar-se de forma imprevista.
A CVE-2026-109619 é descrita como uma vulnerabilidade de utilização após libertação. O software reserva temporariamente áreas de memória do computador e liberta-as quando já não precisa delas. Este tipo de falha ocorre quando um programa tenta posteriormente utilizar uma área que já libertou, podendo aceder a dados que foram alterados ou que pertencem a outra operação.
O risco comunicado é a execução remota de código sem autenticação. Em termos simples, alguém no exterior pode conseguir fazer com que o servidor de um website execute instruções sem introduzir um nome de utilizador ou uma palavra-passe válidos. Um ataque bem-sucedido pode expor informações, instalar software malicioso ou interromper serviços.
Os anúncios divulgados publicamente não especificaram as configurações de servidor nem as condições de pedido exatas necessárias para explorar cada vulnerabilidade. Os operadores devem, por isso, verificar as versões de software afetadas e obter orientação técnica adequada às suas próprias instalações.
Porque é que o WordPress torna o problema relevante para empresas comuns
O PHP é executado no servidor de um website, não no telemóvel ou computador de quem o visita. Quando um cliente pede para consultar o histórico de encomendas, um programa PHP pode obter os registos relevantes de uma base de dados e preparar a página que é enviada ao navegador. Os sistemas de início de sessão, os comentários e os fóruns de mensagens podem funcionar da mesma forma.
O WordPress, que disponibiliza ferramentas para criar e gerir websites, também funciona com PHP. Isto faz com que a resposta de segurança diga respeito a blogues, websites de empresas e lojas online cujos proprietários raramente têm contacto direto com a linguagem de programação subjacente.
Segundo dados atribuídos à W3Techs, um serviço de medição de tecnologias web, o PHP é utilizado por cerca de 75% dos websites cuja linguagem de programação do servidor pode ser identificada. O WordPress representa cerca de 43% de todos os websites. A percentagem do PHP assenta num universo mais restrito do que a do WordPress: websites com uma linguagem de servidor identificável, e não todos os websites.
Estes números ajudam a explicar a amplitude da resposta. Muitos websites geridos de forma independente dependem do mesmo software subjacente, pelo que uma única campanha de correção pode envolver simultaneamente instituições públicas, grandes empresas e pequenos negócios.
Coreia do Sul contacta empresas através de dois canais de segurança
O Ministério da Ciência e das TIC e a KISA dirigiram os pedidos de 21 de outubro aos membros da C-TAS, um sistema de análise e partilha de informações sobre ciberameaças, e às empresas obrigadas a designar um responsável máximo pela segurança da informação, ou CISO.
A C-TAS conta com cerca de 5900 empresas e instituições participantes. Cerca de 30 000 empresas são obrigadas, ao abrigo da legislação sul-coreana sobre redes de informação e comunicações, a designar um CISO e a notificar o ministério. O CISO é o responsável de topo pela segurança da informação de uma organização.
Os dois números referem-se a grupos diferentes abrangidos pela iniciativa, que podem ter membros em comum. O Governo recorreu também ao portal público de cibersegurança da KISA, conhecido como Boho Nara, para recomendar atualizações de segurança e a instalação de correções.
As empresas de menor dimensão enfrentam um problema prático de recursos humanos: algumas não têm funcionários capazes de identificar uma instalação afetada, organizar uma atualização e verificar depois se o website continua a funcionar. Um responsável do ministério afirmou que o Governo tinha começado por distribuir orientações de segurança e estava a ponderar prestar assistência de emergência para aplicar as correções. Não foi anunciada qualquer data de início nem critérios de elegibilidade para essa assistência.
Como evoluiu a resposta
A cronologia comunicada remonta a uma auditoria de segurança externa realizada em 2024 e culmina com a antecipação da publicação das correções para outubro de 2026. As principais datas são:
- 2024: Uma auditoria externa terá identificado indícios de algumas falhas. Foram apontadas divergências internas e preocupações quanto à compatibilidade com o software existente como razões para o desenvolvimento de correções não ter avançado nessa altura.
- 21 de outubro de 2026: Segundo relatos, os programadores do PHP publicaram correções para duas vulnerabilidades e a KISA emitiu recomendações de atualização.
- Noite de 21 de outubro: As autoridades sul-coreanas enviaram pedidos de segurança através de canais empresariais e institucionais.
- 22 de outubro: As autoridades sul-coreanas deram conta da iniciativa. Esta era também a data inicialmente prevista para a publicação das correções.
Segundo relatos, as correções foram antecipadas um dia após a divulgação de informações sobre as vulnerabilidades. Também terão sido detetadas tentativas de ataque antes de as correções se tornarem públicas, aumentando a pressão sobre os operadores para agirem rapidamente.
O relato da auditoria de 2024 evidencia também um desafio de manutenção. Uma alteração a software partilhado pode afetar aplicações concebidas em função do seu comportamento existente. As preocupações de compatibilidade podem dificultar a coordenação das reparações, sobretudo quando uma linguagem é utilizada por muitos websites e em diferentes configurações de alojamento.
Descoberta com IA e investigação de segurança independente
Segundo relatos, a empresa de cibersegurança Calif identificou as vulnerabilidades com recurso a um modelo da OpenAI descrito como GPT-5.6 Sol. As falhas terão passado despercebidas durante mais de uma década.
Segundo relatos, a Wiz, uma empresa de cibersegurança ligada à Google, encontrou e comunicou as duas vulnerabilidades de forma independente. Ami Luttwak, cofundador da Wiz, descreveu-as como as vulnerabilidades mais graves descobertas com recurso à IA e afirmou que a sua complexidade teria tornado a descoberta extremamente difícil sem essa tecnologia.
A OpenAI afirmou ter passado os dois meses anteriores a coordenar investigadores e empresas de cibersegurança para apoiar a resposta. Previu também um aumento acentuado de descobertas semelhantes com recurso à IA nos meses seguintes.
O trabalho imediato dos operadores de websites continua a ser concreto: identificar o software instalado, aplicar a correção adequada e manter os serviços a funcionar. A utilização da IA na descoberta acrescenta outra dimensão à história, a par da investigação independente, da coordenação entre programadores e da distribuição de correções.
Porque é que algumas autoridades recomendaram desligar os sistemas
Segundo relatos, a Agência de Segurança Nacional dos EUA instou as organizações que utilizam PHP a atualizarem-no de imediato, alertando que a exploração das vulnerabilidades poderia dar aos atacantes acesso ao sistema de ficheiros ou à base de dados de um servidor. Recomendou que os sistemas afetados fossem desligados até à resolução das vulnerabilidades, caso não fosse possível aplicar as atualizações imediatamente.
Segundo relatos, o FBI emitiu recomendações semelhantes, alertando para a execução remota de código e para a possível exposição de informações e redes sensíveis. Algumas instituições governamentais neerlandesas e finlandesas suspenderam os seus websites como medida preventiva.
Desligar um website tem um custo imediato: os visitantes deixam de poder aceder aos serviços que este disponibiliza. Para uma loja, isso pode significar vendas interrompidas; para uma instituição pública, informações ou formulários online indisponíveis. A recomendação reflete a gravidade de manter um servidor vulnerável acessível enquanto se aguarda uma correção.
A Cloudflare afirmou estar a atualizar as medidas de proteção para acompanhar as vias de ataque. Ainda assim, os operadores de websites foram aconselhados a instalar as correções do PHP e a atualizar o software subjacente para as versões indicadas na resposta de segurança.
O que os operadores devem fazer agora
Os operadores de websites devem determinar quem controla a instalação do PHP e comparar a versão instalada com os limites indicados pela KISA. As organizações que recorrem a um fornecedor de alojamento precisam de obter desse fornecedor a confirmação da versão do servidor e das condições de atualização. As equipas que gerem os seus próprios servidores devem tratar diretamente da alteração.
As empresas que utilizam WordPress devem incluir o ambiente de execução do PHP nesta verificação, a par da manutenção habitual do website. O PHP é uma camada de software separada, subjacente ao sistema de gestão de conteúdos; por isso, saber apenas a versão do WordPress não permite conhecer toda a instalação.
Os operadores que utilizam PHP 8.1 ou versões anteriores têm de passar para uma versão suportada. Quem já utiliza um dos ramos afetados precisa da versão corrigida correspondente ou de uma versão suportada mais recente adequada. Testar funções essenciais, como o início de sessão dos clientes, a consulta de encomendas e os pagamentos, ajuda a detetar problemas de serviço durante a atualização.
Pontos principais
- A KISA emitiu recomendações de atualização de segurança do PHP a 21 de outubro de 2026, identificando as vulnerabilidades CVE-2026-109618 e CVE-2026-109619.
- As versões mínimas indicadas são PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12.
- A KISA aconselhou os utilizadores do PHP 8.1 e de versões anteriores a passarem para uma versão suportada.
- Os riscos comunicados incluem a execução remota de código por atacantes sem iniciarem sessão.
- A Coreia do Sul contactou membros de redes de segurança e empresas obrigadas a designar um CISO.
- Estava a ser ponderada a prestação de assistência de emergência para instalar correções em empresas sul-coreanas de menor dimensão.
- Autoridades internacionais recomendaram atualizações; algumas aconselharam a suspensão temporária dos sistemas quando não fosse possível instalar as correções imediatamente.






