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
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
- 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.
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).
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.
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.
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.
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.
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).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).April 7
The cause of the GitHub credential leak was identified.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.April 20
Unauthorized access to a cloud environment used for internal business detected; misused accounts and resources stopped and disabled.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 unique affected-user records) and individual notifications began.April 27–28
Fifth notice refined the breakdown. A dedicated inquiry line opened on the 28th.May 30 / June 2
External forensic investigation completed (May 30). On June 2 the company published its investigation results and prevention measures.
- 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
- 413 records of names and email addresses relating to development work 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 settings that prevent or limit the damage at each stage 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 in 225,846 unique affected-user records at risk
↓→
Inventory customer data outside production
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 could be accessed 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
- Introducing a code vulnerability scanning tool
If you want to do the same in your own organization, start with these three.
Set a personal access token policy in your GitHub organization
In organization Settings, "Personal access tokens", GitHub lets organization owners:
- Stop personal access tokens (classic) from accessing organization resources
- Require administrator approval for fine-grained tokens (the newer type, scoped to specific repositories and permissions)
- Set a maximum token lifetime
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 stops working soon and can access very little.
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), which issues temporary credentials for each run, 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.
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 can still leak. 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. Where there are no operation logs, you can't prove that no one viewed the data.
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 preventing leaks isn't enough; tokens must be designed so that one that gets out expires quickly and can access very little.
At South Korea's TVING the same year, one developer's access key was enough to reach all source code and production credentials (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-10-19: Corrected the unit from people to the official unique user-record count, distinguished possible exposure from confirmed findings, and retained overlapping categories without summing them.
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.
Read next
- Another Japanese case this year: Medica Shuppan (medical professionals and authors' bank details)
- Follow-on scams: what is phishing / choosing a password manager
- Developers: catching secrets before commit with gitleaks / self-hosted Git vs GitHub security / .env and API key basics
- Same pattern: breaches that ran on legitimate credentials / the TVING data breach
- Other 2026 incidents: data breaches and cyberattacks in 2026