Stripe API 키 노출로 659개 가맹점 계정과 고객 데이터 유출 위험

이번 사건은 Stripe 플랫폼 자체가 뚫린 침해사고라기보다, 개별 가맹점이 보유하던 결제 API 인증정보가 노출된 사건으로 보는 것이 현재까지 가장 타당하다. 2026년 8월 18일 ‘Satanic’이라는 이름을 사용한 행위자는 약 35GB 규모의 아카이브를 한 사이버범죄 포럼에 무료로 공개했다. 보고된 아카이브에는 659개 가맹점 계정에서 추출된 1만7,654개 파일과 42개국 약 68만8,363명 고객 관련 데이터가 포함된 것으로 전해졌다. 다만 이 수치는 보고된 추정치이며, 위협 행위자가 추가로 제시한 일부 규모 주장은 독립적으로 검증되지 않았다.

아카이브에 포함된 것으로 알려진 정보

자료는 2022년 1월부터 2026년 6월까지의 기록을 포함한 것으로 분석됐다. 보고된 데이터 유형은 다음과 같다.

• Stripe 고객 객체와 고객 연락처 정보
• 결제 청구(charge), 결제 인텐트(payment intent), Checkout 세션
• 인보이스, 환불, 분쟁 기록
• 지급금과 잔액 거래 내역
• 구독, 상품, 가격 정보
• 카드 브랜드, 끝 4자리, 만료일, 자금 유형, 발급 국가, 결제 지문(payment fingerprint) 등 결제 관련 메타데이터

현재 보도만으로는 아카이브에 카드 전체 번호가 포함됐다고 보기는 어렵다. 이는 일부 직접적인 카드 도용 위험을 낮추는 요소지만, 노출된 API 인증정보와 상세한 고객·거래 데이터가 만들어내는 위험까지 없애지는 못한다.

연구진은 정상 작동하는 sk_live 비밀 키 650개와 제한형 키 9개를 확인했다고 밝혔다. 영향을 받은 계정 가운데 573개는 결제를 받을 수 있었고, 531개는 지급금을 보낼 수 있었으며, 519개는 두 기능 모두를 사용할 수 있었던 것으로 분석됐다.

실시간 키 하나만 노출돼도 위험한 이유

Stripe 비밀 키는 단순한 계정 식별자가 아니라 API에 접근하기 위한 인증정보다. 실제 영향 범위는 키의 권한과 가맹점 계정 설정에 따라 달라지지만, 탈취된 키는 가맹점 리소스에 접근하거나 승인되지 않은 결제 관련 작업을 수행하는 데 악용될 수 있다.

보도된 테스트에서는 활성 키 하나로 고객 목록에 접근하고, 사기성 결제 링크를 만들며, 테스트 청구를 생성할 수 있었다. 이는 고객 정보 열거, 결제 악용, 무단 환불, 표적 피싱, 결제 관련 사회공학 공격으로 이어질 수 있다. 지급 기능이 활성화된 계정은 지급 설정과 수취 계좌 정보까지 추가로 확인해야 한다.

특히 서버 측 인증정보가 노출되면 가맹점이 이상 징후를 알아차리기도 전에 비밀 관리 실패가 실제 결제 사기 조사로 번질 수 있다는 점이 핵심이다.

Stripe 인프라 침해로 분류되지 않은 이유

공개된 자료를 오프라인에서 분석한 연구진은 Stripe 형식의 객체와 디렉터리 구조가 API 엔드포인트를 통한 내보내기 결과와 일치한다고 설명했다. 다만 연구진은 검토 과정에서 노출된 키로 인증하거나 가맹점의 실시간 환경에 직접 접근하지는 않았다.

현재 증거는 Stripe 핵심 시스템의 침해보다는 가맹점이 관리하던 인증정보의 손상 가능성을 가리킨다. 가능한 노출 경로로는 다음과 같은 사례가 거론된다.

• 개발자나 관리자의 기기에 설치된 인포스틸러(infostealer)
• 공개 코드 저장소와 과거 Git 기록
• 외부에 노출된 .env 파일과 서버 설정
• 클라우드 저장소, 백업, 컨테이너 이미지
• CI/CD 시스템과 GitHub Actions 로그
• 잘못 설정된 서버 또는 노출된 환경변수를 자동으로 찾는 스캔

다만 659개 가맹점 인증정보가 최초로 어떤 경로에서 탈취됐는지는 확인되지 않았다. 위 항목은 가능한 노출 경로이지, 전체 데이터에 대해 확정된 단일 원인은 아니다.

관련 공개 자료와 숫자를 해석할 때의 주의점

Hudson Rock은 같은 행위자와 관련된 별도의 포럼 공개 자료를 언급했다. 해당 자료는 669개 공급업체 폴더와 1,033개의 손상된 API 키, 광고상 33GB 규모로 설명됐다. 다만 연결된 다운로드 파일은 이보다 작은 것으로 알려졌다. 행위자는 약 2만 개의 추가 손상 Stripe API 키를 보유하고 있으며 추가 공개가 이어질 수 있다고 주장했다.

659개 가맹점 계정, 669개 공급업체 폴더, 1,033개 키라는 숫자를 하나의 확정된 총계로 합산해서는 안 된다. 서로 다른 데이터셋, 계정당 여러 키, 중복 자료, 집계 방식의 차이가 반영됐을 수 있기 때문이다. ‘2만 개’라는 수치 역시 행위자의 검증되지 않은 주장으로 남아 있다.

보고된 피해 가맹점이 많았던 국가

현재 보도에서 확인된 주요 가맹점 분포는 다음과 같다.

• 미국: 212개
• 영국: 81개
• 프랑스: 57개
• 캐나다: 38개
• 브라질: 30개
• 호주: 27개

이는 공개된 자료에서 보고된 가맹점 분포이며, 전체 데이터셋의 범위가 계속 평가 중이라는 점을 함께 고려해야 한다.

Stripe를 사용하는 기업이 지금 해야 할 일

1. 실시간 비밀 키를 즉시 교체한다

소스 코드, 로그, 백업, 엔드포인트 텔레메트리, 컨테이너 이미지 또는 공개 인프라에 나타났을 가능성이 있는 모든 실시간 비밀 키를 폐기하고 새로 발급해야 한다. 부정 결제 증거가 발견될 때까지 기다릴 필요는 없다.

2. API 활동과 결제 작업을 감사한다

API 및 보안 로그에서 익숙하지 않은 호출, 새로 생성된 결제 링크, 테스트 또는 무단 청구, 예상하지 못한 환불, 권한 변경, 낯선 IP 주소를 확인한다. 조사자가 시간순으로 상황을 재구성할 수 있도록 관련 로그도 보존해야 한다.

3. 지급 설정을 검증한다

지급 설정, 연결된 은행 계좌 정보, 지급 대상과 목적지를 점검한다. 의심스러운 변경이 확인되면 Stripe와 금융기관에 신속히 알리고, 적용되는 사고 대응 및 신고 절차를 따라야 한다.

4. 광범위한 키 대신 제한형 키를 사용한다

각 서비스가 실제로 필요한 API 작업만 수행하도록 권한 범위를 최소화한 제한형 키를 사용한다. 하나의 광범위한 비밀값을 여러 애플리케이션에 배포하지 말고, 운영·개발 환경과 담당 역할도 분리해야 한다.

5. 비밀값이 남을 수 있는 모든 위치를 검색한다

현재 및 과거 저장소, Git 기록, CI/CD 출력물, GitHub Actions 로그, .env 파일, 컨테이너 레이어, 클라우드 저장소, 문서와 백업에서 sk_live 값을 검색한다. 현재 코드에 보이지 않더라도 과거에 노출된 인증정보는 폐기하고 교체해야 한다.

6. GitHub 비밀 스캔만으로 충분하다고 생각하지 않는다

GitHub는 공개 저장소에 대해 비밀 스캔을 자동으로 실행하지만, 조직이 소유한 비공개·내부 저장소에는 대상 요금제에서 GitHub Secret Protection을 활성화해야 한다. 또한 비밀 스캔은 이미 로그, 백업, 엔드포인트 텔레메트리 또는 다운로드된 아카이브로 복사된 인증정보를 회수하지 못한다. 따라서 중앙집중형 비밀 관리, 짧은 인증정보 수명, 접근 통제, 지속적인 모니터링을 보완하는 수단으로 활용해야 한다.

가맹점이 얻어야 할 핵심 교훈

이번 사건은 결제 플랫폼의 보안이 플랫폼 사업자뿐 아니라 가맹점의 인증정보 관리 수준에도 달려 있음을 보여준다. 현재 보도는 Stripe 인프라 침해를 입증하지 않지만, 노출된 실시간 API 키가 고객 데이터 접근과 결제 악용의 통로가 될 수 있다는 점은 분명히 보여준다. 운영 환경의 비밀 키를 코드와 로그에서 분리하고, 권한을 제한하며, 노출 가능성이 생기는 즉시 교체하고, 예상하지 못한 API 호출이나 지급 이벤트를 빠르게 조사해야 한다.