Falhas de segurança: IA, PHP2Shell e a semana de alertas na internet

A sequência de falhas de segurança que mobilizou administradores nesta semana não se resume ao PHP. Entre 17 e 23 de outubro de 2026, problemas no processamento de sites, na emissão de certificados HTTPS, em ferramentas de desenvolvimento e na distribuição de software exigiram respostas diferentes. Ao mesmo tempo, pesquisadores documentaram como a inteligência artificial ajudou a transformar defeitos antigos em caminhos demonstráveis de invasão.

O PHP2Shell é o caso mais visível dessa combinação: falhas no motor do PHP, correções emergenciais e tentativas de exploração observadas antes da divulgação técnica. Mas certificados da eMudhra, uma versão maliciosa do LiteLLM, atualizações do GitLab e do Node.js e relatos sobre o kernel Linux completam um quadro mais amplo. Não há evidência, nos comunicados desses casos, de um único ataque coordenando todos eles.

Seis frentes de risco na mesma semana

Os episódios atingem componentes diferentes. Esta é a situação documentada até 23 de outubro:

PHP2Shell: o problema está abaixo do site

As CVE-2026-109618 e CVE-2026-109619 atingem o processamento interno do PHP. Na primeira, uma interrupção por falta de memória pode deixar estruturas parcialmente inicializadas; na segunda, um processo pode reutilizar estado que aponta para memória já liberada. Um pedido posterior ao servidor pode alcançar esse estado inválido. Não é necessário que o administrador tenha instalado um plugin malicioso para existir exposição.

A PHP Foundation explica que gerenciamento de memória e tratamento de erros são partes centrais do motor. A gravidade depende também de como ele atende às requisições, não apenas do nome do CMS. O Ponto Nulo já detalhou as versões corrigidas e a diferença entre atualizar PHP e WordPress.

Esse tipo de falha muda o responsável pela correção: em uma hospedagem gerenciada, pode ser o provedor; em uma infraestrutura própria, a equipe que mantém o ambiente de execução. Trocar um tema ou atualizar apenas o painel do site não substitui a correção desse componente.

Como a IA transforma falhas antigas em exploits

Uma vulnerabilidade não precisa ter sido criada recentemente para se tornar urgente. A novidade pode ser a descoberta de uma maneira prática de explorá-la. No PHP, a fundação relata que sinais do problema de falta de memória já tinham aparecido em 2024. A dificuldade para demonstrar o impacto, os riscos de incompatibilidade das soluções e a limitação de recursos atrasaram a correção. A organização reconheceu uma falha estrutural nesse processo.

Em agosto de 2026, novos relatos demonstraram execução remota de código e mudaram a prioridade do trabalho. Essa cronologia não significa que criminosos exploravam o problema desde 2024: a idade do defeito e a data de exploração conhecida são informações diferentes.

O relato da Calif mostra uma pesquisa guiada por conhecimento humano. Ryan Austin partiu do histórico de vulnerabilidades do PHP e de hipóteses sobre tratamento de erros. A IA ajudou na leitura de código e na identificação de caminhos relevantes. A equipe encontrou variantes e demonstrou execução remota em aplicações, mas ressalta que um pedido genérico a um modelo não encontra todos os bugs. Na descoberta inicial, segundo o pesquisador, não foi necessário acesso a modelos exclusivos.

A Wiz descreve outro ganho: adaptar exploits a diferentes versões, configurações e arranjos de memória. A empresa atribui aos modelos redução do trabalho de análise, testes e depuração necessário para construir essas cadeias. Isso é mais específico do que dizer que uma IA “hackeou a internet”: foram pesquisadores conduzindo experimentos em ambientes de teste.

Da descoberta à adaptação do ataque

Um exploit é código que usa uma vulnerabilidade para produzir um efeito indevido. Encontrar um erro não basta: uma falha que derruba um processo, por exemplo, não se converte automaticamente em execução confiável de comandos. A passagem entre esses resultados pode exigir várias etapas e depender do ambiente.

Nesse trabalho, a IA pode auxiliar em três tarefas distintas:

1. Localizar caminhos vulneráveis: relacionar trechos de código, estados internos e comportamentos de erro que um pesquisador precisa investigar.
2. Desenvolver e depurar uma demonstração: ajudar a interpretar falhas de testes e revisar hipóteses até que o efeito seja reproduzível.
3. Adaptar uma técnica: reduzir o esforço para lidar com diferenças entre sistemas, sem garantir que uma mesma tentativa funcione em todos eles.

Os relatos de Calif e Wiz documentam esses usos na pesquisa do PHP. A OpenAI confirma a participação de Calif no programa Patch the Planet e descreve a coordenação com mantenedores e fornecedores para preparar correções e proteções antes da divulgação. São relatos de participantes do trabalho, não uma medição independente de quanto qualquer atacante ficou mais capaz.

Na avaliação da Amazon Threat Intelligence, a análise assistida por IA também barateia o caminho entre um boletim ou uma alteração de código e um exploit funcional. Isso reduz a dependência de ferramentas prontas feitas por poucos especialistas. O relatório, porém, não identifica qual modelo teria sido usado nas tentativas observadas contra seus sensores.

Já há ataques? O que os números realmente mostram

A AWS encontrou em sua rede MadPot uma tentativa relacionada ao PHP2Shell datada de 17 de outubro, quatro dias antes da divulgação técnica e das correções. Também observou novas tentativas e uso rápido de provas de conceito no dia 21. A própria análise diz que não estava claro se as tentativas anteriores teriam sucesso em sistemas reais, nem como o responsável obteve a informação ainda sob embargo.

Já a Imperva contabilizou, nas primeiras 24 horas de atividade observada, 482.342 requisições, 122.311 sessões de ataque e 21.998 sites visados, distribuídos por 103 países. O Brasil apareceu entre os países com sites atingidos por esse tráfego. São números da infraestrutura observada pela empresa, não um censo mundial.

O fornecedor descreve uma varredura ampla e automatizada. Uma ferramenta pode enviar muitos pedidos ao mesmo site ou sondar milhares deles sem conseguir uma invasão. Por isso, esses totais não devem ser apresentados como quantidade de vítimas comprometidas. Automação de tráfego também não comprova, por si só, uso de IA: scanners tradicionais já executam tarefas repetitivas em escala.

Há outro número que exige cuidado. Na consulta de 23 de outubro, a W3Techs indicava PHP em 69,3% dos sites cuja linguagem de servidor consegue identificar. Isso não significa que 69,3% de toda a internet esteja vulnerável, muito menos invadida. A estatística mede adoção de tecnologia, não instalação de patches ou sucesso de ataques.

A Censys também acompanha serviços expostos e versões declaradas. Seu boletim de 22 de outubro registra diferenças entre os relatos de exploração. Detectar PHP ou uma versão aparentemente antiga ajuda a priorizar investigação, mas não revela sozinho a configuração completa, os patches retroportados ou o comprometimento de um servidor.

eMudhra: quando a confiança no HTTPS precisa ser revogada

O episódio da eMudhra tem outra origem. Segundo o Google, oito certificados de autoridades intermediárias foram associados a chaves privadas geradas com aleatoriedade insuficiente. Chaves assim permitem falsificar certificados que clientes ainda confiantes nessas autoridades podem aceitar.

Certificados digitais ajudam um navegador a verificar a identidade do servidor. Uma autoridade intermediária funciona como um elo de confiança entre o certificado de um site e uma raiz reconhecida pelo software. Comprometer a chave desse elo é diferente de invadir o servidor de cada site: o risco passa a ser a emissão de uma identidade falsa que o cliente considere legítima.

A Mozilla recebeu o aviso em 17 de outubro e distribuiu o bloqueio pelo OneCRL em menos de três horas, sem exigir reinício nas configurações padrão do Firefox. O risco descrito pela empresa envolve um atacante capaz de interceptar a conexão e se passar pelo destino, potencialmente lendo ou modificando o tráfego.

O Google também bloqueou as chaves e informou uma proteção adicional: não havia certificados das seis intermediárias TLS envolvidas no incidente registrados em Certificate Transparency antes do bloqueio. Clientes que exigem esse registro, como o Chrome, tinham essa barreira contra certificados fraudulentos. Isso não autoriza estender a mesma garantia a todo aplicativo ou dispositivo antigo.

No dia 22, a eMudhra anunciou sua saída do negócio global de certificados SSL/TLS. A empresa afirma que não houve invasão de sua infraestrutura nem vazamento de dados e que as intermediárias afetadas não emitiram certificados finais. A decisão comercial não elimina a necessidade de atualizar os repositórios de confiança dos clientes.

Não se trata de uma demonstração de que a IA quebrou a criptografia do HTTPS. O defeito documentado está na geração das chaves. A resposta inclui revogação, bloqueio e atualização de confiança, não apenas a troca de uma senha de usuário.

GitLab e Node.js: riscos também na infraestrutura de desenvolvimento

GitLab: execução remota sem autenticação

O GitLab corrigiu em 21 de outubro a CVE-2026-110264, classificada pelo fornecedor com CVSS 10,0. O problema envolve um estouro de inteiro no compilador de expressões regulares e pode permitir execução de código sem autenticação, sob determinadas condições. A faixa afetada remonta à versão 7.0, respeitados os limites de cada ramo corrigido.

As versões publicadas foram 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 e 18.11.13. O GitLab.com já estava corrigido no anúncio; quem administra a própria instalação precisa seguir o caminho de atualização aplicável. O boletim também disponibiliza detecções de tentativas. A existência dessas regras não é, isoladamente, confirmação de exploração bem-sucedida.

No Brasil, o CISC publicou um alerta em 22 de outubro. Esse caso alcança a infraestrutura que hospeda código e processos de entrega, não apenas os sites produzidos por ela. O anúncio do fornecedor credita o relato a um pesquisador; não atribui a descoberta à IA.

Node.js: dados comprimidos e validação de identidade

O pacote de segurança do Node.js trouxe quatro falhas de severidade alta, três médias e três baixas. Entre elas, a CVE-2026-111497 permite corrupção de memória ao descomprimir dados Brotli malformados, podendo levar a falha do processo, exposição de memória ou execução remota. A aplicação precisa processar os dados afetados: ter Node.js instalado não equivale automaticamente a oferecer esse caminho pela internet.

O projeto credita esse achado à equipe OpenAI Codex Security. O boletim também corrige problemas de resolução DNS e validação de identidade TLS e atualiza dependências, incluindo certificados relacionados à eMudhra. As versões corrigidas são 22.23.4, 24.22.1 e 26.12.1. A inclusão dos certificados conecta parte da resposta operacional, mas não transforma os bugs do Node.js e a falha da certificadora em uma mesma vulnerabilidade.

LiteLLM: o ataque veio dentro da atualização

No LiteLLM, o problema não foi apenas um defeito aguardando patch. A equipe confirmou que a versão 1.107.0, distribuída em 21 de outubro pelo PyPI e por registros de contêineres, continha malware. O projeto integra aplicações a serviços de modelos de linguagem; suas instalações podem ter acesso a chaves de provedores e outros segredos.

Segundo o comunicado do projeto, credenciais de desenvolvedores foram usadas para alterar e acionar o fluxo de publicação. A equipe investiga a hipótese de obtenção dos tokens em logs de sua instalação interna; a forma inicial de acesso ainda não estava confirmada. O incidente atingiu artefatos distribuídos, enquanto a tag correspondente do código-fonte oficial não continha os arquivos maliciosos.

A Datadog Security Labs analisou um ladrão de credenciais e um mecanismo de acesso remoto adicional. O código podia iniciar junto com o Python, mesmo sem importar o LiteLLM. Os alvos incluíam segredos de nuvem, ferramentas de desenvolvimento, serviços de IA e navegadores. Isso faz do caso um ataque à cadeia de distribuição de software, não uma vulnerabilidade geral da linguagem Python.

Essa foi a segunda distribuição comprometida do LiteLLM em 2026. A Datadog não havia estabelecido ligação entre o episódio de outubro e o anterior. Tampouco esse relatório demonstra que a IA escreveu ou comandou o malware: software de IA ser o alvo é diferente de IA ser o instrumento do atacante.

Para quem executou os artefatos afetados, a orientação do projeto inclui reconstruir o ambiente e revogar credenciais expostas. A Datadog recomenda fazer a rotação a partir de uma máquina limpa. Simplesmente remover o diretório do pacote não elimina todos os arquivos maliciosos, e iniciar o Python ou o pip no ambiente afetado pode executar o código novamente.

Linux: relatos públicos e condições que não podem ser ignoradas

Mensagens da Zero Day Initiative publicadas em 21 de outubro descrevem duas falhas no KSMBD, o servidor SMB do kernel: ZDI-CAN-33549 e ZDI-CAN-33774. Os relatos atribuem a ambas potencial de execução remota e nota 9,0, também registrada na lista pública da ZDI.

Não são falhas indistintas de “qualquer Linux conectado”. Os relatos descrevem configurações e condições específicas: o primeiro envolve SMB Direct e RDMA; o segundo, uma condição de corrida no processamento do protocolo. A exposição depende de o componente vulnerável estar presente e acessível no ambiente relevante.

Em uma resposta na lista, Stefan Metzmacher pediu que o problema de SMB Direct fosse testado contra um ramo de desenvolvimento que, em sua avaliação, poderia já corrigi-lo. Um patch em discussão ou em um ramo de trabalho não comprova que o pacote instalado pelo usuário já recebeu a correção.

A divulgação também se cruza com uma mudança de processo. A documentação de segurança do kernel orienta tratar achados assistidos por IA como públicos, devido à possibilidade de descoberta simultânea, mas determina não publicar o reprodutor de imediato. O documento alerta para sobrecarga, relatos imprecisos e necessidade de validar o impacto. Essa política não prova que os dois achados citados foram produzidos por IA nem que sua publicação resultou de um acidente.

É o maior problema de segurança da história da internet?

A Wiz compara a importância potencial do PHP2Shell a marcos como Heartbleed e Log4Shell e o coloca entre os problemas mais graves do PHP, possivelmente do software. A OpenAI o descreve como um dos mais impactantes da memória recente. São avaliações atribuídas a participantes da pesquisa.

Não há, nos dados apresentados, uma comparação histórica suficiente para classificá-lo como o maior incidente da internet. Alcance de uma tecnologia, gravidade técnica, volume de tentativas, invasões confirmadas e prejuízo são medidas diferentes. Uma nota CVSS expressa severidade técnica dentro de um modelo; não conta vítimas nem mede perdas econômicas.

O alerta sobre falhas antigas, entretanto, tem antecedente institucional. Meses antes desses episódios, o NCSC britânico já recomendava preparação para uma onda de patches: a capacidade de pessoas qualificadas com IA de investigar dívida técnica poderia acelerar descobertas e exigir muitas correções em pouco tempo. Trata-se de uma previsão de pressão operacional, não da confirmação de que todo software foi comprometido.

O que precisa ser verificado agora

A primeira divisão é entre sistemas potencialmente vulneráveis e ambientes que executaram software sabidamente malicioso. No primeiro grupo, inventário, atualização e análise de exposição orientam a resposta. No segundo, como o LiteLLM afetado, também é necessário tratar o possível roubo de segredos e a persistência do invasor.

Para PHP, o NCSC recomenda localizar instalações, priorizar as expostas à internet e acompanhar fornecedores de produtos que embutem a linguagem. Quando atualização ou mitigação não forem possíveis em tempo adequado, a orientação é considerar a retirada temporária do sistema do ar. Não é uma ordem para desligar toda a web.

Na prática, as verificações se dividem por componente:

• Sites e hospedagens: confirmar com o responsável técnico qual pacote corrigido atende o domínio e se os processos foram atualizados; revisar sinais de comprometimento quando houver exposição.
• Desenvolvimento: conferir versões efetivamente em execução de GitLab e Node.js, não apenas o instalador ou a imagem disponível no registro.
• Certificados: manter navegadores, sistemas e bibliotecas de confiança atualizados; não contornar erros TLS para fazer uma integração voltar a funcionar.
• Dependências e contêineres: confrontar versões e artefatos usados com os avisos do fornecedor; no LiteLLM afetado, seguir resposta a incidente, não apenas atualização rotineira.
• Linux: verificar serviços habilitados e boletins da distribuição ou do fabricante. O nome do sistema operacional não substitui a identificação do componente exposto.

Novo aviso do PHP em 23 de outubro

O acompanhamento continuou após as correções iniciais. Em 23 de outubro, o projeto publicou um aviso sobre a CVE-2026-115560, relacionada a um cenário incomum de progresso de upload de sessão. A condição exige que a aplicação configure php_binary ou php_serialize e depois mude o serializador para php em execução, antes de iniciar a sessão, mantendo o recurso de progresso habilitado.

O aviso oficial recomenda desativar session.upload_progress.enabled até a próxima versão regular; aplicações que nunca mudam o serializador em execução podem manter o recurso. Quem já aplicou essa mitigação deve preservá-la. O projeto informou que publicará o boletim completo na próxima release. Esse cenário específico não invalida genericamente as correções de 21 de outubro.