Os laboratórios que tornam o software mais fácil de invadir também vendem as ferramentas para defendê-lo. Os incidentes de segurança deste mês mostram por que esse modelo de negócio merece escrutínio e por que a resposta não pode ser outra caixa-preta com uma conta de API maior.
Um discurso de vendas desconfortável está tomando forma na indústria da IA: os modelos estão ficando poderosos o bastante para encontrar rachaduras na sua infraestrutura, então você provavelmente deveria usar os modelos para ajudar a fechá-las.
Chamo a conta resultante de imposto de segurança da IA. Ele inclui mais do que uma assinatura: tempo de engenharia, gastos com inferência, patches de emergência e complexidade operacional para acompanhar máquinas que investigam software continuamente. Equipes pequenas pagam com noites e fins de semana. Grandes organizações pagam com mais uma camada de infraestrutura de segurança.
Os incidentes de outubro tornam essa perspectiva concreta. Também facilitam contar uma história arrumada demais: uma onda global de ataques de IA, um culpado estrangeiro, um fornecedor com a cura. As evidências sustentam um argumento mais interessante. Bugs antigos, confiança comprometida, credenciais roubadas e agentes cada vez mais capazes interagem. Nem todos têm a mesma causa.
Informações verificadas em 24 de outubro de 2026. Esta é uma análise dos principais incidentes e famílias de vulnerabilidades Linux relevantes para esta onda, não um catálogo exaustivo de todo CVE Linux. As datas distinguem a divulgação original da atenção renovada. Detalhes dos incidentes e o estado dos patches dos fornecedores podem mudar.
Um mês movimentado, várias falhas diferentes
Em 21 de outubro, o PHP lançou correções de emergência para duas falhas de execução remota de código sem autenticação: CVE-2026-109618 e CVE-2026-109619, ambos avaliados em 9.2. Um envolve corrupção de memória durante o tratamento de falta de memória; o outro, um estado de requisição obsoleto. São problemas do ambiente de execução, portanto corrigir apenas o código da aplicação não basta. O aviso do CERT-EU descreve as ramificações afetadas e a urgência.
Há uma conexão documentada com IA aqui. A OpenAI afirma A Calif usou GPT-5.6 Sol na pesquisa, enquanto a Wiz relatou as duas falhas de forma independente. Os mantenedores do PHP lideraram as correções e o lançamento. O mérito pertence a esse esforço coordenado entre pessoas e modelo, não a um chatbot agindo sozinho.
As primeiras versões corrigidas são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Distribuidores podem retroportar correções sob versões de pacote diferentes. É importante notar que o CERT-EU atualizou seu aviso em 23 de outubro para acrescentar CVE-2026-115560, um terceiro problema de RCE envolvendo uma configuração incomum. O PHP considerou esse risco improvável e não programou um lançamento de emergência; o aviso fornece uma mitigação provisória. Uma história congelada no anúncio dos patches de quarta-feira já estaria incompleta. Consultar as versões oficiais do PHP e as orientações atuais do fornecedor.
A história do Linux é maior do que uma manchete assustadora
Os relatórios críticos mais recentes sobre o kernel merecem atenção. O órgão eslovaco O CSIRT alertou em 23 de outubro sobre relatórios de vulnerabilidades expostos publicamente, incluindo dois problemas no servidor de arquivos KSMBD avaliados em 9.0: ZDI-CAN-33549 e ZDI-CAN-33774. Seus pré-requisitos diferem: um envolve SMB Direct/RDMA; o outro trata do despacho de protocolos e tem um caminho de escrita ligado ao acesso a um compartilhamento. A exposição depende do serviço e da configuração realmente usados. O próprio inventário da ZDI confirma os identificadores e as pontuações.
Na publicação do aviso, aqueles dois relatórios não tinham identificadores CVE. Essa distinção importa. Um problema crítico não se torna inofensivo enquanto espera um CVE, e uma pontuação crítica não demonstra que toda máquina Linux esteja exposta. Administradores devem restringir o acesso aos serviços afetados e acompanhar o estado real das correções do seu distribuidor.
Também existe uma falha crítica CVE atribuído na discussão recente sobre Linux: CVE-2025-39682, uma falha no caminho de recepção TLS do kernel. O NVD lista uma pontuação de 9.8 e uma referência da CISA a exploração conhecida. Foi publicada originalmente em setembro de 2025, e não descoberta pela primeira vez neste outubro. A Red Hat avalia seus produtos de outra forma, ilustrando por que uma pontuação universal e a avaliação prática de exposição de um fornecedor podem divergir.
Esses são apenas parte do cenário relevante do Linux:
Copy Fail — CVE-2026-31431
Descoberta assistida por IA de uma falha no cache de páginas do kernel, divulgada publicamente em 29 de abril. Permite elevação local de privilégios nos kernels afetados. Um invasor remoto ainda precisa de uma via inicial para execução local. Divulgação do pesquisador.
Dirty Frag / Fragnesia — CVE-2026-43284, CVE-2026-43500, CVE-2026-46300
Problemas relacionados de elevação de privilégios pelo cache de páginas divulgados em maio. Componentes de rede e configuração afetam a acessibilidade; a investigação da Microsoft distingue a atividade observada da exploração não confirmada de variantes individuais. Investigação da Microsoft.
CrackArmor
Nove vulnerabilidades do AppArmor, representadas por onze identificadores CVE no nível dos patches. O Ubuntu documenta pré-requisitos de usuário local e impactos diferentes entre versões, incluindo evasão de políticas e elevação de privilégios. A matriz completa do Ubuntu.
O quarteto de rede — DirtyAH6, TUNderflow, PPPoEject, DiagSpill
CVE-2026-80844, CVE-2026-81000, CVE-2026-68121 e CVE-2026-74469. As reportagens de setembro descrevem caminhos para acesso root local com requisitos diferentes de namespaces, capacidades e módulos. Boletim da Red Hat.
Vghost — CVE-2026-74580
Uma falha de vhost que pode permitir elevação local de privilégios, com risco de escape de máquina virtual em configurações específicas. O aviso da Tencent afirma explicitamente que o ambiente CVM verificado não estava exposto ao caminho de escape da máquina virtual. Aviso da Tencent.
Outros caminhos do kernel — CVE-2026-53266, CVE-2025-39964
O primeiro envolve ebtables SNAT sob regras de ponte específicas; o segundo envolve escritas simultâneas de AF_ALG. Seus requisitos e consequências diferem. Avaliação de SNAT; Avaliação de AF_ALG.
A lição prática é distinguir a entrada remota de o que acontece depois da entrada. Uma vulnerabilidade que concede acesso root local pode ser devastadora em um servidor compartilhado, executor de compilação ou host de agentes, mesmo sem permitir que qualquer visitante da internet entre no sistema. Uma falha de aplicação ou conta roubada pode fornecer o ponto de entrada inicial. Tratar cada manchete sobre o kernel como uma tomada de controle remota universal obscurece quais sistemas precisam de atenção primeiro.
O cadeado pode falhar sem que a criptografia seja quebrada
O incidente dos certificados é um tipo diferente de falha. A Mozilla diz ter recebido em 17 de outubro um relato de que as chaves privadas de oito certificados intermediários eMudhra haviam sido comprometidas. Um invasor capaz de interceptar uma conexão poderia usar certificados emitidos de forma fraudulenta para se passar por um site. A Mozilla bloqueou os certificados afetados pelo OneCRL naquela noite e depois atualizou o Firefox e os componentes do armazenamento de confiança. Sua resposta também registra uma correção posterior para Android.
A chave de assinatura de uma autoridade certificadora dá o poder de atestar identidades. Comprometê-la ataca essa decisão de confiança. Isso não significa que alguém tenha vencido matematicamente a criptografia TLS. O relato da Mozilla tampouco demonstra que um LLM causou o comprometimento.
Os problemas do OpenSSL também pertencem a esse quadro, mas não devem ser confundidos com o incidente da CA. Os avisos de setembro incluem tratamento de extensões X.509, esgotamento de recursos ao processar certificados, QUIC e outros defeitos de bibliotecas criptográficas. O índice de avisos do OpenSSL distingue as versões afetadas e a gravidade. Um certificado malicioso pode expor um defeito de software mesmo quando esse certificado jamais deveria ser considerado confiável.
A versão de segurança do Node.js de 21 de outubro reúne essas camadas: atualiza o material de CA incluído para eMudhra e corrige problemas independentes de DNS, verificação de nomes de host TLS e outros componentes do ambiente de execução. Uma falha no decodificador Brotli, CVE-2026-111497, poderia permitir corrupção de memória e execução remota de código quando uma aplicação processa dados compactados fornecidos por um invasor; o projeto dá o crédito aos pesquisadores do OpenAI Codex Security. O aviso de segurança do Node classifica os problemas mais graves como High. As versões corrigidas publicadas são 26.12.1, 24.22.1 e 22.23.4. Arquivo oficial de versões.
As chaves API estão se tornando um recurso estratégico
O comprometimento da LiteLLM torna o problema das credenciais especialmente tangível. O pacote malicioso 1.107.0 chegou a registros públicos em 21 de outubro. A Microsoft encontrou hooks de inicialização do Python que podiam ativar um coletor de credenciais sem que uma aplicação importasse explicitamente a LiteLLM. Chaves de provedores de modelos faziam parte de um conjunto de alvos muito mais amplo, incluindo credenciais de desenvolvedores e da nuvem. Remover um pacote não equivale, portanto, a restaurar a confiança na máquina. A investigação da Microsoft explica as implicações para exposição e recuperação.
A investigação posterior da própria LiteLLM rastreia o comprometimento a montante até uma chave mestra exposta que não foi revogada, seguida de acesso a credenciais poderosas de desenvolvedores e ao processo de lançamento. Também relata um foco em obter tokens API de inferência a montante. O relato de referência do incidente corrige algumas suposições iniciais. É um lembrete para acompanhar a investigação, em vez de preservar a primeira explicação que viralizou.
Uma credencial de IA agora pode comprar mais do que uma conta fraudulenta de nuvem. Pode comprar raciocínio, assistência à programação e um lugar para esconder as atividades de outro operador. Se o acesso for revendido, o titular legítimo da conta pode arcar com custos e riscos de sanções enquanto outra pessoa usa a capacidade. Quem comprou uma chave roubada específica e para que a usou ainda exige evidências.
O que as evidências dizem sobre os laboratórios chineses
Há uma base documentada para a preocupação com destilação não autorizada. Em seu relatório de setembro, a Anthropic descreve campanhas que atribui a laboratórios sediados na China e explica como serviços de proxy podem usar contas fraudulentas, dados de pagamento roubados e credenciais API roubadas para fornecer acesso. O mesmo relatório descreve operações maliciosas assistidas por IA de vários tipos de atores, não de um único grupo nacional. São conclusões atribuídas pela Anthropic, não um veredito independente sobre cada suposto participante. Ler o relatório de ameaças.
A divulgação da OpenAI de 30 de setembro atribui um núcleo de uma campanha de extração de raciocínio a pessoas associadas à Moonshot AI. Crucialmente, afirma que a campanha não quebrou a criptografia, não comprometeu um banco de dados nem acessou diretamente conversas armazenadas de usuários. Seu mecanismo foi a manipulação das interações com modelos. O relato da OpenAI não deve ser recontado como outro tipo de invasão.
A NSA, o FBI e a CISA também emitiram em setembro um alerta conjunto sobre destilação em escala industrial por empresas de IA sediadas na China. O anúncio do aviso governamental demonstra que essa é uma preocupação séria e documentada publicamente. A destilação em si continua sendo uma técnica legítima de treinamento; as questões são autorização, acesso e como os dados foram obtidos.
Minha avaliação: credenciais de inferência roubadas e destilação não autorizada são uma parte plausível da economia das ameaças. As fontes acima não demonstram que laboratórios chineses tenham orquestrado os bugs do PHP, o comprometimento da chave eMudhra, as divulgações KSMBD ou o ataque à LiteLLM. Conectar esses eventos em uma única campanha exigiria evidências ligando operadores, infraestrutura ou o uso de credenciais roubadas. Incentivos compartilhados justificam investigar, não substituem a atribuição.
Quando o outro lado pode usar um enxame
A mudança importante é econômica. Um modelo pode inspecionar código, propor testes e ajudar a investigar o resultado. Dentro de um agente que usa ferramentas, pode repetir esse ciclo. Com muitos agentes em paralelo, um operador pode explorar várias hipóteses ao mesmo tempo. Isso não torna toda tentativa correta nem todo alvo vulnerável. Torna a investigação contínua mais barata.
Há um exemplo defensivo concreto em O relatório de contenção da OpenAI de 23 de outubro. A empresa descreve frotas de agentes testando cópias especialmente construídas da sua infraestrutura, com acesso ao código e à configuração, monitoramento e objetivos delimitados. Relata descobertas de escape de máquinas virtuais e isolamento, além de trabalho em problemas do kernel, incluindo CVE-2026-74753, CVE-2026-80521 e CVE-2026-80841. Esses experimentos controlados não provam que um bot público sem supervisão consiga invadir qualquer servidor. Mostram por que os defensores levam a sério testes contínuos assistidos por máquinas.
Para um pequeno operador, isso muda o benefício de não ser interessante. A obscuridade protege menos quando verificar mais um host custa pouco. O invasor pode continuar tentando enquanto sua equipe faz o trabalho de verdade. A resposta defensiva precisa encurtar o caminho entre um sinal confiável e uma correção verificada, em vez de simplesmente gerar mais alertas.
Agentes defensivos úteis precisam de limites
Na minha visão, o primeiro agente de segurança útil é um investigador meticuloso. Ele mapeia o software implantado e os serviços acessíveis, conecta avisos ao ambiente real e produz evidências sobre as quais um mantenedor pode agir. Um segundo papel é testar uma correção proposta em um ambiente descartável. Nenhum dos dois precisa de credenciais irrestritas de produção.
A sequência de adoção deve ser deliberada:
- Observar: coletar inventário, versões e logs usando acesso restrito e somente para leitura.
- Verificar: determinar se o caminho de código vulnerável está presente e acessível. Uma simples versão pode não revelar uma correção retroportada pelo distribuidor.
- Testar: reproduzir e validar em uma cópia controlada, com orçamentos e escopo impostos fora do modelo.
- Alterar: exigir aprovação para ações de produção com consequências importantes e depois usar uma implantação gradual com reversão testada.
- Medir: verificar o sistema em execução, as evidências preservadas, a integridade dos serviços e se a exposição realmente diminuiu.
Logs, chamados e arquivos de repositório podem conter texto controlado por invasores. Um defensor que trata esse texto como autoridade pode se tornar outra superfície de ataque. Identidades limitadas, ferramentas isoladas, acesso restrito à rede e regras de ação impostas independentemente importam mesmo quando o modelo parece confiante. Raciocinar mais depressa não torna permissões amplas mais seguras.
O laboratório vende a capacidade. Depois vende o escudo.
É aqui que o modelo de negócio fica desconfortável. As mesmas empresas que desenvolvem capacidades capazes de reduzir o custo de ataques estão posicionando essas capacidades como ferramentas defensivas essenciais. Os clientes podem acabar pagando uma conta contínua para administrar um risco que a própria categoria de produto está acelerando.
Há uma estrutura comercial concreta por trás dessa preocupação. O anúncio do Glasswing da Anthropic comprometeu até 100 milhões de dólares em créditos de modelos e 4 milhões de dólares em doações para organizações de segurança de código aberto; também descreveu uso pago após o apoio da fase de prévia. Em outubro, os membros atuais do Glasswing estavam migrando para o Cyber Verification Program ampliado. A página do programa é tanto uma iniciativa defensiva séria quanto parte de um mercado de capacidades avançadas de segurança.
Chamar isso de imposto de segurança da IA não exige alegar que os laboratórios inventaram bugs de décadas atrás ou organizaram ataques deliberadamente. Identifica um incentivo: conforme modelos poderosos se espalham, a demanda por defesa assistida por modelos pode crescer, e os fornecedores dessas capacidades podem capturar esse gasto. O público deve poder examinar restrições de acesso, preços, alegações de segurança e evidências de que a proteção prometida funciona.
Há um contraponto justo. A pesquisa defensiva pode transformar uma vantagem temporária de descoberta em patches públicos permanentes, inclusive correções que protegem pessoas que nunca compram uma assinatura de modelo. Esse benefício é real. Ele sugere julgar o setor por correções implantadas e padrões mais seguros, em vez de tratar medo ou otimismo como evidência suficiente.
O gargalo é tudo o que vem depois da descoberta
Os modelos podem produzir descobertas mais depressa do que os mantenedores conseguem necessariamente revisá-las. O painel de divulgações da Anthropic, em seu retrato explicitamente datado de 2 de outubro, informou 6.157 descobertas divulgadas em 591 projetos e 516 patches conhecidos a montante. O painel alerta que os números correspondem a etapas diferentes de validação e que a quantidade de patches não indica o alcance da instalação das correções. Sua metodologia importa tanto quanto o número da manchete.
A lição não é subtrair esses números e anunciar milhares de servidores exploráveis e sem patches. Descoberta, confirmação, reparo a montante e implantação são trabalhos separados. Financiar só o primeiro transfere trabalho para as pessoas responsáveis pelo restante.
Prefiro um mercado de segurança que remunere resultados: relatos reproduzíveis, capacidade para mantenedores, correções públicas, caminhos de atualização utilizáveis e contenção testada de forma independente. Os clientes devem poder levar suas evidências a outro fornecedor. Pequenos mantenedores não deveriam precisar de um contrato empresarial de IA para manter uma biblioteca muito utilizada segura.
A próxima era da segurança provavelmente incluirá modelos vigiando modelos e agentes testando defesas contra outros agentes. Mas uma defesa duradoura não pode depender inteiramente de quem consegue pagar o maior enxame. Ela também exige infraestrutura menos exposta, credenciais com menos poder, software que falhe de modo mais seguro e pessoas autorizadas a agir com base em boas evidências.
A questão já não é apenas se a IA consegue encontrar a brecha. É quem recebe a correção, quem controla a defesa e quem recebe a fatura.
Nota editorial: este artigo separa relatos verificados de incidentes, atribuições de fornecedores e análise do autor. As ilustrações conceituais foram geradas com ChatGPT; os infográficos foram criados a partir dos registros vinculados. Nenhum exploit foi executado contra um sistema ativo para este artigo. Antes de agir, consulte o aviso atual para seu produto e sua configuração exatos.
