A equipe de segurança do PHP lançou, em 21 de outubro de 2026, correções para duas vulnerabilidades críticas de execução remota de código (RCE) identificadas como CVE-2026-109618 e CVE-2026-109619 (GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp). Segundo o anúncio oficial, qualquer instalação do PHP que atenda requisições web está em risco — incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed —, com risco ainda maior para quem usa mod_php. Isso cobre a enorme maioria dos sites do mundo, já que o PHP está por trás de grande parte do comércio eletrônico brasileiro, incluindo lojas em WordPress/WooCommerce, Magento e outras plataformas.

As duas falhas têm origem em problemas de gerenciamento de memória: a CVE-2026-109618 ocorre quando uma falta de memória interrompe o PHP enquanto dados internos da requisição ainda estão parcialmente inicializados, e a rotina de limpeza pode tratar esse estado inválido como válido; a CVE-2026-109619 ocorre quando o estado interno de uma requisição sobrevive depois que sua memória já foi liberada, podendo ser reutilizado indevidamente por uma requisição seguinte no mesmo worker. A equipe do PHP já lançou correções nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35, além de backports mínimos para quem compila a partir do código-fonte em 7.4, 8.0 e 8.1 (branches que não recebem mais suporte oficial). Até a publicação deste artigo não havia confirmação pública de exploração ativa, mas o próprio aviso descreve um exploit demonstrado para configurações com mod_php e caminhos de ataque já confirmados, o que normalmente antecede tentativas reais em poucos dias. A gravidade do caso levou a União Europeia — por meio da Comissão Europeia, ENISA, CERT-EU, Europol e a rede de CSIRTs do bloco — a publicar um comunicado conjunto no mesmo dia, recomendando a atualização imediata de qualquer aplicação baseada em PHP.

Por que isso importa para uma PME brasileira: se o site, a loja virtual ou o sistema interno da sua empresa roda em PHP — o que inclui a maioria dos sites em WordPress, WooCommerce, Magento e sistemas feitos sob encomenda —, ele está potencialmente exposto, mesmo que você nunca tenha ouvido falar da linguagem por trás da ferramenta que usa. Como a falha permite execução de código sem necessidade de login, um site comprometido pode ser usado para roubar dados de clientes, desviar pagamentos ou servir como porta de entrada para outros ataques, incluindo ransomware. E como a correção depende de quem hospeda ou mantém o site — agência, freelancer, provedor de hospedagem ou plataforma —, o maior risco é a falha ficar sem atualização por falta de alguém assumir a responsabilidade.

O que fazer agora: pergunte hoje mesmo à sua agência, freelancer ou provedor de hospedagem se os servidores PHP já foram atualizados para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou a versão com patch equivalente do seu fornecedor). Se sua empresa usa um servidor compartilhado ou gerenciado, confira se o painel de hospedagem já aplicou a atualização automaticamente — a maioria dos grandes provedores costuma aplicar correções críticas rapidamente, mas vale confirmar. Se o site roda PHP 8.1 ou anterior, trate isso como prioridade além da correção pontual: essas versões não recebem mais suporte oficial, e migrar para uma versão com suporte deveria estar no radar. Enquanto a atualização não é confirmada, evite expor painéis administrativos e áreas sensíveis do site diretamente à internet sem proteção adicional (como autenticação extra ou restrição de IP).

Fonte primária: anúncio oficial de segurança do PHP, 21/10/2026 (CVE-2026-109618 e CVE-2026-109619).