Com o advento da IA, o tempo para encontrar falhas em códigos e desenvolver exploits caiu drasticamente. Não é coincidência. O FOSS (Free and Open Source Software) é utilizado há anos no treinamento de LLMs (Large Language Models), então esses modelos conhecem muito bem esses códigos, e o problema é justamente esse.
Os exploits sempre existiram, mas nunca surgiram tão rápido como hoje. Geralmente surgiam depois de um período de embargo.
O Embargo de Segurança é uma divulgação coordenada de vulnerabilidades. Primeiro, o pesquisador que descobre a vulnerabilidade a comunica em sigilo à equipe de segurança do Linux para que um patch seja preparado. Depois que o patch é desenvolvido, os mantenedores das distribuições Linux empacotam o patch para que fique disponível nos sistemas operacionais. Somente depois disso a vulnerabilidade é divulgada publicamente.
É aqui que está o “problema da IA”: com acesso às listas de discussão do Linux e/ou aos repositórios Git do código-fonte (ambos são públicos), pessoas com pouco ou nenhum conhecimento em pentest podem desenvolver exploits durante o período de embargo, ou seja, quando ainda não há correções disponíveis.
Copy Fail, Dirty Frag e Fragnesia:
Entre o fim de abril e o início de maio deste ano (2026), três vulnerabilidades LPE (Local Privilege Escalation) no kernel do Linux agitaram a comunidade de segurança: Copy Fail (CVE-2026-31431), Dirty Frag (CVE-2026-43284 e CVE-2026-43500) e Fragnesia (CVE-2026-46300).
O Copy Fail foi revelado em 29/04/2026 junto com o exploit e o patch de correção. Já o Dirty Frag e o Fragnesia vieram a público em 07/05 e 13/05, respectivamente, com exploit e com o patch disponível apenas em upstream, ou seja, não disponíveis nos sistemas operacionais, o que, na prática, os tornou vulnerabilidades zero-day.
As falhas Copy Fail e Dirty Frag existiam há mais de 9 anos no código e foram encontradas com auxílio de IA.
A quebra do embargo do Dirty Frag:
O pesquisador Hyunwoo Kim descobriu a falha Dirty Frag e a reportou em 30 de abril de forma privada à equipe de segurança do kernel, iniciando um embargo que duraria até 12 de maio. Porém, durante o embargo, um desenvolvedor chamado Trevor analisou os commits públicos do kernel, fez engenharia reversa e divulgou uma PoC com um exploit. A vulnerabilidade tornou-se pública e o embargo de segurança foi quebrado. O Dirty Frag tornou-se um zero-day.
O patch de correção para a falha já havia sido criado pela equipe de segurança do kernel Linux, porém, não houve tempo para que os mantenedores das distribuições Linux o empacotassem. Por consequência, a correção não foi disponibilizada, mas o pesquisador e as distribuições recomendaram um workaround.
O patch é a correção feita no código do Linux. Depois que o patch é desenvolvido, os mantenedores das distribuições (Red Hat, Oracle, Canonical, etc) empacotam o patch e disponibilizam em seus repositórios.
O workaround consistia em desativar recursos vulneráveis do sistema (ESP do IPSec tanto no IPv4 quanto no IPv6 e protocolo RXRPC). Aqueles que precisavam desses recursos tiveram que ponderar os riscos e decidir se manteriam esses recursos ativos ou não.
Fragnesia e o Efeito Borboleta:
Quando a correção do Dirty Frag foi finalmente disponibilizada, acabou criando outra vulnerabilidade: o Fragnesia. Essa também foi identificada com o auxílio de IA.
Devido ao problema no embargo do Dirty Frag, os pesquisadores que identificaram o Fragnesia optaram por não seguir o embargo. Publicaram a vulnerabilidade, o exploit e o patch no código do Linux, mas sem pacotes com a correção nos repositórios. O workaround era o mesmo do Dirty Frag. Quem já o tinha aplicado estava protegido. Já quem aplicou somente o patch do Dirty Frag ficou exposto ao Fragnesia.
Software Livre e Open source na era da IA:
Os três casos possuem em comum o uso de IA para acelerar o processo de descoberta e desenvolvimento de exploits, e isso era previsto.
O problema está no comportamento das pessoas, como sempre. O episódio do Dirty Frag nos mostra como a pressão por visibilidade em detrimento da segurança coletiva pode ser grave, pois a IA elimina muitas complexidades, reduz vertiginosamente o tempo de pesquisa e permite que qualquer pessoa se torne um “pentester”.
A nós, profissionais de tecnologia, nos cabe seguir a “cartilha de boas práticas” para eliminar riscos desnecessários. Isso inclui a adoção de uma boa cadência de atualização, proteger melhor nossos perímetros com segmentação de rede e políticas de firewall, adotar o uso de IDS/IPS para mitigar diversos tipos de ataques, eliminar Shadow IT, em nível de servidor, aplicar hardening/tuning de segurança, adotar um bom EDR/XDR, além de aplicar políticas rígidas de IAM e de seguir o princípio de menor privilégio. Isso, para dizer no mínimo.
Conclusão:
A inteligência artificial deixou de ser uma novidade. Hoje ela faz parte da nossa realidade. De toda forma, ela não é má. É uma tecnologia como tantas outras, e assim como toda tecnologia na história humana, são os humanos que determinam o quanto ela será utilizada para o bem e o quanto será utilizada para o mal.
Lembremos que pessoas más e habilidosas são combatidas por pessoas boas e habilidosas. “Combater” a IA é impossível para nós, meros mamíferos movidos a cafeína, taurina e inositol. Só uma IA poderia fazer isso, mas você também não vai sair gastando tokens de IA da sua empresa antes de fazer a lição de casa, pois o básico bem feito ainda funciona muito bem.
Sejamos capazes de nos defender de pessoas e não da IA.
Thank You For Your Vote!
Sorry You have Already Voted!