하이브 위버스 42만 건 정보유출, 결제 처리용 내부 API가 외부에 그대로 뚫렸다

[핵심요약] 하이브 위버스컴퍼니가 운영하는 팬 플랫폼 위버스에서 결제 처리용 내부 API가 접근 제어 없이 외부에 노출돼 계정 42만2584건의 정보가 유출됐어요. 이름·연락처는 빠졌지만 결제 패턴과 내부식별정보가 함께 새어나갔어요.

2026년 9월 6일, 하이브 산하 위버스컴퍼니가 팬 플랫폼 위버스에서 개인정보 유출 사고가 있었다고 공식 사과했어요. 앞서 9월 3일 한국인터넷진흥원(KISA)이 외부 제보자로부터 위버스 서비스의 보안 취약점을 제보받았다고 알려오면서 사고가 드러났어요. 회사가 자체 점검한 결과 계정 ID 기준 42만2584건의 정보가 외부에 노출된 것으로 확인됐어요. 유출 경로는 결제 정보를 처리하는 내부용 API였는데, 접근 제어가 제대로 걸려 있지 않아 외부에서도 그대로 호출할 수 있는 상태였어요.

어쩌다 결제 API가 뚫렸나요?

위버스컴퍼니에 따르면 유출된 정보는 크게 두 가지예요. 하나는 이용자가 가입할 때 내부적으로만 쓰도록 생성되는 내부식별정보고, 다른 하나는 결제수단, PG사명, 통화 형태, 구매·취소 금액, 결제 일시, 환불 일시 같은 결제 관련 일반정보예요. 문제는 이 정보를 다루는 API가 시스템 간 통신을 위해 설계된 '내부용'이었다는 점이에요. 원래대로라면 내부망 안에서만 오갔어야 할 요청이 외부 네트워크에서도 접근 가능하게 열려 있었고, 공격자로 추정되는 외부 행위자가 이 API를 비정상적으로 반복 호출하는 방식으로 데이터를 긁어간 것으로 파악됐어요. 회사는 사고를 인지하자마자 API 접근 제어를 강화하고 외부로 나가는 응답값에서 내부식별자를 제거했으며, 9월 4일 KISA에 점검 결과를 신고했어요. 양주일 대표는 6일 공식 사과문을 내고 외부 노출 API 전수조사와 보안 모니터링 강화를 약속했어요.

왜 특히 뼈아픈 사고인가요?

다행히 이름이나 연락처처럼 개인을 직접 특정할 수 있는 정보는 이번 유출 범위에 없어서, 회사 설명대로 결제 위조나 부정 이체로 바로 이어질 가능성은 낮아요. 그런데도 이 사고가 가볍지 않은 이유는 따로 있어요. 먼저 위버스는 전 세계 수천만 명이 쓰는 글로벌 팬 플랫폼이라, 국내뿐 아니라 해외 이용자의 신뢰에도 타격이 커요. 또 이번 사고를 회사가 스스로 탐지한 게 아니라 외부 제보자가 KISA에 취약점을 알려오면서 뒤늦게 인지했다는 점도 뼈아픈 대목이에요. 최근 국내에서 반복되고 있는 대형 유출 사고들 - 티빙의 개발자 액세스키 유출, 배달대행 플라이의 Firebase 설정 오류, SK이노베이션·롯데케미칼의 내부 시스템 노출 - 을 보면 공통점이 하나 있어요. 정교한 해킹 기법이 아니라 '기본적인 접근 제어를 빠뜨린' 실수가 사고의 시작이라는 점이에요. 내부식별정보와 결제 패턴이 결합된 데이터는 그 자체로는 무해해 보여도, 향후 정교한 사칭 메일이나 사회공학 공격의 재료로 재활용될 수 있다는 점도 눈여겨봐야 해요.

API 보안, 뭐부터 챙겨야 하나요?

API는 사람이 아니라 시스템끼리 주고받는 창구라서, 정작 보안 점검에서 사각지대로 밀려나는 경우가 많아요. 특히 내부 시스템 간 통신용으로만 설계했던 API가 서비스가 커지면서 자기도 모르게 외부에 노출되는 '섀도우 API' 문제는 국내외 기업 대부분이 안고 있는 위험이에요. 먼저 우리 서비스가 외부에서 실제로 접근 가능한 API 목록을 최근에 전수 조사한 적이 있는지부터 확인해야 해요. 그다음엔 내부용 API에는 IP 화이트리스트나 별도 인증 토큰 같은 최소한의 접근 제어를 걸고, 결제·정산처럼 민감한 데이터를 다루는 API는 응답값에 불필요한 내부 정보가 그대로 노출되지 않도록 응답 필드를 다시 설계해야 해요. 이번 사고가 외부 제보로 드러났다는 점도 시사하는 바가 커요. 화이트해커나 이용자가 취약점을 발견했을 때 편하게 신고할 수 있는 채널(버그바운티 등)을 실제로 운영하고 있는지, 신고가 들어왔을 때 며칠 안에 대응하는 프로세스가 마련돼 있는지도 함께 점검해볼 부분이에요.

• 외부에서 접근 가능한 API 목록을 최근 1년 내 전수 점검한 적이 있나요?
• 내부 시스템 간 통신용으로 설계된 API에 별도 인증·IP 제한이 걸려 있나요?
• 결제·정산 관련 API 응답값에 불필요한 내부 식별자나 원본 데이터가 그대로 담겨 있진 않나요?
• API 접근 로그에서 짧은 시간에 반복적으로 조회되는 비정상 패턴을 탐지할 수 있나요?
• 외부 보안 취약점 제보(버그바운티) 채널이 있고, 실제로 며칠 안에 대응하는 절차가 있나요?

위버스 이용자는 결제 정보가 실제로 도용될 위험이 있나요?

이름이나 연락처 같은 직접 식별정보는 유출 범위에 없어서 결제 위조 자체는 어렵다고 회사는 설명했어요. 다만 내부식별정보와 결제 패턴이 결합된 데이터는 정교한 사칭 메일의 소재로 쓰일 수 있어서, 위버스에서 온 것처럼 보이는 결제 확인·환불 안내 메일은 한 번 더 의심해 보는 게 안전해요.

왜 '내부용'이라던 API가 외부에서 접근됐나요?

시스템 간 통신만을 위해 설계된 API였지만, 접근 제어 설정이 빠진 채 외부 네트워크에서도 호출 가능한 상태로 운영되고 있었어요. 공격자로 추정되는 외부 행위자가 이 API를 비정상적으로 반복 조회하는 방식으로 데이터를 확보한 것으로 파악돼요.

이번 사고는 회사가 직접 발견했나요?

아니요. 9월 3일 KISA가 외부 제보자로부터 위버스 서비스의 보안 취약점 제보를 받았다고 알려오면서 사고가 드러났어요. 자체 모니터링이 아니라 외부 신고로 뒤늦게 인지했다는 점이 이번 사고의 약한 고리로 지적돼요.

위버스 사고는 개인정보를 직접 훔친 사건이라기보다, 시스템끼리만 주고받아야 할 창구 하나가 무방비로 열려 있었던 사건에 가까워요. 결제 정보처럼 민감한 데이터를 다루는 API일수록 접근 제어는 선택이 아니라 최소한의 전제조건이라는 걸 다시 한번 보여준 사례예요. 규모가 크든 작든, 외부에 노출된 API가 있다는 사실조차 모르고 있다면 그게 가장 위험한 상태라는 걸 이번 사고가 알려주고 있어요.

이런 사고를 막으려면 API 하나가 뚫리더라도 그 뒤에 있는 백업 데이터까지는 손댈 수 없는 이중 안전장치가 필요해요. 물리적으로 분리된 이중 데이터 다이오드 방식의 디포트리스가 그 역할을 해줘요. API가 뚫려도 백업까지는 왜 안전한지 궁금하다면 여기서 확인해보세요.