Checkmarx investiga publicação de dados de repositório GitHub após ataque de cadeia de suprimentos

Dados atribuídos a um repositório GitHub da Checkmarx foram publicados na dark web após um ataque iniciado em 23 de março de 2026 que adulterou fluxos de GitHub Actions, extensões e componentes de distribuição para desenvolvedores.

Componente	Repositório GitHub da Checkmarx, dois fluxos de GitHub Actions, dois plugins distribuídos pelo Open VSX, imagem Docker do KICS, extensões de VS Code e o pacote npm Bitwarden CLI citado como afetado em cadeia.
Vetor	Acesso ao repositório teria sido facilitado pelo ataque de cadeia de suprimentos de 23 de março de 2026, que adulterou fluxos de automação e plugins para distribuir um ladrão de credenciais voltado a segredos de desenvolvedores.
Impacto	Dados relacionados à Checkmarx foram publicados na dark web; a evidência atual aponta origem no repositório GitHub, enquanto a natureza e o escopo dos dados publicados continuam em apuração.
Prioridade	Restringir acesso ao repositório afetado, validar histórico de workflows e artefatos distribuídos, revisar segredos expostos em ambientes de desenvolvimento e rotacionar credenciais com possibilidade de uso indevido.
Limite confirmado	O repositório GitHub é mantido separado do ambiente de produção de clientes e não armazena dados de clientes, conforme a posição técnica informada no contexto.
Atribuição	TeamPCP reivindicou o ataque anterior envolvendo o ladrão de credenciais; uma listagem atribuída ao grupo LAPSUS$ alegou incluir Checkmarx entre vítimas em site de vazamento.

Resumo técnico

A Checkmarx investiga a publicação de dados relacionados à empresa em um site da dark web após um incidente de cadeia de suprimentos iniciado em 23 de março de 2026. A evidência técnica descrita até agora indica que o material publicado teria origem em um repositório GitHub da empresa, e que o acesso a esse repositório foi viabilizado pelo ataque anterior contra componentes usados em fluxos de desenvolvimento. O ponto central para operadores de segurança é a relação entre comprometimento de automação, distribuição de extensões e possível exposição de artefatos internos de engenharia. O caso não deve ser tratado como um incidente genérico de vazamento, porque a investigação ainda verifica a natureza e o escopo do material publicado, mas já há indicação suficiente para priorizar revisão de segredos, permissões e integridade de pipelines.

A empresa afirma que o repositório GitHub afetado é mantido separado do ambiente de produção de clientes e que dados de clientes não são armazenados nele. Esse limite é importante porque reduz a superfície confirmada do incidente ao ambiente de desenvolvimento e aos artefatos do repositório, sem sustentar, pelos dados disponíveis, conclusão sobre exposição direta de informações de clientes. Ainda assim, a publicação de dados na dark web e a alegação de que a listagem conteria código-fonte, base de funcionários, chaves de API e credenciais de MongoDB e MySQL tornam necessária uma resposta conduzida como incidente de exposição de ativos de engenharia. A defesa deve separar fatos confirmados de alegações de site de vazamento, mas não deve aguardar conclusão pública para iniciar contenção de credenciais potencialmente expostas.

Fluxo técnico

O fluxo descrito começa com um ataque de cadeia de suprimentos associado ao ecossistema Trivy, no qual dois workflows de GitHub Actions e dois plugins publicados no Open VSX foram adulterados para entregar um ladrão de credenciais. Esse tipo de comprometimento é crítico porque workflows e extensões de desenvolvimento operam perto de tokens, variáveis de ambiente, arquivos de configuração, credenciais de publicação e integrações com registries. Quando um artefato malicioso roda em uma máquina de desenvolvedor ou em uma esteira de automação, ele pode capturar segredos que não aparecem em aplicações de produção, mas que permitem acesso posterior a repositórios, pacotes, imagens, bancos auxiliares ou contas de serviço. O material analisado indica que essa etapa inicial teria facilitado o acesso ao repositório GitHub de onde os dados publicados se originaram.

Depois do ataque de 23 de março, o incidente se expandiu para outras peças de distribuição técnica. O grupo financeiramente motivado TeamPCP reivindicou responsabilidade pelo ataque anterior, e há suspeita de comprometimento posterior da imagem Docker do KICS, de duas extensões de VS Code e de um workflow de GitHub Actions com malware semelhante de roubo de credenciais. Esse encadeamento também teria gerado impacto cascata sobre o pacote npm Bitwarden CLI, ainda que o contexto caracterize esse efeito como breve. O padrão operacional é típico de ataques contra confiança de desenvolvimento: em vez de explorar diretamente uma aplicação final, o operador altera pontos de execução que desenvolvedores e pipelines já tratam como legítimos, ampliando a chance de coleta de segredos e reutilização desses acessos em repositórios ou sistemas adjacentes.

A publicação na dark web aparece como fase posterior do incidente. Uma listagem atribuída ao grupo LAPSUS$ alegou três vítimas, incluindo Checkmarx, e afirmou conter código-fonte, base de funcionários, chaves de API e credenciais de MongoDB e MySQL. Essa alegação não deve ser lida como confirmação integral do conteúdo, porque a investigação ainda verifica natureza e escopo dos dados. Para resposta defensiva, porém, a diferença entre confirmação pública e risco operacional é prática: qualquer segredo que possa ter estado no repositório, em workflows, em extensões, em imagens ou em registros de build deve ser considerado candidato à rotação. A linha de investigação deve reconstruir quais tokens existiam no período de comprometimento, quais permissões eles tinham e quais eventos de autenticação ocorreram antes e depois da publicação dos dados.

Superfície afetada

A superfície diretamente sustentada pelo contexto envolve o repositório GitHub da Checkmarx, que foi bloqueado como parte da resposta ao incidente, além de automações e artefatos de distribuição usados por desenvolvedores. Dois workflows de GitHub Actions foram citados como adulterados, o que torna relevante revisar permissões de GITHUB_TOKEN, segredos de repositório, segredos de organização, ambientes protegidos, chaves de publicação e integrações acionadas por eventos de push, pull request, release ou publicação de pacote. Em ataques desse tipo, o risco cresce quando o workflow tem permissão ampla de escrita, acesso a registries externos ou capacidade de publicar artefatos consumidos por terceiros.

Também entram na superfície os dois plugins distribuídos pelo Open VSX, as duas extensões de VS Code mencionadas no contexto, a imagem Docker do KICS e o pacote npm Bitwarden CLI citado como impactado em cascata. Esses elementos não representam a mesma classe de ativo, mas compartilham um ponto operacional: todos são executáveis ou instaláveis em ambientes de desenvolvimento, CI/CD ou análise de código. A exposição relevante não é apenas a presença do malware, mas a cadeia de confiança que permite a instalação automática, atualização silenciosa, cache em runners, reutilização por imagens base e execução com variáveis sensíveis disponíveis no ambiente.

O limite declarado é igualmente importante para escopo: o repositório GitHub é separado do ambiente de produção de clientes e não armazena dados de clientes. Portanto, o material recebido não sustenta afirmação de comprometimento do ambiente de produção de clientes, acesso a dados de clientes ou movimentação lateral dentro desses ambientes. A investigação deve permanecer concentrada em engenharia, distribuição, repositórios, credenciais e artefatos de build, a menos que novos dados indiquem outra direção.

• Repositório GitHub da Checkmarx apontado como origem provável dos dados publicados.
• Dois workflows de GitHub Actions adulterados no ataque de cadeia de suprimentos de 23 de março de 2026.
• Dois plugins no Open VSX usados como canal de distribuição do ladrão de credenciais.
• Imagem Docker do KICS, extensões de VS Code e pacote npm Bitwarden CLI citados como parte do encadeamento técnico do incidente.

Hunting e telemetria

A investigação defensiva deve começar por eventos de identidade e auditoria do GitHub no intervalo que cobre o ataque de 23 de março de 2026, os dias posteriores e o momento de bloqueio do repositório afetado. Devem ser examinados acessos a repositórios, alterações de workflows, criação ou atualização de secrets, mudanças em permissões de tokens, criação de deploy keys, alterações em webhooks, publicações de releases e execuções incomuns de GitHub Actions. Como o contexto aponta um ladrão de credenciais voltado a segredos de desenvolvedores, a telemetria precisa incluir tanto eventos de CI/CD quanto estáções de trabalho usadas por mantenedores, principalmente quando houver instalação ou atualização de plugins, extensões ou imagens citadas no incidente.

Em endpoints de desenvolvimento, sinais úteis incluem processos associados a extensões ou ferramentas recém-instaladas, conexões de rede iniciadas logo após atualização de plugins, leitura de arquivos de configuração com tokens, acesso a diretórios de credenciais de registries e execução de binários ou scripts a partir de caches de extensões. Em ambientes de build, a busca deve cobrir runners persistentes e efêmeros, logs de execução de workflows, variáveis de ambiente expostas no tempo de execução, artefatos armazenados em cache e uso de credenciais fora do padrão esperado. O objetivo é identificar se tokens coletados foram usados depois da execução maliciosa, não apenas confirmar a presença de um pacote comprometido.

Para infraestrutura de pacotes e imagens, operadores devem comparar horários de publicação, digest de imagens, versões instaladas, origem dos artefatos e histórico de downloads em caches internos. O impacto cascata sobre o pacote npm Bitwarden CLI exige atenção especial a pipelines que baixaram dependências nesse período, porque caches e lockfiles podem manter referências a versões ou artefatos mesmo após a remoção pública de um componente comprometido. A telemetria de rede deve procurar autenticações incomuns em serviços ligados a MongoDB, MySQL, APIs internas e registries, sempre respeitando que a presença desses nomes no contexto vem de alegação de listagem e não de confirmação pública do conteúdo total publicado.

• Alterações inesperadas em arquivos de workflow, permissões de GitHub Actions, webhooks, deploy keys ou secrets.
• Execuções de extensões, plugins ou imagens associadas ao período do ataque com acesso a variáveis sensíveis.
• Uso anômalo de tokens de desenvolvedor, chaves de API ou credenciais de banco após 23 de março de 2026.
• Instalações ou caches envolvendo plugins Open VSX, extensões de VS Code, imagem Docker do KICS e pacote npm Bitwarden CLI citados no incidente.

Mitigação

A primeira medida já indicada no contexto é o bloqueio do acesso ao repositório GitHub afetado. A partir daí, a resposta deve tratar como suspeitos todos os segredos que tenham passado pelo repositório, por workflows, por runners, por ambientes de publicação e por máquinas de mantenedores com os plugins ou extensões citados. A rotação deve priorizar credenciais com capacidade de escrita, publicação, administração de repositório, acesso a bancos, acesso a registries e integração com sistemas de build. Tokens de baixa visibilidade, como chaves de automação embutidas em variáveis de ambiente, secrets de organização e credenciais usadas por imagens de CI, costumam ser mais difíceis de inventariar e devem receber atenção explícita.

A validação de integridade deve comparar o histórico dos workflows de GitHub Actions, os artefatos publicados no Open VSX, as extensões de VS Code, a imagem Docker do KICS e dependências npm afetadas em cascata. Equipes devem remover caches de runners, invalidar artefatos reconstruídos durante a janela de risco, revisar lockfiles e reconstruir imagens a partir de fontes verificadas. Quando houver distribuição interna de extensões ou imagens, a mitigação precisa alcançar espelhos corporativos e caches de proxy, porque a limpeza apenas no registro público pode deixar cópias acessíveis em ambientes de engenharia.

A etapa final é reduzir a chance de repetição do padrão de ataque. Workflows devem operar com menor privilégio, permissões explícitas, aprovação para ambientes sensíveis e separação entre build, teste e publicação. Extensões e plugins usados por desenvolvedores devem passar por política de allowlist, verificação de origem e monitoramento de atualização. Repositórios que não armazenam dados de clientes ainda podem conter código, chaves, histórico de configuração e metadados úteis para ataques futuros; por isso, a ausência de dados de clientes no repositório não elimina a necessidade de resposta completa sobre segredos, identidade e distribuição de artefatos.

• Manter o repositório afetado restrito até concluir inventário de acessos, secrets, workflows e artefatos publicados.
• Rotacionar chaves de API, tokens de GitHub, credenciais de banco, credenciais de registries e segredos presentes em ambientes de build relacionados.
• Revisar e reconstruir artefatos derivados de plugins Open VSX, extensões de VS Code, imagem Docker do KICS e dependências npm instaladas na janela de risco.
• Auditar permissões de GitHub Actions, runners, deploy keys, webhooks e contas de serviço para remover privilégios desnecessários.