CrowdSec perdeu 170 repositórios privados em nove minutos devido a uma lacuna de offboarding

Em 22 de maio de 2026, entre 05:52:29 e 06:01:33 UTC, alguém trabalhando a partir de um endereço IP em Toronto, Canadá, usou a conta do GitHub de um desenvolvedor que havia acabado de sair da CrowdSec para copiar cerca de 170 repositórios privados da empresa francesa de segurança. A CrowdSec publicou essa linha do tempo em seu próprio relatório de incidente em 18 de setembro de 2026 — a data que o arquivo de incidentes de IA atribui a este registro — depois que um arquivo do seu código-fonte apareceu no mercado de crimes cibernéticos pwnforum em 16 de setembro. A conta ainda funcionava porque a empresa havia deixado deliberadamente o acesso do desenvolvedor ao GitHub aberto para que fosse possível concluir algum trabalho. O laptop por trás disso havia sido infectado onze dias antes pelo worm de roubo de credenciais Mini Shai-Hulud que a TeamPCP distribuiu por meio dos pacotes npm da TanStack. Este relato é extraído do registro arquivado em 18 de setembro de 2026, e o conjunto completo de incidentes documentados — cada entrada com sua própria gravidade, classificação de confiança, indicador de disputa e fontes — está em o Orca AI Incident Archive, onde este pode ser lido ao lado dos outros casos de cadeia de suprimentos do mesmo ano.

O roubo não se limitou ao código. O relatório da CrowdSec também divulgou os endereços de e-mail de 83 utilizadores, retirados de uma lista interna de monitorização de ciência de dados e maioritariamente contas Gmail, além dos nomes próprios e apelidos, endereços de e-mail e contexto de investimento de 51 potenciais investidores de 2020. Em comparação com cerca de 150 000 utilizadores, 83 endereços são uma pequena fração; não é zero. O diretor executivo Philippe Humeau reservou o seu pedido de desculpas pessoal para os investidores: "A divulgação dos vossos nomes e endereços de e-mail é uma questão que vamos discutir diretamente convosco e com as autoridades competentes, e por isso peço desculpa pessoalmente."

O que nove minutos realmente levaram

Os registros do Git que o GitHub devolveu à CrowdSec começam às 05:52:32.138 UTC com um fetch em um dos repositórios da empresa, e a atividade termina às 06:01:33. O número do arquivo de cerca de 170 repositórios privados vem desses dados do Git. Em seu relato, Humeau descreve a exposição como "limitada ao código-fonte da CrowdSecurity, incluindo mais de 130 repositórios públicos e muitos privados". O DevOps.com, ao noticiar o incidente em 24 de setembro, colocou a contagem combinada de repositórios públicos e privados em cerca de 300 — um número maior do que o número de repositórios privados da própria CrowdSec, e que o relatório da empresa não declara.

O conteúdo era o mobiliário comum de uma empresa SaaS de ritmo acelerado: o código-fonte do console web, scripts de implantação e automação, e os scripts e modelos de ciência de dados por trás de suas análises. O item mais sensível que a CrowdSec nomeia é o "algoritmo de consenso" que decide quais endereços IP chegam às suas listas de bloqueio. A arquitetura do algoritmo já era pública, mas seus limiares de diversidade e detecção não eram, e agora são conhecidos. Humeau argumenta que os limiares são um alvo móvel e que direcionar o consenso ainda exigiria uma frota de servidores grande e cara; a empresa diz que pode ajustá-los e está monitorando discrepâncias.

As credenciais foram a parte que poderia ter sido bem pior. "Estivemos muito perto de ficar limpos", escreveu Humeau. O único segredo utilizável no dump era um token do AWS Simple Notification Service, restrito à publicação em um único tópico. Alguém o testou em 17 de agosto de 2026 a partir do IP 23.234.84.102, chamando GetCallerIdentity e ListTopics contra os tópicos de dev e env, e não foi além disso. A maioria dos outros tokens e segredos no código havia sido revogada ou rotacionada antes do vazamento. A CrowdSec afirma que sua infraestrutura e seus bancos de dados não foram acessados e que nenhum código foi alterado no projeto de código aberto, em seu código-fonte privado ou em seus pipelines de build.

Por que a conta ainda funcionava

A falha no offboarding é pequena e específica. Quando o desenvolvedor saiu, a CrowdSec já havia removido seu outro acesso; a conta do GitHub foi mantida ativa, escreveu Humeau, porque "nos separamos em bons termos do nosso desenvolvedor, e ele queria finalizar algum trabalho." A conta foi removida da organização do GitHub em 25 de maio, três dias depois de os repositórios já terem sido copiados.

A CrowdSec não conseguiu ver o roubo na época, e o motivo vale ser enunciado com precisão. O token OAuth não estava presente no log de auditoria da organização nem no de nenhum membro atual e, quando alguém foi procurá-lo, ele já não existia: tinha sido criado, usado e expirado sem deixar um rastro que a empresa pudesse ler. O GitHub só retém a atividade Git em uma janela móvel de sete dias para organizações que não estão em um plano enterprise, como a própria CrowdSec observa. O avanço veio da equipe de suporte do GitHub, que rastreou todo o ciclo de vida do token e forneceu a atividade Git da janela de duas horas em torno da cópia. Foi assim que a empresa chegou à conta de um funcionário que já havia saído. A ligação de volta à TanStack veio do mesmo exercício.

O arquivo vazado trazia suas próprias evidências. O .github/.git/config dentro dele registrava uma URL de origem no formato oauth2:gho_xxxxxxxxx@github.com, identificando a credencial como um token OAuth do GitHub e correspondendo à metodologia documentada do TeamPCP. A CrowdSec afirma que verificou máquinas de desenvolvedores em busca de pacotes maliciosos e não encontrou nenhuma das versões do TanStack com backdoor em seus próprios repositórios — um resultado que descreve como inconclusivo, e não exculpatório.

Quem o fez, e quão sólida é a atribuição

A CrowdSec atribui o download a "um dos fundadores do BreachForum e a um membro, diencracked", com o endereço do membro indicado como diencracked@cock.li, operando a partir de um IP de Toronto com o fuso horário da máquina definido como UTC-4. A empresa acrescenta sua própria ressalva na mesma frase: "Pelo menos é o que os dados do Git mostram." O relatório da Dark Reading de 22 de setembro traz a mesma atribuição ao fundador do BreachForum e ao nome de usuário diencracked.

A campanha upstream está melhor documentada do que as identidades por trás dela. Os pacotes da TanStack tiveram backdoor inserido em 11 de maio de 2026, quando 84 versões maliciosas em 42 pacotes foram publicadas; o The Hacker News registra o comprometimento como CVE-2026-45321 e cita o próprio comunicado de segurança da TanStack sobre o payload de roubo de credenciais. A linha do tempo da CrowdSec observa que, em 22 de maio, no mesmo dia da cópia do repositório, o TeamPCP — rastreado pela CrowdSec como UNC6780 — reivindicou responsabilidade por comprometer repositórios pertencentes à Mistral AI.

O que está estabelecido e o que não está

Estabelecido: uma cópia de cerca de 170 repositórios privados ocorreu em 22 de maio de 2026, em uma janela de nove minutos, usando a conta GitHub ainda válida de um desenvolvedor que já saiu — uma sequência reconstruída a partir dos próprios registros de atividade Git do GitHub, não inferida. Também comprovado pelo próprio relato da empresa: a exposição de 83 endereços de e-mail de usuários e os detalhes de 51 potenciais investidores, a revogação de 25 de maio, o token SNS sondado, e a constatação de que nenhum código foi alterado e nenhuma infraestrutura ou banco de dados foi acessado.

Não estabelecido: qual pacote envenenado chegou ao laptop, e quando. A CrowdSec afirma claramente que não identificou nenhum dos dois. A varredura do repositório da empresa foi inconclusiva, e suas máquinas de desenvolvedores retornaram limpas, o que contrasta de forma estranha com um laptop que, segundo o próprio relato da empresa, foi comprometido. A lacuna é reconhecida, não fechada.

Não publicado: O lado do GitHub na investigação. A CrowdSec afirma que a equipe de suporte do GitHub corroborou a origem do TanStack, mas o The Hacker News observa que o relatório da empresa não contém conclusões do próprio GitHub, e o GitHub não publicou seu próprio relato sobre o ciclo de vida do token.

Corroboração: Dark Reading, The Hacker News e DevOps.com cobriram o incidente em até uma semana, e todos os três se baseiam no relatório da CrowdSec e no aviso da TanStack, e não em um exame forense independente dos sistemas da CrowdSec. O Dark Reading acrescenta comentários de profissionais externos, incluindo Denis Calderone, da Suzu Labs, que chamou a falha na revogação de "coisa de primeiro dia". Uma nota de pesquisa da Cloud Security Alliance datada de 20 de setembro repete a sequência, mas o documento traz seu próprio aviso de que foi gerado com assistência de IA e não passou por revisão oficial da CSA — vale saber antes de ser contado como uma segunda constatação independente. O arquivo classifica a confiança do registro como A, contestado como falso, dano real como verdadeiro.

A primeira afirmação, e a correção

A primeira declaração pública da CrowdSec, em 17 de setembro, afirmou que "nenhum dado de cliente, login/senha, nome, organização ou qualquer outra coisa foi vazado, e a CrowdSec não armazena PII nem registos de clientes; o impacto está limitado à CrowdSec." Também levantou uma hipótese técnica: a de que um componente interno tinha sido comprometido por uma backdoor para roubar uma chave de API capaz de ler código privado.

O relatório mais completo, um dia depois, substituiu essa hipótese pela versão do funcionário que saiu e divulgou os 83 endereços e os 51 investidores. The Hacker News descreve isso como uma correção da alegação anterior. A própria formulação da CrowdSec é mais restrita: os 83 endereços vieram de uma lista de monitoramento de ciência de dados, e não de registros de clientes, e os detalhes dos investidores datavam de 2020. As duas descrições podem ser verdadeiras ao mesmo tempo — os endereços não eram contas de clientes, e ainda assim eram dados pessoais em um dump publicado em um fórum criminoso. A empresa diz que notificará os usuários e investidores afetados e reportará o vazamento às autoridades.

O que mudou depois

• As credenciais e os tokens encontrados no arquivo foram rotacionados na noite de 16 de setembro e ao longo de 17 de setembro, com a rotação restante concluída na manhã seguinte.

• A detecção e resposta em endpoints agora está implantada nas estações de trabalho e nos laptops das pessoas que mexem na base de código ou na infraestrutura da CrowdSec; a empresa aponta a Aikido Security como o produto. Humeau admite que isso deveria estar em vigor antes e também admite que era improvável que a máquina de um ex-funcionário estivesse executando isso.

• Os limiares do algoritmo de consenso expostos na fuga de informação estão a ser ajustados, com uma monitorização mais rigorosa de desvios estatísticos em toda a rede de listas de bloqueio.

• A empresa definiu como meta comprimir o mesmo tempo de resposta — inventário, rotação, perícia forense e divulgação — de 48 horas para menos de 24.

• Os usuários e investidores afetados estão sendo contatados diretamente, e o vazamento está sendo comunicado às autoridades, na formulação da empresa.

Por que isto está num arquivo de incidentes de IA

O envolvimento da IA aqui é infraestrutural, e vale ser exato sobre o que isso significa. Nada no relato da CrowdSec descreve um sistema de IA tomando uma decisão durante a intrusão; o ator era uma pessoa ou pessoas usando um token roubado. O que torna o caso um incidente da indústria de IA é o raio de impacto. As bibliotecas da TanStack constroem as interfaces de grande parte do software moderno, o worm que coletou o token é feito para obter credenciais de nuvem, SSH e provedores de modelos de uma só vez, e o material copiado da CrowdSec incluía scripts e modelos de ciência de dados, e não apenas código de aplicação.

A mesma campanha atingiu diretamente empresas de IA. A linha do tempo da CrowdSec registra o TeamPCP reivindicando repositórios da Mistral AI em 22 de maio, e o The Hacker News relata que dois dispositivos de funcionários da OpenAI foram afetados, com acesso não autorizado a um conjunto limitado de repositórios internos de código. O arquivo registra o caso CrowdSec como a segunda vítima downstream do comprometimento da TanStack em maio, depois daqueles dispositivos de funcionários da OpenAI.

A distância entre a cópia e a sua descoberta é a parte que deveria viajar. Os repositórios foram levados em 22 de maio; a CrowdSec soube do vazamento em 16 de setembro, quando a equipe do Fuites Info contatou a empresa sobre a postagem no pwnforum — 117 dias depois, e não por meio de seu próprio monitoramento. O mecanismo que tornou o atraso possível não era exótico: uma conta que sobreviveu ao seu propósito por três dias, um token que não deixou rastro nos logs que a empresa conseguia ler, e notebooks de desenvolvedores sem detecção de endpoint. A CrowdSec, uma empresa que vende detecção de ameaças, tinha os três.