PingCAP confirma vazamento de dados e código-fonte do TiDB Cloud
Grupo FulcrumSec afirma ter extraído 10,6 TB de dados do controle do TiDB Cloud, incluindo chaves de API, logs de conexão e código-fonte da PingCAP. A empresa confirma parte do vazamento e recomenda rotação de credenciais.
A PingCAP, empresa por trás do TiDB (banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → distribuído open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → compatível com MySQL), confirmou acesso não autorizado a sistemas internos e o roubo de código-fonte e dados relacionados a clientes. O caso foi reportado pela InfoQ em 25 de outubro de 2026, com base em um relatório de incidente da própria empresa e nas alegações do grupo de extorsão cibernética FulcrumSec.
O grupo afirma ter extraído 10,6 TB de dados, incluindo registros do plano de controle do TiDB Cloud, statements SQL de clientes, chaves de API, logs de conexão, dados de faturamento, documentos internos e 413 repositórios privados de código-fonte. A PingCAP não confirmou todos esses números, e a InfoQ destaca que as alegações do FulcrumSec não foram verificadas de forma independente.
O que a PingCAP confirmou oficialmente
No relatório de incidente citado pela InfoQ, a empresa diz que uma firma externa de resposta a incidentes revisou os sistemas de produção e não encontrou evidência de que o atacante executou comandos ou manteve acesso persistente nos sistemas analisados.
Uma firma externa de resposta a incidentes revisou os sistemas de produção da PingCAP e não encontrou evidência de que o atacante executou comandos ou manteve acesso persistente nos sistemas revisados. Essa constatação não muda a exposição de dados descrita a seguir. Com apoio de assessoria jurídica externa e especialistas forenses terceirizados, não há evidência de que dados armazenados no TiDB tenham sido impactados.
An external incident response firm reviewed PingCAP's production systems and found no evidence that the attacker ran commands or maintained persistent access in the systems reviewed. That finding does not change the data exposure described below. With support from outside counsel and third-party forensic specialists, there is no evidence that data stored in TiDB was impacted.PingCAP, relatório de incidente
A empresa confirmou que os registros exportados incluem nomes de usuário e e-mails, associações de organização e projeto, e textos e erros do editor SQL do console. Alguns registros também continham identificadores de organização, projeto e cluster.
O que o FulcrumSec alega ter levado
O grupo diz ter obtido uma cópia completa do banco metadb da PingCAP, com cerca de 180 mil organizações-cliente e quase 300 mil registros de usuário, dos quais 166 mil com nomes reais e mais de 400 mil e-mails únicos. Entre os dados alegadamente roubados:
- 115 mil pares de chaves de API do console, dos quais mais de 40 mil estariam ativos (a mais recente teria sido criada horas antes do fim do acesso alegado pelo atacante);
- cerca de 1.800 endpoints de bancos de dados externos usados em jobs de migração de clientes, incluindo contas root e admin de hosts MySQL e Aurora de terceiros;
- quatro anos de logs de conexão de cada cliente ao produto, segundo o grupo.
O FulcrumSec descreve o alcance do que diz possuir em termos diretos:
Temos o plano de controle completo do TiDB Cloud, seu patrimônio de faturamento e finanças, seu patrimônio de armazenamento na GCP e seu patrimônio de custos e faturamento na AWS, seu Jira, seu CRM, sua análise de dados, seu código-fonte, e um log de quatro anos de cada conexão que cada cliente já fez ao produto, a partir dos endereços IP dos servidores de aplicação deles.
We possess the complete TiDB Cloud control plane, its billing and finance estate, its GCP storage estate and its AWS cost and billing estate, its Jira, its CRM, its analytics, its source code, and a four-year log of every connection every customer ever made to its product, from the IP addresses of their application servers.FulcrumSec, grupo de extorsão cibernética
O primeiro lote divulgado publicamente soma cinco arquivos tar.gz, totalizando 128,3 GB comprimidos (pouco mais de 200 GB descompactados) de um total alegado de 10,6 TB.
A causa raiz: credenciais coladas em tickets do Jira
Segundo o FulcrumSec, engenheiros da PingCAP colavam credenciais de produção de clientes diretamente em tickets do Jira. O grupo reproduziu três logs completos e os tickets correspondentes no primeiro lote de dados divulgado. É esse detalhe que, para especialistas em segurança, torna o caso mais grave do que um incidente comum de banco de dados.
Kim Barthel, diretora e fundadora da consultoria de segurança 42Sec, resume o problema:
A violação da PingCAP não é realmente uma história sobre banco de dados. É uma história sobre uma chave de service account (...) A PingCAP diz não ter evidência de que dados de clientes armazenados no próprio TiDB tenham sido tocados. Ótimo. Mas olhe o que vazou. Quem tiver isso sabe quem são seus engenheiros, quanto você paga, quando seu contrato renova e como é seu schema. É tudo que se precisa para um e-mail de phishing em que você realmente acreditaria.
The PingCAP breach isn't really a database story. It's a story about one service-account key (...) PingCAP says it has no evidence that customer data stored in TiDB itself was touched. Good. But look at what did leak. Whoever has it knows who your engineers are, what you pay, when your contract renews, and what your schema looks like. That's everything needed for a phishing email you'd actually believe.Kim Barthel, diretora e fundadora da 42Sec
Em outras palavras: mesmo que nenhum dado armazenado no TiDB em si tenha sido acessado, o que vazou (histórico de queries, tickets de suporte, logs de diagnóstico) já é suficiente para ataques de engenharia social direcionados contra equipes de engenharia específicas.
Reação na comunidade e perguntas sem resposta
Em uma discussão popular no Hacker News, citada pela InfoQ, desenvolvedores questionam a resposta da PingCAP ao incidente. A alegação do FulcrumSec de que manteve uma exportação contínua do banco do plano de controle por mais de um mês sem ser detectado gerou críticas. O usuário dherls escreveu:
Se for verdade, isso é incompetência de outro nível por parte da PingCAP. Aparentemente os atacantes montaram um pipeline de replicação por um mês?!
If true, this is next level incompetence from PingCap. Apparently the attackers set up a replication pipeline for a month?!dherls, usuário no Hacker News
O momento do ataque também chamou atenção porque a PingCAP havia acabado de divulgar um comunicado sobre auditoria de segurança independente do código-fonte do TiDB, feita pela NCC Group. O usuário xKingfisher comentou:
Isso acontecer logo depois da auditoria de segurança feita pela NCC é bem constrangedor para todas as partes.
Coming this close on the heels of the security audit by NCC is pretty embarrassing for all parties.xKingfisher, usuário no Hacker News
Quem foi citado, e quem já negou envolvimento
Os registros supostamente expostos incluem dados associados a empresas como Booking.com, Shopee, Airbnb, Pinterest, Databricks, Atlassian, Fujitsu, SoftBank e Baidu. A InfoQ reforça que a presença do nome de uma empresa no vazamento não confirma que ela foi comprometida. A corretora de criptomoedas Bitget, uma das citadas no relatório, afirmou que sua própria investigação não encontrou evidência de exposição de dados de usuários.
O que fazer se você roda TiDB em produção
Para quem usa TiDB Cloud (ou considera migrar para ele) no Brasil, o episódio pede ação concreta, não só acompanhamento da notícia. A PingCAP recomenda publicamente a troca de chaves de API de gerenciamento do TiDB Cloud que estejam ativas e atenção redobrada a tentativas de phishing direcionado.
Além da recomendação oficial, vale considerar:
- Rotacionar toda chave de API do console TiDB Cloud ativa hoje, mesmo sem confirmação de que a sua organização está entre as afetadas;
- Auditar endpoints de migração configurados no passado: se você já rodou um job de migração para o TiDB Cloud, as credenciais usadas naquele momento (inclusive root/admin de MySQL ou Aurora) devem ser tratadas como potencialmente expostas;
- Revisar o que entra em tickets de suporte: o vazamento mostra que strings de conexão e credenciais coladas em sistemas de terceiros (Jira, CRM, ferramentas de analytics) são um vetor tão real quanto uma falha no próprio banco;
- Reforçar o monitoramento contra phishing direcionado: com nomes de engenheiros, valores de contrato e datas de renovação potencialmente expostos, e-mails fraudulentos tendem a ficar mais convincentes nas próximas semanas.
O que ainda está em aberto
Nem a extensão real dos 10,6 TB alegados, nem a lista completa de organizações afetadas foram confirmadas de forma independente até a publicação da reportagem da InfoQ. A PingCAP mantém a posição de que não há evidência de que dados armazenados dentro do próprio TiDB tenham sido acessados, mas isso não cobre o que vazou do plano de controle, do Jira e dos sistemas de billing. Até que uma investigação forense independente confirme ou refute os números do FulcrumSec, clientes do TiDB Cloud fazem bem em tratar toda credencial emitida antes de outubro de 2026 como potencialmente comprometida.
Fonte: InfoQ
Este artigo foi escrito por Redação iMasters. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Vulnerabilidades do PHP2Shell mostram como IA acelera exploração de falhas antigas
Falhas do PHP conhecidas desde 2024, mas tidas como inexploráveis, viraram ataque real depois que pesquisadores usaram IA para encontrar o caminho que humanos não achavam. Cloudflare registrou milhões de tentativas de exploração em horas.






