Uma conta sem rosto, 23 exploits e zero aviso prévio

Imagine abrir o GitHub numa manhã qualquer e encontrar um repositório com exploits funcionais para FFmpeg, Firefox, nmap, PHP, libssh2, RustDesk e mais de uma dúzia de ferramentas que você provavelmente usa todo dia. Nenhum deles reportado aos mantenedores. Todos com proof-of-concept pronto para rodar.

Foi exatamente isso que aconteceu quando uma conta anônima chamada “bikini” publicou o Exploitarium — um repositório único consolidando 23 pesquisas de vulnerabilidade, cada uma com writeup técnico e PoC funcional. A descrição do repo é desarmante: “Feel free to report them yourself and take credit for the CVE if handed out lulz.”

A comunidade de segurança pirou. No Hacker News, o post ultrapassou 879 pontos em horas. No dark web, vendedores já tentavam revender os PoCs públicos como “0-days exclusivos” por milhares de dólares. E pesquisadores sérios começaram a dissecar cada exploit para separar o que é real do que é fumaça.

O que tem dentro do Exploitarium

O repositório não é um dump aleatório. Cada subdiretório segue um padrão: documentação de classificação, análise técnica, e um PoC que demonstra a vulnerabilidade. Os alvos são uma mistura improvável de ferramentas de infraestrutura, software de desktop e bibliotecas de baixo nível:

São 23 entradas. Nem todas são iguais — e é aí que a história fica interessante.

Os que funcionam de verdade

Pesquisadores no Hacker News e analistas de segurança da Femtosec começaram a testar os PoCs contra as versões mais recentes do software alvo. O resultado preocupa.

libssh2 (CVE-2026-55200) é provavelmente o mais perigoso do lote. É um integer wraparound pré-autenticação no lado do cliente. Quando um cliente vulnerável se conecta a um servidor SSH malicioso, o servidor envia um campo de tamanho de pacote enorme que causa um wraparound na aritmética de alocação do heap. O resultado? Corrupção de memória heap e execução remota de código — tudo isso antes de qualquer autenticação acontecer.

Na prática: se alguém convencer você a conectar via SSH em um servidor controlado por ele (phishing, man-in-the-middle, ou até um link malicioso num README do GitHub), seu cliente SSH pode ser comprometido.

c-ares, FFmpeg e libssh2 — um pesquisador no HN confirmou: “Checked out the ones that were interesting to me (c-ares, libssh2, ffmpeg) and they seem to all work as of the latest upstream commit. Weird.” Três PoCs funcionando contra a versão mais recente do código. Isso não é brincadeira.

O exploit do nmap chamou atenção especial. Um comentarista notou a ironia brutal: “There’d be a certain irony being able to reverse shell anyone doing an nmap scan.” Pense nisso — a ferramenta que você usa para escanear redes poderia ser usada contra você. O bug está no parser de extensões IPv6, e se for explorável para execução de código, seria o tipo de vulnerabilidade que agências de inteligência pagariam milhões para ter. Afinal, todo pesquisador de segurança e todo pentester usa nmap.

PHP 8.5.7 tem um RCE via StreamBucket combinado com SOAP. Se confirmado contra instâncias em produção, o impacto seria massivo — PHP ainda roda em mais de 75% dos sites com server-side detectável.

Os que são fumaça

Nem tudo que brilha é ouro, e a comunidade foi rápida em apontar os PoCs fracos.

O caso mais emblemático é o Ghidra. O repositório traz três PoCs contra a ferramenta de engenharia reversa da NSA. Um pesquisador que usa Ghidra diariamente desmontou todos:

O primeiro requer que você já consiga sobrescrever binários no diretório de ferramentas do Swift. Ou seja: se você já pode escrever código executável na máquina, pode executar código. Que surpresa.

O segundo envolve TraceRMI — mas como um comentarista apontou, “RMI” literalmente significa Remote Method Invocation. É uma funcionalidade, não um bug.

O terceiro apenas demonstra que o código de parsing nativo de 7zip é acessível via Ghidra. Talvez exista um bug no parser, mas sem demonstrar isso concretamente, é como dizer “encontrei uma porta” sem mostrar que ela está destrancada.

Um comentarista resumiu perfeitamente citando o clássico MS07-052: “code execution leads to code execution.” Se você já tem acesso para executar código arbitrário, dizer que encontrou uma forma de executar código não é exatamente uma descoberta revolucionária.

O mercado negro tentou vender o que é público

A história ficou ainda mais bizarra quando a Femtosec descobriu que atores em fóruns da dark web começaram a vender os PoCs do Exploitarium como “zero-days não patcheados exclusivos”. A análise da empresa foi direta: “the zero-day label in this sale is likely an attempt to scam other underground buyers.”

É quase poético. Alguém pegou código público de um repositório GitHub, empacotou com marketing agressivo, e tentou vender para outros criminosos. Golpe dentro do golpe. A internet realmente é um lugar mágico.

Mas a Femtosec faz um alerta importante: mesmo que o marketing seja fraudulento, os exploits em si são reais e perigosos. Organizações que rodam versões não patcheadas do software afetado estão vulneráveis independentemente de como o código chegou até o atacante.

O elefante na sala: responsible disclosure morreu?

A grande questão que o Exploitarium levanta não é técnica — é ética.

O modelo tradicional de segurança funciona assim: pesquisador encontra bug → reporta ao mantenedor → mantenedor corrige → pesquisador publica o writeup. Esse ciclo existe por um bom motivo: dá tempo para os patches chegarem aos usuários antes que atacantes saibam da vulnerabilidade.

O autor do Exploitarium jogou isso pela janela. Publicou 23 PoCs de uma vez, nenhum reportado aos mantenedores, com a nota casual de que qualquer um pode “report them yourself and take credit for the CVE.”

# Do README do Exploitarium
"At the time I post these, none have been reported.
 Feel free to report them yourself and take credit
 for the CVE if handed out lulz."

A comunidade está dividida.

O argumento pró-full disclosure é antigo e tem fundamento: se um pesquisador encontrou, atacantes provavelmente já sabem. Segurar vulnerabilidades dá uma falsa sensação de segurança. Publicar imediatamente força patches rápidos e tira o poder das mãos de quem explora em silêncio.

O argumento contra também é forte: publicar PoCs sem aviso transforma todo script kiddie em uma ameaça real. As equipes de segurança dos projetos afetados não tiveram tempo zero para reagir. Milhões de instâncias vulneráveis do FFmpeg, libssh2 e PHP ficaram expostas da noite para o dia.

E tem um terceiro ângulo que poucos discutiram: a ironia dos relatórios vibecoded. No mesmo thread do HN, alguém lembrou de um caso onde um pesquisador enviou um relatório de vulnerabilidade claramente gerado por IA alegando ter encontrado uma forma de executar SQL arbitrário. O projeto em questão? Um servidor SQL. A pull request no Turso virou piada, mas levanta uma questão séria: com IA gerando relatórios de segurança em massa, como separar o sinal do ruído?

O que fazer agora se você usa algum desses softwares

Eu sei que a lista é grande, mas se algum desses nomes aparece no seu stack, vale prestar atenção:

Ação imediata:

• libssh2: Verifique sua versão. O CVE-2026-55200 é pré-autenticação e client-side. Se você usa qualquer ferramenta que depende de libssh2 (e são muitas), atualize assim que um patch estiver disponível
• c-ares: Usado pelo Node.js, curl, e dezenas de outras ferramentas. O use-after-free em TCP pode ser trigger remoto
• FFmpeg: Se você processa mídia de fontes não confiáveis, isole o processo. O bug no parser RASC/DLTA é confirmado contra o commit mais recente
• PHP 8.5.7: Se você roda essa versão específica, o RCE via StreamBucket + SOAP é potencialmente devastador

Verificação de infraestrutura:

# Verificar versão do libssh2
dpkg -l libssh2* 2>/dev/null || rpm -qa | grep libssh2

# Verificar versão do c-ares
dpkg -l libc-ares* 2>/dev/null || rpm -qa | grep c-ares

# Verificar versão do FFmpeg
ffmpeg -version 2>/dev/null | head -1

# Verificar versão do PHP
php -v 2>/dev/null | head -1

# Verificar se nmap está instalado
nmap --version 2>/dev/null | head -1

Mitigação genérica:

• Rode ferramentas de segurança (nmap, Wireshark) em VMs ou containers isolados — como alguém no HN lembrou, é para isso que o Windows Sandbox existe
• Não conecte via SSH em servidores que você não controla diretamente
• Se você processa input de fontes não confiáveis com FFmpeg ou ImageMagick, use sandboxing (seccomp, firejail, ou containers)

A questão do nmap é a mais assustadora

Eu quero voltar nesse ponto porque ele merece atenção especial.

O nmap é a ferramenta de reconhecimento de rede. Toda equipe de segurança, todo pentester, todo admin de rede usa. Se o bug de integer wrap no parser de extensões IPv6 for explorável para execução remota de código, o cenário é cinematográfico: um atacante configura um host na rede que responde com pacotes IPv6 maliciosos, e qualquer pessoa que fizer um scan naquele range tem seu computador comprometido.

Um comentarista do HN especulou: “This is the kind of bug an intelligence agency would love to have: Add a few ipv6 packets that then edit the trace being observed if the observer uses nmap — get access to any researcher PC who uses nmap.”

Outro respondeu com realismo sombrio: “These kind of tools have always had a broad attack surface. I’ve assumed state level actors already have exploits for them.”

E alguém completou lembrando que os dissectors do Wireshark (decodificadores de protocolo) são todos escritos em C, e qualquer pessoa enviando pacotes pode acionar um dissector. A superfície de ataque das ferramentas de segurança é enorme — e historicamente negligenciada.

Lembra do Stagefright? Os codecs de mídia do Android tinham tantos bugs que o Google redesenhou toda a arquitetura de segurança do sistema por causa deles. As ferramentas de segurança podem estar no mesmo ponto em que os codecs de mídia estavam há uma década: cheias de bugs esperando para serem encontrados.

Quem é “bikini”?

Ninguém sabe. A conta no GitHub não tem bio, não tem links para redes sociais, não tem histórico público anterior ao Exploitarium. O repositório original era composto de repos independentes que foram consolidados em um único archive em 23 de junho de 2026.

O estilo do código e da documentação sugere alguém com experiência real em pesquisa de vulnerabilidades — não é output de IA puro. As classificações seguem taxonomia padrão (CWE, CVSS), os writeups demonstram entendimento do código-fonte dos projetos alvo, e os PoCs que funcionam são tecnicamente sofisticados.

Mas há inconsistências. Os exploits do Ghidra são fracos o suficiente para levantar dúvidas. E o tom casual do README (“lulz”) contrasta com o rigor técnico de alguns dos PoCs mais sérios.

Uma possibilidade que circulou nos comentários: o repositório pode ser um honeypot. Alguém escondendo um exploit real no meio de vários PoCs públicos, esperando que pesquisadores de segurança baixem e executem tudo sem ler. Como um comentarista colocou: “Was just thinking it would be hilarious if these were all known CVEs hiding the next Shai-Hulud inside of them and waiting to compromise security hobbyists rushing to download them.” Outro respondeu secamente: “It wouldn’t be the first time.”

O Exploitarium e a erosão da confiança no open source

Esse incidente se encaixa numa tendência preocupante. Nos últimos meses, vimos o ataque XZ Utils onde um contribuidor infiltrado plantou um backdoor numa biblioteca crítica, pacotes maliciosos no NPM e PyPI se multiplicando, e agora um repositório público despejando exploits para ferramentas que são a espinha dorsal da infraestrutura da internet.

O modelo de segurança do open source sempre dependeu de um contrato social implícito: pesquisadores reportam bugs, mantenedores corrigem, a comunidade se beneficia. O Exploitarium testa os limites desse contrato. Não é malicioso — o autor explicitamente pede que as pessoas não usem o material de forma destrutiva. Mas é irresponsável? Depende de para quem você pergunta.

O que é inegável: 23 PoCs publicados sem coordenação significam que as equipes de segurança do FFmpeg, libssh2, PHP e dos outros projetos afetados estão agora numa corrida contra atacantes que têm código pronto para usar. E nessa corrida, os mantenedores open source — muitos deles voluntários não remunerados — começam em desvantagem.

Se você mantém software afetado, o clock está rodando. Se você usa, verifique suas versões. E se você é pesquisador de segurança baixando PoCs de repositórios anônimos no GitHub — pelo amor de tudo que é sagrado, rode isso numa VM.