Por que o aumento das vulnerabilidades de segurança impulsionadas pela IA exige a atuação técnica de especialistas

Os historiadores do futuro lembrarão do primeiro semestre de 2026 como o início dos relatórios de vulnerabilidade de segurança impulsionadas pela IA. Em 7 de abril, a Anthropic anunciou uma prévia do modelo de IA Claude Mythos, disponibilizado para empresas selecionadas como parte do Project Glasswing. A iniciativa afirmou ter descoberto milhares de vulnerabilidades de nível de gravidade alta e crítica em todo o ecossistema open source. Três semanas depois, a iniciativa Xint anunciou uma vulnerabilidade de escalonamento de privilégios locais do kernel do Linux chamada Copy Fail. Alguns dias depois, o mundo se deparou com outra vulnerabilidade chamada Dirty Frag, seguida de outra chamada Fragnesia. Outras virão em breve.

O Project Glasswing, o Copy Fail e o Dirty Frag compartilham problemas de divulgação responsável. O Project Glasswing compartilhou poucas informações acionáveis, apesar do alarde. Os pesquisadores por trás do Copy Fail compartilharam as descobertas com desenvolvedores do kernel.org, mas não com fornecedores de sistemas. Alguém vazou detalhes do Dirty Frag prematuramente, obrigando o pesquisador Hyunwoo Kim a divulgar detalhes em uma conversa de e-mail pública antes que alguém pudesse desenvolver patches.

Este post analisa a resposta da Red Hat ao Copy Fail e discute como nosso Technical Account Management Service for Product Security ajuda as organizações a gerenciar a postura de segurança nesta nova era de divulgações rápidas e implacáveis geradas por IA.

Histórico e contexto do Red Hat Product Security

O time do Red Hat Product Security é líder na comunidade de segurança de TI desde 2001 e evolui constantemente com o cenário de ameaças. 

CVE.org gerencia relatórios de vulnerabilidade de software no setor de TI usando o conceito de Common Vulnerabilities and Exposures (CVE). Uma CVE Numbering Authority (CNA) é uma organização membro que publica CVEs. CVE.org tem mais de 500 membros da CNA em todo o setor de TI. Um CNA-LR é uma CVE Numbering Authority de último recurso. As organizações membros contam com eles para resolver disputas sobre CVEs. As organizações raiz ensinam outras CNAs a enviar CVEs.

Hoje, a Red Hat é a única empresa do setor privado no mundo a exercer a função de CNA-LR, e uma das duas únicas empresas do setor privado a exercer a função raiz. Isso significa que a Red Hat ocupa uma posição merecida de respeito, responsabilidade e confiança em todo o setor. Muitas vezes estamos no centro, traduzindo um commit misterioso de kernel em algo acionável enquanto o resto do mundo corre atrás das manchetes.

Com o aumento de relatórios de vulnerabilidade de segurança orientados por IA, o cenário de ameaças não está apenas evoluindo, ele está se acelerando. A Mozilla colaborou recentemente com a Anthropic para descobrir 22 bugs sensíveis à segurança no seu mecanismo JavaScript, seguidos por 271 vulnerabilidades adicionais em uma etapa subsequente que analisou toda a base de código do navegador. Em todo o ecossistema de software, em meados de maio de 2026, ferramentas de descoberta orientadas por IA, lideradas em grande parte pelo Mythos, sinalizaram mais de 10.000 possíveis problemas, o equivalente a quase um ano de descobertas tradicionais em apenas duas semanas.

A Red Hat está no centro dessa explosão. Em 2025, o Red Hat Product Security realizou a triagem de 7.722 vulnerabilidades de segurança. Nos primeiros quatro meses de 2026 — de 1º de janeiro a 30 de abril — o número foi de 2.826. Se essa taxa continuar, o total anual chegará a 8.596. De 1º a 15 de maio de 2026, o número de vulnerabilidades triadas aumentou para 712, totalizando mais de 17.000 no ano inteiro, ou mais que o dobro de 2025.

Copy Fail: O primeiro de muitos que virão

Em um dia normal, o CVE.org publica centenas de registros de vulnerabilidade. Em 22 de abril de 2026, uma CNA, kernel.org, publicou 100 vulnerabilidades, numeradas de CVE-2026-31431 a CVE-2026-31530. 

CVE-2026-31431 oferece esta descrição.

“No kernel do Linux, a seguinte vulnerabilidade foi resolvida: crypto: algif_aead - Revert to operating out-of-place. Isso reverte principalmente o commit 72548b093ee3, exceto pela cópia dos dados associados. Não há benefício em operar in-place no algif_aead, já que a origem e o destino vêm de mapeamentos diferentes. Elimine toda a complexidade adicionada para a operação in-place e apenas copie o AD diretamente.”

Isso não era nada animador, até que uma semana depois, em 29 de abril, um serviço chamado Xint.io de uma empresa chamada Theori postou um ataque de prova de conceito e o denominou Copy Fail. Oculta sob essa descrição obscura, havia uma maneira de qualquer usuário local sem privilégios, seja em bare metal, em uma máquina virtual (VM) ou dentro de um container, obter acesso root a um sistema.

Felizmente, esse ataque exige acesso à máquina. O invasor precisa fazer login primeiro. Infelizmente, a Red Hat e outras distribuições Linux ficaram sabendo do ataque no mesmo dia em que o público tomou conhecimento.

Artigos na imprensa e tópicos online explodiram. A corrida começou.

O Red Hat Product Security atualizou imediatamente a classificação de vulnerabilidade deste CVE para Importante e atualizou seu security bulletin com uma estratégia de mitigação e um cronograma de remediação. A Red Hat entregou o primeiro de muitos avisos de segurança cinco dias depois, em 4 de maio. Vários outros surgiram rapidamente.

Mas a história não termina aí.

Implementação para clientes

Ao meio-dia no horário de verão central dos EUA, em 12 de maio de 2026, o Copy Fail gerou 1.132 casos de suporte de clientes que executam Red Hat Enterprise Linux (RHEL), Red Hat OpenShift e Red Hat OpenStack. No final de maio, esse número aumentou para mais de 1.300 casos. Muitos desses casos de suporte incluíam perguntas detalhadas ou problemas complexos que não cabem em um documento de FAQ organizado. Por exemplo:

• Algumas organizações dependem de aplicações com suporte limitado ou inexistente que tendem a apresentar falhas com patches e upgrades do sistema operacional. Nesta nova era de patches e upgrades constantes, essas aplicações apresentam um risco ainda maior.
• Sempre surgem dúvidas sobre como utilizar as pontuações do Common Vulnerability Scoring System (CVSS) para avaliar riscos. A melhor resposta é: depende. As pontuações CVSS atribuem níveis de gravidade isoladamente. A avaliação de riscos depende das especificidades do cliente e exige julgamento humano.
• Como acompanhar uma enxurrada interminável de problemas sinalizados por IA? A resposta "corrigir tudo" é um modelo falho. Em vez de interrupções constantes para aplicação de patches, projete seu ambiente de TI para mitigar vulnerabilidades com defesa em profundidade. Use o julgamento humano para avaliar quais vulnerabilidades realmente representam uma ameaça ao seu ambiente específico e corrija-as.
• Pelo menos um cliente precisava saber como aplicar patches no OpenStack 17.1, que depende do RHEL 9.2. A resposta foi usar o fluxo de versão do RHEL 9.2 SAP.
• Outro cliente precisava saber o que aconteceria se utilizasse kernels mais novos e corrigidos com sistemas RHEL 8 mais antigos. 
• Algumas organizações executavam versões antigas do OpenShift e precisavam de uma estratégia de patches.
• Muitas precisavam de ajuda para coordenar a implantação de patches com equipes de aplicações que buscam zero downtime.
• Outras organizações estavam preocupadas com o desempenho.
• Várias precisavam de ajuda com análises de risco para diversas iniciativas de conformidade.
• E, em muitos casos, os clientes solicitaram declarações oficiais de garantia da Red Hat para a alta gestão.

Estes são apenas alguns exemplos. Crises de segurança são sempre estressantes. Consideramos valioso trabalhar diretamente com os clientes para separar a especulação da realidade, especialmente quando surgem manchetes sobre o bug de Linux mais alarmante da década. 

A necessidade de um parceiro comercial para preencher a lacuna entre a inovação upstream e as proteções de segurança de nível empresarial nunca foi tão clara.

Red Hat Technical Account Management Service for Product Security

Para lidar com situações de segurança como esta, a Red Hat agora oferece o Red Hat Technical Account Management Service for Product SecurityPágina disponível no idioma inglês (Portuguese, Brazil não disponível). Os Technical Account Managers (TAMs) atuam como elos de comunicação entre os clientes e os grupos de engenharia e produtos da Red Hat e da comunidade open source. Enquanto a maioria dos TAMs se concentra em um produto ou tecnologia específica, os TAMs de segurança da Red Hat focam holisticamente na presença de segurança em todo o portfólio de produtos Red Hat. Estes TAMs ajudam a:

• Compartilhar educação ad hoc sobre várias táticas de ataque
• Ajudar os clientes a usar as ferramentas de segurança e conformidade da Red Hat
• Sugerir configurações e implantações protegidas conforme apropriado
• Explicar como a Red Hat ajuda a reduzir riscos e mitigar vulnerabilidades
• Fornecer análises de vulnerabilidade mais precisas para produtos Red Hat
• Auxiliar na triagem de relatórios de varredura de vulnerabilidades
• Facilitar a comunicação com clientes, equipes da Red Hat, parceiros, outros fornecedores e a comunidade open source, quando possível
• Influenciar o gerenciamento de produtos Red Hat, as equipes de segurança de produtos, parceiros, outros fornecedores e a comunidade open source, representando os pontos de vista dos clientes.
• Promover a conscientização sobre a cadeia de valor de software e ataques à cadeia de suprimentos
• Orientar sobre possíveis mitigações diante de incidentes graves de segurança
• Ajudar na produção de avaliações post-mortem de incidentes de segurança.

A comunicação contínua é sempre essencial, especialmente durante uma crise. Isso é ainda mais importante à medida que a Red Hat AI aumenta a velocidade e a gravidade dos relatórios de vulnerabilidade de segurança. Os TAMs de segurança da Red Hat têm uma posição única para ajudar os clientes a distinguir o ruído da realidade e a lidar com outras preocupações. 

Tranquilidade

Nesta nova era de relatórios de vulnerabilidade orientados por Red Hat AI, a maior ameaça não é apenas o volume de bugs, mas a dependência excessiva da automação. A Red Hat AI pode encontrar vulnerabilidades, mas não consegue fornecer uma estratégia de segurança baseada em riscos nem oferecer a integridade necessária para apoiar sua organização durante uma crise. O julgamento humano continua sendo a única coisa com a qual você pode realmente contar. Falhas nos processos de divulgação responsável representam outra ameaça. Sempre que alguém revela uma nova vulnerabilidade antes que os desenvolvedores lancem uma mitigação ou um patch, os invasores podem surpreender os clientes.

Ninguém pode prometer imunidade total contra ataques, mas os TAMs de segurança da Red Hat podem ajudar. Eles coordenam ações com o Red Hat Product Security e a comunidade para oferecer a orientação estratégica e a defesa técnica que a Red Hat AI não consegue fornecer. 

A capacidade de discernir a diferença entre o exagero e a realidade, ou de ganhar algumas horas de aviso prévio sobre um ataque iminente, pode ser a diferença entre aplicar uma mitigação imediata e um desastre. Não espere pela próxima grande divulgação para proteger sua infraestrutura. Saiba mais sobre como um TAM de segurança da Red Hat oferece o planejamento proativo e a defesa técnica de que sua organização precisaPágina disponível no idioma inglês (Portuguese, Brazil não disponível).

Entre em contato com sua equipe de contas da Red Hat para saber mais ou fale com a Red Hat.
 

Encontre esses números navegando até o banco de dados de CVE da Red Hat legível por humanos, selecionando um período adequado e verificando a contagem na parte inferior da página.