Skip to content
>_ITDITDWeb Security Platform

Security Guides

#data breach#phishing#credentials#Git#Japan

Production was untouched, but customer data lived elsewhere — what CAMPFIRE users and developers should do after the breach

At Japanese crowdfunding site CAMPFIRE, a compromised GitHub account led to an internal cloud and put data of 225,846 people, including some bank details, at risk. From the company's notices: who is affected, what to do, and GitHub token lessons.

Published 2026-09-30 Updated 2026-09-30 Last verified 2026-09-30 13 min read

Who this is for: people who launched a project on CAMPFIRE, backed one, received a refund, or registered as a partner — and developers and operators who use GitHub and the cloud at work. This article is based on CAMPFIRE's own official notices and does not cover attack techniques.

What users should do now

1

Check whether you are affected — the notification email has a fixed subject

Since April 24, 2026, the company has been emailing affected people individually, with the Japanese subject line "【重要：CAMPFIRE】お客様情報漏えい可能性に関するお詫びとご報告" (an apology and report on a possible leak of customer information). The affected groups are some project and community owners who used the service up to April 9, 2026, supporters who paid with PayPal (Jan 1, 2021 – Apr 19, 2026) or the Kondo-barai deferred payment (Jan 3, 2022 – Apr 24, 2023), supporters who received refunds by bank transfer (Jan 6, 2022 – Mar 5, 2026), partners registered by March 5, 2025, and people who edited bank details on their account page in 2020. If you fit any of these but can't find the email, follow the steps anyway.

2

Don't open links in messages about refunds or payout accounts

The data at risk is name, address, phone number, email address and bank account details. If you receive "re-register your account for your refund" or "confirm where we should send your funds", don't open the link; if needed, log in to CAMPFIRE from a bookmark or an address you type yourself. The company states it never asks for PINs by phone or email (basics: what is phishing).

3

Check your bank statements

The company says the possibly leaked bank details alone cannot be used to withdraw cash or make transfers. It asks you to contact your bank or the company right away if you see unfamiliar transactions. If you use online banking, turning on transaction notifications makes this easier.

4

Refuse unexpected cash-on-delivery packages

Because addresses are included, the company warns about scams that send cash-on-delivery packages you never ordered. Check the sender and contents before accepting.

5

Change reused passwords on other services

The company asks people who use the same email address and password on other services to change them as a precaution. Passwords aren't among the listed items, but end the reuse now; a password manager is the practical way to do it.

6

Project owners: brief your team too

If a company or group runs your project, staff may receive emails posing as payout or review notices. Agree as a team to verify payout-account changes in the CAMPFIRE dashboard and never act on email instructions alone. The company's dedicated line is 0120-188-070 (10:00–19:00 JST, weekdays only since July; toll-free in Japan), and in Japan the police consultation line #9110 handles fraud concerns.

What happened (per CAMPFIRE's notices)

The company published a series of notices from April 3, 2026 through its investigation report of June 2. Everything below is as stated in the company's official notices.

  1. April 2, 2026, ~22:50 JST

    Unauthorized access by a third party to the GitHub account used for system management was identified, and some source code may have been viewed (as stated in the first notice).

  2. April 3

    Suspicious operations on some GitHub repositories were detected; related accounts were removed and possibly stolen credentials replaced. First notice published (no personal data leak confirmed at that point).

  3. April 7

    The cause of the GitHub credential leak was identified.

  4. April 14

    Second notice: the GitHub account could view the name and contact details of one business partner, and names and email addresses of 413 people who worked on development. Reported to Japan's Personal Information Protection Commission.

  5. April 20

    Unauthorized access to a cloud environment used for internal business detected; misused accounts and resources stopped and disabled.

  6. April 22–24

    Third notice reported traces of unauthorized access in part of a system managing customer information. Fourth notice (24th) disclosed the scope of possible leakage (225,846 people) and individual notifications began.

  7. April 27–28

    Fifth notice refined the breakdown. A dedicated inquiry line opened on the 28th.

  8. May 30 / June 2

    External forensic investigation completed (May 30). On June 2 the company published its investigation results and prevention measures.
225,846
People whose data may have leaked (de-duplicated)
53,869
Owner records with bank details (plus 4,307 supporter and 10,521 unclassified records with bank details)
Not included
Credit card data
Separate
Service platform (no misuse or tampering found)
Data possibly leaked (CAMPFIRE investigation report, June 2, 2026)
Some project and community owners
Name, address, phone number, email address, bank account details. 108,784 records (53,869 with bank details)
Some supporters
Name, address, phone number, email address, bank account details. 118,010 records (4,307 with bank details)
Partners
Name. 1,282 records
Category unclear (e.g., mid-registration)
Bank account details of people who edited them on their account page in 2020. 10,521 records
Other
Names and email addresses of 413 people who worked on development were viewable
Credit card data
Not included
Forensic findings
Credentials and API keys stored in a specific cloud environment, some data files without personal data, and table names and configuration information were obtained. During exploration, one record containing personal data was output as a query result. No traces were found of files containing personal data being transferred out
Company's assessment
Because logs were not collected in some areas, it cannot rule out that data was viewed
Secondary harm
No harm from misuse of the data had been reported at the time of the notices

For developers and operators: from a GitHub token to an internal cloud

The company's June 2 report is unusually specific about the sequence and cause. The figure lays out the path as the company described it, with the settings that could stop it on the right.

1. GitHub credential issued by an employee

Unintentionally uploaded to a personal-project server

↓

Org policy: block classic tokens, cap lifetimes

2. Organization repositories

Some source code and data on 413 staff viewable

↓

Minimal default permissions, no personal data in repos

3. From GitHub information to cloud credentials

↓

No long-lived cloud keys (use short-lived auth)

4. Part of the internal cloud's management area

Credentials, API keys, table names obtained

↓

Audit logs everywhere, alerts on unusual actions

5. Customer data of 225,846 people at risk

↓

Inventory customer data outside production

The path CAMPFIRE disclosed (left) and settings that limit damage at each stage (right). The route to customer data ran through an internal business cloud, not the service's production environment.

According to the company, the service runs in an environment separate from the cloud environment where the unauthorized access was found, and no misuse or tampering of the service platform was identified. Customer data was still put at risk because it was reachable from the internal business cloud. The company says the credential in question should have been handled only in environments under its control and limited to the minimum permissions, and that its mechanisms and rules for credential management and permission design were insufficient.

Measures the company says it has completed include moving away from reliance on personal access tokens to authentication methods with limited permissions, reviewing default access permissions within the organization, strengthening audit log collection and alerting, and introducing a code vulnerability scanning tool. If you want to do the same in your own organization, start with these three.

1

Set a personal access token policy in your GitHub organization

GitHub lets organization owners stop personal access tokens (classic) from accessing organization resources, require administrator approval for fine-grained tokens, and set a maximum token lifetime (organization Settings, "Personal access tokens"). Since you can never fully prevent a work token from landing on a personal machine or server, the realistic defense is making sure that if it does, it won't work for long or reach far.

2

Keep long-lived cloud keys away from your repositories

The company says the third party used information viewable on GitHub to find and obtain cloud credentials. If GitHub Actions deploys to your cloud, switch to short-lived authentication via OpenID Connect (OIDC) and keep long-lived access keys out of repositories and config files. First sweep your repositories, including history, and revoke and reissue anything you find; see catching secrets before commit with gitleaks. GitHub's push protection, which blocks pushes containing secrets, is free for public repositories and available for private ones as part of the paid GitHub Secret Protection.

3

Write down every place customer data lives outside production

Analytics platforms, internal tools, support admin panels, exported CSVs. However well you harden production, a copy of customer data in another environment becomes the way in. For each location, record whose credentials can read it and whether operations are logged. CAMPFIRE says it cannot rule out viewing because some areas had no logs. A place without logs is a place where you can't prove nothing happened.

This site's view: design tokens assuming they will leave the company's machines

The company says a GitHub credential issued by an employee was unintentionally uploaded to a server the employee used for personal development. This isn't about any one person; it reflects something true in every organization — developers also write code outside work. You can't get the chance of a work token leaving managed machines to zero. So defense can't rely only on "don't let it out"; it must be designed so that a token that gets out expires quickly and reaches very little. At South Korea's TVING the same year, one developer's access key led to all source code and to production keys (the TVING data breach). The common entry route across Japanese incidents that year is covered in 2026 breaches ran on legitimate credentials.

Sources (public record)

The facts in this article are based on the public sources below. We do not speculate about undisclosed methods.

  • CAMPFIRE, Inc., notice of unauthorized access to a GitHub account (April 3, 2026; Japanese) — campfire.co.jp
  • Same, second notice (April 14, 2026) — campfire.co.jp
  • Same, third notice (April 22, 2026) — campfire.co.jp
  • CAMPFIRE, Inc., apology and report on a possible personal data leak due to unauthorized access (April 24, 2026) — campfire.co.jp
  • CAMPFIRE, Inc., follow-up on the scope of the possible leak (April 27, 2026) — campfire.co.jp
  • CAMPFIRE, Inc., opening of a dedicated inquiry line (April 28, 2026) — campfire.co.jp
  • CAMPFIRE, Inc., investigation results on the unauthorized access incident (June 2, 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

Update history

2026-09-30: First published, based on CAMPFIRE's notices from the first notice of April 3, 2026 to the investigation report of June 2. Record counts follow the breakdown in the June 2 report.

FAQ

QWhat was leaked in the CAMPFIRE breach?
A

According to CAMPFIRE's investigation report of June 2, 2026, data possibly leaked covers some project and community owners (108,784 records) and some supporters (118,010 records) — names, addresses, phone numbers, email addresses and bank account details — plus partners (1,282 records, names only) and 10,521 records whose category is unclear (bank account details). After removing duplicates, 225,846 people are affected. Credit card data is not included. Names and email addresses of 413 people who worked on development were also viewable.

QAm I affected?
A

According to the company, the affected groups are some project and community owners who used CAMPFIRE up to April 9, 2026; supporters who paid with PayPal between January 1, 2021 and April 19, 2026; supporters who used the 'Kondo-barai' deferred payment between January 3, 2022 and April 24, 2023; supporters who received refunds by bank transfer between January 6, 2022 and March 5, 2026; partners registered by March 5, 2025; and people who edited bank details on their account page in 2020. Affected people have been notified individually by email since April 24, 2026.

QCan someone withdraw money with my leaked bank details?
A

CAMPFIRE says the bank account details that may have leaked cannot by themselves be used to withdraw cash or make transfers from your account. It asks anyone who sees unfamiliar transactions on their statement to contact their bank or the company immediately. Bank details can also make refund or payout scams look more convincing, so be wary of such messages.

QShould I change my password?
A

The company asks people who use the same email address and password on other services to change them as a precaution. Passwords are not listed among the possibly leaked items, but it is a good moment to end password reuse.

QWhat caused the breach?
A

According to the company's June 2 report, a GitHub credential issued by an employee was unintentionally uploaded to a server the employee used for personal development and was misused by a third party. The company believes the third party then used information viewable on GitHub to find and obtain credentials for a cloud environment used for internal business, and accessed part of its management area. The company says its mechanisms and rules for credential management and permission design were insufficient.

QWas personal data actually taken?
A

According to the external forensic investigation results the company received, no traces were found of data files containing personal data being transferred out, and one record containing personal data was output as a query result during exploration. The company nonetheless says it cannot rule out that data was viewed, because logs were not collected in some areas.