대상 독자: CAMPFIRE에서 프로젝트를 시작했거나, 후원했거나, 환불을 받았거나, 파트너로 등록한 사람, 그리고 업무에서 GitHub와 클라우드를 사용하는 개발자와 운영자입니다. 이 글은 CAMPFIRE의 공식 공지를 바탕으로 작성되었으며, 공격 기법은 다루지 않습니다.
사용자가 지금 해야 할 일
영향을 받았는지 확인하세요 — 안내 이메일의 제목은 정해져 있습니다
2026년 4월 24일부터 회사는 영향을 받은 사람에게 개별 이메일을 보내고 있으며, 제목은 일본어로 "【重要：CAMPFIRE】お客様情報漏えい可能性に関するお詫びとご報告"입니다(고객 정보 유출 가능성에 대한 사과 및 보고라는 뜻입니다). 영향을 받은 집단은 다음과 같습니다.
- 2026년 4월 9일까지 서비스를 이용한 일부 프로젝트 및 커뮤니티 소유자
- PayPal로 결제한 후원자(2021년 1월 1일 – 2026년 4월 19일) 또는 후불 결제 '콘도바라이'를 이용한 후원자(2022년 1월 3일 – 2023년 4월 24일)
- 계좌 이체로 환불받은 후원자(2022년 1월 6일 – 2026년 3월 5일)
- 2025년 3월 5일까지 등록한 파트너
- 2020년에 계정 페이지에서 은행 정보를 수정한 사람
위 조건에 해당하지만 안내 이메일을 찾을 수 없더라도 아래 단계는 따라 해 주세요.
환불이나 지급 계좌와 관련된 메시지의 링크를 열지 마세요
위험에 처한 데이터는 이름, 주소, 전화번호, 이메일 주소, 은행 계좌 정보입니다. '환불을 받으려면 계정을 다시 등록하라'거나 '자금을 어디로 보낼지 확인하라'는 메시지를 받으면 링크를 열지 마세요. 필요하다면 즐겨찾기나 직접 입력한 주소로 CAMPFIRE에 로그인하세요. 회사는 전화나 이메일로 PIN을 요구하지 않는다고 밝히고 있습니다(기본 개념: 피싱이란 무엇인가).
은행 거래 내역을 확인하세요
회사는 유출 가능성이 있는 은행 정보만으로는 현금을 인출하거나 송금할 수 없다고 말합니다. 그래도 낯선 거래가 보이면 즉시 은행이나 회사에 연락하라고 요청합니다. 인터넷뱅킹을 이용한다면 거래 알림을 켜 두면 확인이 더 쉬워집니다.
예상하지 못한 착불 택배를 거부하세요
주소가 포함되어 있으므로 회사는 주문하지 않은 착불 택배를 보내는 사기에 대해 경고합니다. 물건을 받기 전에 발송인과 내용물을 확인하세요.
다른 서비스에서 재사용하는 비밀번호를 바꾸세요
회사는 다른 서비스에서 같은 이메일 주소와 비밀번호를 사용하는 사람에게 예방 차원에서 비밀번호를 변경하라고 요청합니다. 비밀번호는 목록에 포함되어 있지 않지만, 지금 재사용을 끊으세요. 이때 비밀번호 관리자를 사용하면 실용적으로 해결할 수 있습니다.
프로젝트 소유자: 팀에도 알려 주세요
회사나 단체가 프로젝트를 운영한다면, 직원들이 지급이나 심사 안내를 사칭한 이메일을 받을 수 있습니다. 팀 차원에서 지급 계좌 변경은 CAMPFIRE 대시보드에서 확인하고, 이메일 지시만으로는 절대 행동하지 않기로 합의하세요.
회사의 전용 문의 번호는 0120-188-070입니다(7월부터 평일만 운영, 10:00–19:00 JST, 일본 내 무료 전화). 일본에서는 사기 관련 상담을 경찰 상담 전화 #9110에서 처리합니다.
무슨 일이 있었나 (CAMPFIRE 공지 기준)
회사는 2026년 4월 3일부터 6월 2일 조사 보고서까지 일련의 공지를 발표했습니다. 아래 내용은 모두 회사의 공식 공지에 나온 그대로입니다.
2026년 4월 2일, 약 22:50 JST
시스템 관리에 사용되는 GitHub 계정에 제3자가 무단으로 접근한 사실이 확인되었고, 일부 소스 코드가 열람되었을 수 있습니다(첫 공지 기준).4월 3일
일부 GitHub 저장소에서 의심스러운 작업이 감지되었습니다. 관련 계정을 삭제하고 유출되었을 수 있는 자격 증명을 교체했습니다. 첫 공지가 발표되었으며, 이 시점에는 개인 데이터 유출이 확인되지 않았습니다.4월 7일
GitHub 자격 증명 유출의 원인이 확인되었습니다.4월 14일
두 번째 공지: GitHub 계정으로 사업 파트너 1곳의 이름과 연락처, 개발 작업에 참여한 413명의 이름과 이메일 주소를 볼 수 있었습니다. 일본 개인정보보호위원회에 신고되었습니다.4월 20일
내부 업무용 클라우드 환경에 무단 접근이 감지되었습니다. 악용된 계정과 리소스는 중지되고 비활성화되었습니다.4월 22–24일
세 번째 공지에서 고객 정보를 관리하는 시스템의 일부에서 무단 접근 흔적이 보고되었습니다. 24일의 네 번째 공지에서 유출 가능성의 범위(고유 영향 사용자 기록 225,846건)가 공개되었고, 개별 안내가 시작되었습니다.4월 27–28일
다섯 번째 공지에서 세부 내역이 정리되었습니다. 28일에는 전용 문의 창구가 열렸습니다.5월 30일 / 6월 2일
외부 포렌식 조사가 완료되었습니다(5월 30일). 6월 2일 회사는 조사 결과와 재발 방지 조치를 발표했습니다.
- 일부 프로젝트 및 커뮤니티 소유자
- 이름, 주소, 전화번호, 이메일 주소, 은행 계좌 정보. 108,784건(은행 정보 포함 53,869건)
- 일부 후원자
- 이름, 주소, 전화번호, 이메일 주소, 은행 계좌 정보. 118,010건(은행 정보 포함 4,307건)
- 파트너
- 이름. 1,282건
- 분류 불분명(예: 등록 진행 중)
- 2020년에 계정 페이지에서 정보를 수정한 사람의 은행 계좌 정보. 10,521건
- 기타
- 개발 작업과 관련된 이름 및 이메일 주소 413건을 열람할 수 있었음
- 신용카드 정보
- 포함되지 않음
- 포렌식 조사 결과
- 특정 클라우드 환경에 저장된 자격 증명과 API 키, 개인 데이터가 없는 일부 데이터 파일, 테이블 이름과 설정 정보가 획득되었습니다. 탐색 과정에서 개인 데이터가 포함된 기록 1건이 조회 결과로 출력되었습니다. 개인 데이터가 포함된 파일이 외부로 전송된 흔적은 발견되지 않았습니다
- 회사의 평가
- 일부 영역에서 로그를 수집하지 않았기 때문에, 데이터가 열람되었을 가능성을 배제할 수 없습니다
- 2차 피해
- 공지 시점까지 데이터 악용으로 인한 피해는 보고되지 않았습니다
개발자와 운영자를 위해: GitHub 토큰에서 내부 클라우드까지
회사의 6월 2일 보고서는 사고 경로와 원인을 이례적으로 구체적으로 밝히고 있습니다. 아래 도표는 회사가 설명한 경로를 보여주며, 각 단계에서 피해를 막거나 줄이는 설정을 오른쪽에 제시합니다.
1. 직원이 발급받은 GitHub 자격 증명
개인 프로젝트용 서버에 의도치 않게 업로드됨
↓→
조직 정책: 클래식 토큰 차단, 유효 기간 제한
2. 조직 저장소
일부 소스 코드와 직원 413명의 데이터를 열람할 수 있음
↓→
최소 기본 권한, 저장소에 개인 데이터 보관 금지
3. GitHub 정보에서 클라우드 자격 증명으로
↓→
장기 유효 클라우드 키 사용 금지(단기 인증 사용)
4. 내부 클라우드 관리 영역의 일부
자격 증명, API 키, 테이블 이름 획득
↓→
모든 곳에 감사 로그, 비정상 작업 시 경고
5. 고유 영향 사용자 기록 225,846건의 고객 데이터 위험
↓→
운영 환경 밖의 고객 데이터 목록 작성
회사에 따르면, 이 서비스는 무단 접근이 발견된 클라우드 환경과 분리된 환경에서 운영되며, 서비스 플랫폼에서 악용이나 변조는 확인되지 않았습니다. 그럼에도 고객 데이터는 내부 업무용 클라우드에서 접근될 수 있었기 때문에 위험에 처했습니다.
회사는 해당 자격 증명이 회사가 통제하는 환경에서만 최소 권한으로 다뤄졌어야 했으며, 자격 증명 관리와 권한 설계를 위한 메커니즘과 규칙이 부족했다고 말합니다. 회사가 완료했다고 밝힌 조치는 다음과 같습니다.
- 개인 액세스 토큰에 대한 의존에서 벗어나 권한이 제한된 인증 방식으로 전환
- 조직 내 기본 접근 권한 검토
- 감사 로그 수집과 경고 체계 강화
- 코드 취약점 스캐닝 도구 도입
자신의 조직에서도 같은 조치를 하려면 아래 세 가지부터 시작하세요.
GitHub 조직에 개인 액세스 토큰 정책을 설정하세요
조직 설정의 "Personal access tokens"에서 조직 소유자는 다음을 설정할 수 있습니다.
- 클래식 개인 액세스 토큰(classic)이 조직 리소스에 접근하지 못하도록 차단
- 세분화된 토큰(특정 저장소와 권한으로 범위를 제한하는 최신 방식)에 관리자 승인 요구
- 토큰의 최대 유효 기간 설정
업무용 토큰이 개인 기기나 서버에 들어가는 것을 완전히 막을 수는 없으므로, 현실적인 방어는 토큰이 유출되더라도 곧 작동을 멈추고 접근할 수 있는 범위가 아주 작도록 만드는 것입니다.
장기 유효 클라우드 키를 저장소에서 멀리하세요
회사는 제3자가 GitHub에서 볼 수 있는 정보를 이용해 클라우드 자격 증명을 찾아 얻었다고 말합니다. GitHub Actions로 클라우드에 배포한다면, 실행 단위마다 임시 자격 증명을 발급하는 OpenID Connect(OIDC) 기반 단기 인증으로 전환하고, 장기 액세스 키는 저장소와 설정 파일에서 빼세요.
먼저 커밋 이력을 포함해 저장소 전체를 점검하고, 발견된 키는 폐기 후 재발급하세요. 자세한 방법은 gitleaks로 커밋 전에 시크릿 잡아내기를 참고하세요. 시크릿이 포함된 푸시를 차단하는 GitHub의 push protection은 공개 저장소에서는 무료이며, 비공개 저장소에서는 유료 GitHub Secret Protection에 포함되어 사용할 수 있습니다.
운영 환경 밖에 있는 고객 데이터의 위치를 모두 기록하세요
분석 플랫폼, 내부 도구, 고객 지원 관리자 화면, 내보낸 CSV 파일 등이 여기에 해당합니다. 운영 환경을 아무리 강화하더라도 다른 환경에 있는 고객 데이터 사본은 여전히 유출될 수 있습니다. 각 위치마다 누가 그 데이터를 읽을 수 있는 자격 증명을 가지고 있는지, 작업이 로그로 남는지 기록하세요.
CAMPFIRE는 일부 영역에 로그가 없었기 때문에 열람 가능성을 배제할 수 없다고 말합니다. 작업 로그가 없는 곳에서는 아무도 데이터를 보지 않았다는 사실을 증명할 수 없습니다.
이 사이트의 견해: 토큰이 회사 기기 밖으로 나갈 수 있다고 가정하고 설계하세요
회사는 직원이 발급받은 GitHub 자격 증명이 직원이 개인 개발에 쓰던 서버에 의도치 않게 업로드되었다고 말합니다. 이것은 특정 개인의 문제가 아니라, 모든 조직에서 사실인 부분을 보여줍니다. 개발자는 업무 외에서도 코드를 작성합니다. 업무용 토큰이 관리되는 기기 밖으로 나갈 가능성을 0으로 만들 수는 없습니다. 따라서 유출을 막는 것만으로는 충분하지 않고, 밖으로 나간 토큰이 빠르게 만료되고 접근 범위가 아주 작도록 설계해야 합니다.
같은 해 한국의 TVING에서는 한 개발자의 액세스 키 하나로 모든 소스 코드와 운영 환경 자격 증명에 접근할 수 있었습니다(TVING 데이터 유출). 같은 해 일본 사고들에서 공통으로 나타난 침입 경로는 2026년 침해 사고는 정상 자격 증명으로 이루어졌다에서 다룹니다.
출처(공개 기록)
이 글의 사실관계는 아래 공개 출처를 바탕으로 합니다. 공개되지 않은 방법에 대해서는 추측하지 않습니다.
- CAMPFIRE, Inc., GitHub 계정 무단 접근 공지(2026년 4월 3일, 일본어) — campfire.co.jp
- 같은 회사, 두 번째 공지(2026년 4월 14일) — campfire.co.jp
- 같은 회사, 세 번째 공지(2026년 4월 22일) — campfire.co.jp
- CAMPFIRE, Inc., 무단 접근으로 인한 개인 데이터 유출 가능성에 대한 사과 및 보고(2026년 4월 24일) — campfire.co.jp
- CAMPFIRE, Inc., 유출 가능성 범위에 대한 후속 공지(2026년 4월 27일) — campfire.co.jp
- CAMPFIRE, Inc., 전용 문의 창구 개설 공지(2026년 4월 28일) — campfire.co.jp
- CAMPFIRE, Inc., 무단 접근 사고 조사 결과(2026년 6월 2일) — 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
업데이트 기록
2026-10-19: 단위를 사람 수에서 공식 고유 사용자 기록 수로 수정했고, 유출 가능성과 확인된 사실을 구분했으며, 겹치는 분류는 합산하지 않고 그대로 유지했습니다.
2026-09-30: 2026년 4월 3일 첫 공지부터 6월 2일 조사 보고서까지 CAMPFIRE의 공지를 바탕으로 처음 발행되었습니다. 기록 수는 6월 2일 보고서의 세부 내역을 따랐습니다.
다음으로 읽을 글
- 같은 해 일본의 다른 사례: Medica Shuppan(의료 전문가와 저자의 은행 정보)
- 후속 사기: 피싱이란 무엇인가 / 비밀번호 관리자 고르기
- 개발자: gitleaks로 커밋 전에 시크릿 잡아내기 / 자체 호스팅 Git과 GitHub 보안 비교 / .env와 API 키 기초
- 같은 유형: 정상 자격 증명으로 이루어진 침해 사고 / TVING 데이터 유출
- 2026년 기타 사고: 2026년 데이터 유출과 사이버 공격