lorenzopasquali.dev

PHP2Shell, Node.js e GitLab: a semana em que a segurança virou uma corrida contra o tempo

· 8 min de leitura · também em English

Nos últimos dias, uma sequência de vulnerabilidades críticas em tecnologias bastante utilizadas voltou a levantar uma questão importante: estamos preparados para um cenário em que encontrar falhas e transformá-las em exploits fica cada vez mais rápido?

Entre 20 e 27 de outubro, PHP, Node.js e GitLab publicaram atualizações de segurança relevantes. Não estamos falando apenas de bugs que exigem condições muito específicas para causar algum impacto. Alguns dos problemas permitem execução remota de código, em determinados cenários até mesmo sem autenticação.

E existe um detalhe que torna essa sequência especialmente interessante: tudo isso acontece justamente quando a inteligência artificial começa a mudar a maneira como vulnerabilidades são descobertas, analisadas e exploradas.

PHP2Shell: duas falhas críticas no coração do PHP

O primeiro caso que chamou atenção foi o PHP2Shell, nome associado a duas vulnerabilidades do interpretador PHP: CVE-2026-109618 e CVE-2026-109619.

Ambas receberam pontuação CVSS 4.0 de 9,2, considerada crítica, e podem permitir execução remota de código sem autenticação.

A primeira está relacionada ao tratamento de memória quando uma requisição provoca uma condição de falta de memória. A segunda envolve o uso de referências para regiões de memória que já foram liberadas, conhecido como use-after-free.

Na prática, um atacante pode tentar explorar esses comportamentos para executar comandos com as permissões do processo que executa o servidor web.

O detalhe mais preocupante é que o problema não fica restrito à aplicação PHP que desenvolvemos. Dependendo da configuração, a vulnerabilidade pode ser acionada durante o processamento da requisição, antes mesmo de o código da aplicação ser executado. Isso reduz a capacidade de uma aplicação se proteger apenas com validações internas.

Os riscos atingem diferentes formas de executar PHP, incluindo Apache com mod_php, PHP-FPM, php-cgi, FrankenPHP e LiteSpeed.

Em 21 de outubro, o projeto publicou as versões corrigidas 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Sistemas em versões antigas e sem suporte também exigem atenção especial.

Fontes: comunicado do PHP, análise da Sophos e orientação do governo de Singapura.

O problema não terminou com a primeira atualização

Em 23 de outubro, o projeto PHP publicou informações sobre outra possível vulnerabilidade, identificada como CVE-2026-115560, relacionada ao recurso de progresso de upload de sessões.

Ela não foi resolvida pelas mesmas atualizações emergenciais do PHP2Shell. Até que uma correção esteja disponível, a recomendação publicada é desabilitar o recurso com:

session.upload_progress.enabled=0

A existência desse novo problema é importante porque mostra como uma investigação de segurança pode revelar outros caminhos de exploração dentro de funcionalidades relacionadas.

Também precisamos distinguir as coisas: essa terceira CVE não deve ser tratada simplesmente como uma terceira falha já corrigida pelo patch do dia 21. É um problema adicional, com orientação própria de mitigação.

Fonte: alerta técnico do MyCERT, de 24 de outubro.

Node.js: falhas que atingem desde DNS até a memória do processo

No mesmo dia 21 de outubro, o projeto Node.js publicou uma nova rodada de atualizações de segurança para as linhas 22.x, 24.x e 26.x.

Entre os problemas corrigidos está a CVE-2026-111497, uma falha no decodificador Brotli integrado ao Node.js. Dados comprimidos especialmente preparados podem provocar uma escrita fora dos limites de um buffer, causando corrupção de memória, falhas no processo e, potencialmente, execução remota de código.

A condição de exploração depende de a aplicação aceitar e descomprimir conteúdo controlado por um atacante usando a funcionalidade afetada.

Mas essa não foi a única questão da atualização. O comunicado também abordou problemas na resolução DNS, na validação de certificados TLS, no reaproveitamento de conexões HTTP e no modelo de permissões do sistema de arquivos.

Alguns exemplos:

O ponto aqui é que segurança não se resume a evitar SQL injection ou validar os dados recebidos de um formulário. Funções aparentemente fundamentais, como resolver nomes de domínio, validar certificados e descomprimir arquivos, também podem esconder falhas relevantes.

As versões publicadas para corrigir os problemas foram Node.js 22.23.4, 24.22.1 e 26.12.1.

Fonte primária: comunicado oficial de segurança do Node.js, de 21 de outubro.

GitLab: uma CVE com pontuação máxima

O GitLab também entrou nessa sequência de alertas com a CVE-2026-110264, divulgada em 21 de outubro.

A vulnerabilidade recebeu pontuação CVSS 3.1 de 10,0 e está relacionada a um estouro de inteiro no compilador de expressões regulares. Sob determinadas condições, ela pode permitir que um atacante não autenticado execute código arbitrário no servidor.

O alcance merece atenção: o alerta do CERT-EU indica que as versões self-managed do GitLab CE e EE desde a linha 7.0 estão no intervalo afetado, respeitando os limites específicos de cada versão.

Isso é especialmente relevante porque o GitLab pode ser muito mais do que um repositório Git. Em muitas organizações, ele faz parte da infraestrutura de desenvolvimento, armazenando código-fonte, pipelines de CI/CD, variáveis de ambiente e informações sobre o processo de entrega de software.

Uma falha que compromete essa plataforma pode, portanto, ter consequências que vão além da disponibilidade do serviço.

As versões corrigidas incluem 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 e 19.5.1.

É importante não confundir esse problema com todas as outras vulnerabilidades corrigidas pelo GitLab no período: o comunicado de 21 de outubro também contemplou falhas de severidades diferentes.

Fontes: alerta do CERT-EU e alerta do governo brasileiro.

O que isso tem a ver com inteligência artificial?

É aqui que a discussão fica mais interessante.

Seria fácil reunir essas vulnerabilidades e concluir que a IA está tornando o software menos seguro. Mas essa conclusão seria precipitada.

O que temos é uma mudança na velocidade com que problemas podem ser encontrados e explorados.

Em uma reportagem publicada em 23 de outubro, a Reuters ouviu especialistas em segurança que discutiram justamente esse cenário. Segundo a reportagem, pesquisadores da empresa de inteligência de ameaças VulnCheck apontaram um aumento expressivo na descoberta de falhas, com a IA entre os fatores que contribuem para esse crescimento.

A reportagem também destaca que modelos de IA podem examinar bases de código continuamente, encontrar problemas e ajudar a desenvolver exploits em períodos muito menores do que os que tradicionalmente seriam necessários.

Isso altera uma premissa importante da segurança: o intervalo entre a descoberta de uma vulnerabilidade e sua exploração pode ficar cada vez menor.

Historicamente, encontrar uma falha, compreender sua causa, desenvolver uma exploração funcional e transformá-la em um ataque confiável exigia tempo e conhecimento especializado. Hoje, ferramentas automatizadas podem reduzir parte desse trabalho.

Mas há uma ressalva essencial: mais vulnerabilidades descobertas não significam automaticamente mais ataques bem-sucedidos. A própria Reuters relata divergências entre especialistas sobre o impacto líquido da IA. Algumas falhas encontradas por ferramentas avançadas continuam difíceis de explorar na prática.

Também não há evidência suficiente para atribuir todas as vulnerabilidades desta semana à inteligência artificial. No caso do Node.js, por exemplo, o projeto reconheceu o OpenAI Codex Security entre os responsáveis pela descoberta da falha no Brotli. Isso demonstra uma participação concreta da IA naquele caso, não uma explicação universal para todos os incidentes.

Fonte: Reuters — AI-discovered bugs may soon trigger fresh disruptions, 23 de outubro de 2026.

O mercado está preocupado?

Sim, há sinais concretos de preocupação operacional no setor de segurança, mas é importante separar isso de uma suposta crise financeira generalizada.

A sequência de alertas provocou recomendações urgentes de atualização, investigações sobre possíveis comprometimentos e, segundo a Reuters, casos de operadores que retiraram sites temporariamente do ar por não conseguirem corrigir seus sistemas antes de uma possível exploração.

O impacto mais evidente é o aumento da pressão sobre equipes de infraestrutura, segurança e desenvolvimento. Atualizações emergenciais precisam ser avaliadas, testadas e implantadas rapidamente, sem introduzir novos problemas de compatibilidade ou indisponibilidade.

Para empresas que mantêm sistemas antigos, aplicações expostas à internet ou instalações próprias de plataformas como GitLab, o custo pode ser significativo: inventariar ativos, atualizar dependências, reiniciar serviços, revisar logs e verificar se houve invasão antes da correção.

Não há, porém, base suficiente para afirmar que esses episódios causaram uma queda generalizada do mercado de tecnologia ou que investidores estejam reagindo de forma uniforme. O sinal mais claro, neste momento, é de preocupação com a resiliência da infraestrutura digital.

O que eu faria como desenvolvedor?

Para mim, a principal lição dessa semana é que a segurança precisa fazer parte do ciclo de desenvolvimento, e não aparecer apenas quando uma CVE crítica vira notícia.

Algumas medidas práticas:

  1. Inventariar o que realmente está rodando. Não basta conhecer as dependências declaradas no projeto. É necessário identificar runtimes, imagens Docker, serviços embutidos em appliances e componentes mantidos por terceiros.
  2. Priorizar a exposição real. Serviços acessíveis pela internet, especialmente aqueles com possibilidade de execução remota de código sem autenticação, merecem prioridade.
  3. Atualizar e verificar. Aplicar o patch é apenas uma parte do processo. É necessário confirmar a versão efetivamente utilizada, reiniciar os processos quando necessário e revisar sinais de comprometimento.
  4. Automatizar a identificação de vulnerabilidades. Scanners de dependências, análise estática, monitoramento de imagens e alertas de segurança precisam estar integrados ao fluxo de desenvolvimento.
  5. Usar IA também para defesa. Ferramentas de análise assistida podem ajudar a revisar código, investigar avisos, criar testes de regressão e acelerar a compreensão de patches. Mas suas conclusões precisam ser verificadas.

No meu contexto de desenvolvimento, com aplicações, integrações, bancos de dados e serviços executados em contêineres, a lição é direta: conhecer a aplicação não é suficiente. Precisamos conhecer também toda a infraestrutura de software da qual ela depende.

A segurança vai se tornar uma corrida permanente?

Minha impressão é que estamos entrando em uma fase em que o tempo de resposta será tão importante quanto a capacidade de prevenir vulnerabilidades.

A inteligência artificial pode ajudar desenvolvedores a encontrar e corrigir falhas antes que elas cheguem à produção. Ao mesmo tempo, pode reduzir o esforço necessário para que atacantes investiguem sistemas e automatizem etapas de exploração.

Isso não significa que a IA seja inerentemente insegura, nem que o software esteja condenado a se tornar mais vulnerável. Significa que as práticas de segurança precisam evoluir junto com as ferramentas de desenvolvimento.

Se a implementação de software está ficando mais rápida, a análise, a validação, a distribuição de correções e o monitoramento também precisam acompanhar esse ritmo.

O PHP2Shell, os problemas do Node.js e a vulnerabilidade crítica do GitLab mostram que até componentes maduros e amplamente utilizados podem esconder falhas graves. E, em um cenário de descoberta acelerada, a diferença entre uma vulnerabilidade conhecida e um incidente real pode estar no tempo que uma organização leva para reagir.

Talvez a pergunta mais importante não seja se a IA vai encontrar mais bugs.

É se nossas equipes, processos e infraestruturas estarão preparadas para lidar com eles na velocidade em que passarão a aparecer.

← Todos os posts