Cognition lança plugin para agentes de código contra falhas no PHP e no Node.js com CVSS 9.2

Em 21 de outubro de 2026, saíram atualizações de segurança urgentes para PHP e Node.js, e as duas histórias envolvem execução remota de código. No PHP, foi corrigido o par de vulnerabilidades PHP2Shell (CVE-2026-109618 e CVE-2026-109619), com nota CVSS v4 9,2, que não exige autenticação. No Node.js, foram corrigidas 10 CVEs, quatro delas com severidade High. A Cognition, empresa por trás do agente Devin, afirma que as falhas já estão sendo exploradas de forma automatizada e publicou em código aberto um plugin que transforma o agente de código no responsável por todo o processo de aplicação de patches.

O que exatamente está quebrado

O PHP2Shell é composto por dois bugs. O primeiro, CVE-2026-109618, é uma corrupção de memória após o esgotamento da memória RAM. O segundo, CVE-2026-109619, é um estado global obsoleto que uma requisição deixa para a seguinte. Qualquer configuração web do PHP é afetada: PHP-FPM, php-cgi, FrankenPHP, LiteSpeed e Apache mod_php, que tem o risco mais alto.

No Node.js, o principal problema é a CVE-2026-111497: uma escrita fora dos limites do buffer no decodificador Brotli, que pode levar à execução de código. A prioridade é corrigir os serviços expostos à internet que descompactam Brotli: clientes HTTP, servidores e proxies. Outras três vulnerabilidades High (CVE-2026-105482, CVE-2026-105483, CVE-2026-106069) estão ligadas a TLS e à verificação de nomes de host. Elas são perigosas para serviços que acessam endereços definidos pelo usuário.

• PHP: correções nas versões 8.2.35, 8.3.36, 8.4.27 e 8.5.12; para 7.4, 8.0 e 8.1, foram publicados apenas backports no código-fonte
• Node.js: 22.23.4, 24.22.1 e 26.12.1
• O Node.js 20 e versões anteriores perderam o suporte e não receberão patches, mas a vulnerabilidade continua lá; é preciso migrar para a 22+
• O release do Node.js atualiza OpenSSL, c-ares, Undici, SQLite e o repositório de CAs: o certificado raiz da eMudhra foi removido dele

Por que "simplesmente atualizar" não resolve

PHP e Node.js se escondem em imagens de contêiner, pacotes do SO, pipelines de CI, valores do Helm, Terraform e runtimes do Lambda, e isso em dezenas de repositórios. Cada implantação precisa ser localizada, atualizada, testada e colocada em produção.

Há armadilhas. Debian e Ubuntu fazem backport das correções sem mudar a versão do upstream: no Ubuntu 24.04, o pacote corrigido se chama 8.3.6-0ubuntu0.24.04.13, e o `php -v` continua mostrando 8.3.6. É preciso consultar o boletim de segurança do fornecedor ou o changelog do pacote. Imagens fixadas por digest exigem um novo digest, e tags flutuantes como php:8.3-fpm precisam ser reconstruídas com a nova imagem base. Alterar require.php ou config.platform.php no Composer não corrige nada: essas configurações não escolhem o runtime em produção.

Se não for possível atualizar de imediato, o PHP propõe medidas temporárias. Entre elas, session.upload_progress.enabled=0 com reinício de todos os workers e limite ao tamanho do corpo da requisição e ao número de partes multipart no proxy. RLIMIT_AS e RLIMIT_DATA não devem ser usados: eles mesmos ativam o caminho de código vulnerável.

Como o plugin funciona

O plugin Vulnerability Fixes foi construído a partir do processo que a Cognition usou para corrigir a própria infraestrutura. Primeiro, o agente faz um inventário somente leitura: Dockerfile, imagens base, pacotes, builds a partir do código-fonte, setup-php, setup-node, .nvmrc, Terraform, Packer, Ansible, Chef e Puppet. Em seguida, mostra uma tabela e espera você definir em quais repositórios ele pode mexer. Tudo o que for mais arriscado que uma troca de versão de patch (upgrade minor ou major, troca do SO base, prováveis alterações de código) ele sinaliza de antemão.

Depois, o agente confere tags, digests, versões de pacotes e checksums nos registries oficiais, roda os testes na versão atual como linha de base, repete os testes na nova imagem de produção e compara os runtimes: extensões, configurações ini, versões do OpenSSL e do ICU. O resultado é um PR por repositório, com as versões antes e depois, os resultados dos testes, uma etiqueta de risco e um plano de rollout e rollback.

O plugin está no Devin Marketplace e também como Agent Skills padrão para Claude Code, Codex, Cursor, Factory Droid, GitHub Copilot, Gemini CLI e OpenCode: `npx skills add CognitionAI/devin-vuln-fixes`. As skills são executadas com todos os privilégios do seu agente, por isso a Cognition pede que você as leia antes de rodar. Para build e testes, são necessários git, shell, Docker e acesso ao seu registry de imagens.

Por onde começar hoje

A Cognition recomenda, antes de tudo, tirar do ar os aplicativos PHP públicos enquanto o patch é aplicado: a exploração está automatizada. Depois:

• verificar as versões pelo boletim da distribuição, e não pelo `php -v`
• reconstruir as imagens com tags flutuantes e trocar o digest nas imagens fixadas
• incluir o Node 20 e anteriores no plano de migração para a 22+
• colocar os PRs arriscados primeiro em staging ou canary
• após o merge, refazer o deploy de cada serviço: a correção só vale na nova build

O agente verifica apenas o que está coberto por testes, então, para aplicações pouco testadas, o PR recomenda explicitamente o staging. Runtimes gerenciados são corrigidos pelo provedor, e, no caso de soluções de hardware de fornecedores e de aplicativos Electron com PHP ou Node embutido, o agente apenas sinaliza que é preciso aguardar a atualização do fornecedor.

A Cognition acredita que episódios assim vão virar rotina: a velocidade de descoberta de vulnerabilidades está crescendo, e os atacantes automatizam cadeias de exploração com ajuda de IA. A empresa recomenda escanear continuamente a superfície de ataque externa, colocar os aplicativos internos atrás de VPN ou ZTNA, migrar para runtimes e contêineres mais recentes e abandonar os ciclos de patching de 30 dias. O diretor de segurança, Alex Stamos, fará um webinar em 26 de outubro, às 10:30 no horário do Pacífico.