Para quem é este artigo: pessoas que lançaram um projeto na CAMPFIRE, apoiaram um, receberam um reembolso ou se cadastraram como parceiras — e desenvolvedores e operadores que usam GitHub e nuvem no trabalho. Este artigo se baseia nos próprios comunicados oficiais da CAMPFIRE e não aborda técnicas de ataque.
O que os usuários devem fazer agora
Verifique se você foi afetado — o e-mail de notificação tem um assunto fixo
Desde 24 de abril de 2026, a empresa envia e-mails individuais às pessoas afetadas, com o assunto em japonês "【重要：CAMPFIRE】お客様情報漏えい可能性に関するお詫びとご報告" (um pedido de desculpas e relatório sobre um possível vazamento de informações de clientes). Os grupos afetados são:
- Alguns responsáveis por projetos e comunidades que usaram o serviço até 9 de abril de 2026
- Apoiadores que pagaram com PayPal (1º de jan. de 2021 – 19 de abr. de 2026) ou com o pagamento diferido Kondo-barai (3 de jan. de 2022 – 24 de abr. de 2023)
- Apoiadores que receberam reembolsos por transferência bancária (6 de jan. de 2022 – 5 de mar. de 2026)
- Parceiros cadastrados até 5 de março de 2025
- Pessoas que editaram dados bancários na página de sua conta em 2020
Se você se encaixa em algum desses grupos, mas não encontra o e-mail, siga os passos mesmo assim.
Não abra links em mensagens sobre reembolsos ou contas para repasse
Os dados em risco são nome, endereço, número de telefone, endereço de e-mail e dados de conta bancária. Se você receber "recadastre sua conta para receber seu reembolso" ou "confirme para onde devemos enviar seus valores", não abra o link; se necessário, acesse a CAMPFIRE por um favorito ou por um endereço que você mesmo digite. A empresa afirma que nunca pede PINs por telefone ou e-mail (noções básicas: o que é phishing).
Verifique seus extratos bancários
A empresa diz que os dados bancários possivelmente vazados, por si só, não podem ser usados para sacar dinheiro ou fazer transferências. Ela pede que você entre em contato imediatamente com seu banco ou com a empresa se vir transações desconhecidas. Se você usa internet banking, ativar notificações de transações facilita essa verificação.
Recuse pacotes de pagamento na entrega que você não pediu
Como os endereços estão incluídos, a empresa alerta para golpes que enviam pacotes de pagamento na entrega que você nunca encomendou. Verifique o remetente e o conteúdo antes de aceitar.
Troque senhas reutilizadas em outros serviços
A empresa pede que pessoas que usam o mesmo endereço de e-mail e a mesma senha em outros serviços as troquem como precaução. As senhas não estão entre os itens listados, mas interrompa a reutilização agora; um gerenciador de senhas é a forma prática de fazer isso.
Responsáveis por projetos: informem também sua equipe
Se uma empresa ou grupo administra seu projeto, a equipe pode receber e-mails se passando por avisos de repasse ou de análise. Combinem em equipe que as alterações da conta para repasse devem ser verificadas no painel da CAMPFIRE e que nenhuma ação seja tomada apenas com base em instruções por e-mail.
A linha exclusiva da empresa é 0120-188-070 (10h–19h JST, somente dias úteis desde julho; ligação gratuita no Japão). No Japão, a linha de consulta da polícia #9110 atende dúvidas sobre fraudes.
O que aconteceu (segundo os comunicados da CAMPFIRE)
A empresa publicou uma série de comunicados a partir de 3 de abril de 2026, até seu relatório de investigação de 2 de junho. Tudo a seguir é conforme declarado nos comunicados oficiais da empresa.
2 de abril de 2026, ~22h50 JST
Foi identificado acesso não autorizado por um terceiro à conta do GitHub usada para gerenciamento de sistemas, e parte do código-fonte pode ter sido visualizada (conforme o primeiro comunicado).3 de abril
Foram detectadas operações suspeitas em alguns repositórios do GitHub; contas relacionadas foram removidas e credenciais possivelmente roubadas foram substituídas. Primeiro comunicado publicado (naquele momento, nenhum vazamento de dados pessoais havia sido confirmado).7 de abril
A causa do vazamento da credencial do GitHub foi identificada.14 de abril
Segundo comunicado: a conta do GitHub podia visualizar o nome e os dados de contato de um parceiro comercial e os nomes e endereços de e-mail de 413 pessoas que trabalharam em desenvolvimento. Caso comunicado à Comissão de Proteção de Informações Pessoais do Japão.20 de abril
Detectado acesso não autorizado a um ambiente de nuvem usado para operações comerciais internas; contas e recursos indevidos foram interrompidos e desativados.22–24 de abril
O terceiro comunicado informou vestígios de acesso não autorizado em parte de um sistema que gerencia informações de clientes. O quarto comunicado (24 de abril) divulgou a abrangência do possível vazamento (225.846 registros únicos de usuários afetados), e as notificações individuais começaram.27–28 de abril
O quinto comunicado detalhou a distribuição. Uma linha exclusiva de atendimento foi aberta no dia 28.30 de maio / 2 de junho
Perícia forense externa concluída (30 de maio). Em 2 de junho, a empresa publicou os resultados da investigação e as medidas de prevenção.
- Alguns responsáveis por projetos e comunidades
- Nome, endereço, número de telefone, endereço de e-mail, dados de conta bancária. 108.784 registros (53.869 com dados bancários)
- Alguns apoiadores
- Nome, endereço, número de telefone, endereço de e-mail, dados de conta bancária. 118.010 registros (4.307 com dados bancários)
- Parceiros
- Nome. 1.282 registros
- Categoria não clara (ex.: em meio ao cadastro)
- Dados de conta bancária de pessoas que os editaram na página de sua conta em 2020. 10.521 registros
- Outros
- 413 registros com nomes e endereços de e-mail relacionados a trabalhos de desenvolvimento estavam visíveis
- Dados de cartão de crédito
- Não incluídos
- Achados forenses
- Credenciais e chaves de API armazenadas em um ambiente de nuvem específico, alguns arquivos de dados sem informações pessoais, além de nomes de tabelas e informações de configuração foram obtidos. Durante a exploração, um registro contendo dados pessoais foi exibido como resultado de consulta. Não foram encontrados vestígios de arquivos com dados pessoais sendo transferidos para fora
- Avaliação da empresa
- Como os logs não foram coletados em algumas áreas, ela não pode descartar que os dados tenham sido visualizados
- Dano secundário
- Nenhum dano decorrente do uso indevido dos dados havia sido relatado na época dos comunicados
Para desenvolvedores e operadores: do token do GitHub à nuvem interna
O relatório de 2 de junho da empresa é incomumente específico quanto à sequência e à causa. A figura mostra o caminho como a empresa o descreveu, com as configurações que impedem ou limitam os danos em cada etapa à direita.
1. Credencial do GitHub emitida para um funcionário
Enviada por engano a um servidor de projeto pessoal
↓→
Política da organização: bloquear tokens clássicos, limitar validade
2. Repositórios da organização
Parte do código-fonte e dados de 413 funcionários visíveis
↓→
Permissões padrão mínimas, sem dados pessoais nos repositórios
3. Das informações do GitHub às credenciais da nuvem
↓→
Sem chaves de nuvem de longa duração (usar autenticação de curta duração)
4. Parte da área de gerenciamento da nuvem interna
Credenciais, chaves de API e nomes de tabelas obtidos
↓→
Logs de auditoria em todos os lugares, alertas para ações incomuns
5. Dados de clientes em 225.846 registros únicos de usuários afetados em risco
↓→
Fazer inventário dos dados de clientes fora da produção
Segundo a empresa, o serviço funciona em um ambiente separado do ambiente de nuvem onde o acesso não autorizado foi encontrado, e não foi identificado uso indevido ou adulteração da plataforma de serviço. Os dados de clientes, ainda assim, ficaram em risco porque podiam ser acessados a partir da nuvem comercial interna.
A empresa afirma que a credencial em questão deveria ter sido tratada apenas em ambientes sob seu controle e limitada às permissões mínimas necessárias, e que seus mecanismos e regras de gerenciamento de credenciais e de desenho de permissões foram insuficientes. As medidas que a empresa diz ter concluído incluem:
- Deixar de depender de tokens de acesso pessoal e adotar métodos de autenticação com permissões limitadas
- Revisar as permissões de acesso padrão dentro da organização
- Reforçar a coleta de logs de auditoria e os alertas
- Introduzir uma ferramenta de varredura de vulnerabilidades em código
Se você quiser fazer o mesmo na sua organização, comece por estas três.
Defina uma política de tokens de acesso pessoal na sua organização do GitHub
Nas configurações da organização, em "Personal access tokens", o GitHub permite que os proprietários da organização possam:
- Impedir que tokens de acesso pessoal (clássicos) acessem recursos da organização
- Exigir aprovação de administrador para tokens refinados (o tipo mais novo, restrito a repositórios e permissões específicos)
- Definir um tempo máximo de validade para os tokens
Como você nunca consegue impedir totalmente que um token de trabalho acabe em uma máquina ou servidor pessoal, a defesa realista é garantir que, se isso acontecer, ele deixe de funcionar logo e tenha acesso a muito pouco.
Mantenha chaves de nuvem de longa duração fora dos seus repositórios
A empresa diz que o terceiro usou informações visíveis no GitHub para encontrar e obter credenciais da nuvem. Se o GitHub Actions faz deploy na sua nuvem, mude para autenticação de curta duração via OpenID Connect (OIDC), que emite credenciais temporárias para cada execução, e mantenha chaves de acesso de longa duração fora dos repositórios e dos arquivos de configuração.
Primeiro, revise seus repositórios, incluindo o histórico, e revogue e reemita tudo o que encontrar; veja como detectar segredos antes do commit com o gitleaks. A proteção de push do GitHub, que bloqueia pushes com segredos, é gratuita para repositórios públicos e está disponível para privados como parte do GitHub Secret Protection pago.
Registre todos os lugares onde os dados de clientes ficam fora da produção
Plataformas de análise, ferramentas internas, painéis administrativos de suporte, CSVs exportados. Por mais que você reforce a produção, uma cópia dos dados de clientes em outro ambiente ainda pode vazar. Para cada local, registre quem tem credenciais para lê-lo e se as operações são registradas em log.
A CAMPFIRE diz que não pode descartar a visualização porque algumas áreas não tinham logs. Onde não há logs de operações, não é possível comprovar que ninguém visualizou os dados.
Visão deste site: planeje tokens considerando que eles podem sair das máquinas da empresa
A empresa diz que uma credencial do GitHub emitida para um funcionário foi enviada por engano a um servidor que ele usava para desenvolvimento pessoal. Isso não diz respeito a uma pessoa específica; reflete algo verdadeiro em qualquer organização — desenvolvedores também escrevem código fora do trabalho. Não é possível reduzir a zero a chance de um token de trabalho sair de máquinas gerenciadas. Por isso, prevenir vazamentos não basta: os tokens devem ser projetados para que, se algum vazar, expire rapidamente e tenha acesso a muito pouco.
Na sul-coreana TVING, no mesmo ano, a chave de acesso de um único desenvolvedor foi suficiente para alcançar todo o código-fonte e as credenciais de produção (o vazamento de dados da TVING). A porta de entrada comum nos incidentes japoneses daquele ano é tratada em as violações de 2026 usaram credenciais legítimas.
Fontes (registro público)
Os fatos deste artigo se baseiam nas fontes públicas abaixo. Não especulamos sobre métodos não divulgados.
- CAMPFIRE, Inc., comunicado sobre acesso não autorizado a uma conta do GitHub (3 de abril de 2026; em japonês) — campfire.co.jp
- Idem, segundo comunicado (14 de abril de 2026) — campfire.co.jp
- Idem, terceiro comunicado (22 de abril de 2026) — campfire.co.jp
- CAMPFIRE, Inc., pedido de desculpas e relatório sobre um possível vazamento de dados pessoais devido a acesso não autorizado (24 de abril de 2026) — campfire.co.jp
- CAMPFIRE, Inc., acompanhamento sobre a abrangência do possível vazamento (27 de abril de 2026) — campfire.co.jp
- CAMPFIRE, Inc., abertura de uma linha exclusiva de atendimento (28 de abril de 2026) — campfire.co.jp
- CAMPFIRE, Inc., resultados da investigação sobre o incidente de acesso não autorizado (2 de junho de 2026) — campfire.co.jp
- GitHub Docs, "Setting a personal access token policy for your organization" — docs.github.com / "About push protection" — docs.github.com / "About security hardening with OpenID Connect" — docs.github.com
Histórico de atualizações
2026-10-19: Corrigida a unidade de pessoas para a contagem oficial de registros únicos de usuários, distinguida a possível exposição de achados confirmados e mantidas as categorias sobrepostas sem somá-las.
2026-09-30: Primeira publicação, com base nos comunicados da CAMPFIRE, do primeiro comunicado de 3 de abril de 2026 ao relatório de investigação de 2 de junho. As contagens de registros seguem a distribuição do relatório de 2 de junho.
Leia também
- Outro caso japonês deste ano: Medica Shuppan (dados bancários de profissionais de saúde e autores)
- Golpes derivados: o que é phishing / como escolher um gerenciador de senhas
- Desenvolvedores: como detectar segredos antes do commit com o gitleaks / Git self-hosted vs. segurança do GitHub / noções básicas de .env e chaves de API
- Mesmo padrão: violações que usaram credenciais legítimas / o vazamento de dados da TVING
- Outros incidentes de 2026: vazamentos de dados e ciberataques em 2026