핵심 요약
- 해커가 제3자 공급업체 침해를 통해 폴리마켓(Polymarket) 프론트엔드에 악성 스크립트를 삽입해 약 300만 달러 상당의 고객 자금을 탈취한 것으로 추정된다.
- 폴리마켓은 피해 고객에 대해 자산을 전액 환불하겠다는 방침을 공식화했다.
- 공격 표면이 플랫폼 자체가 아닌 외부 벤더였기 때문에 전통적인 코드 감사만으로는 차단이 어려운 공급망 리스크가 다시 한번 부각되고 있다.
이번 사건은 웹3 서비스가 자체 보안뿐 아니라 서드파티 공급망 전반의 무결성까지 함께 관리해야 할 필요성을 명확히 보여준다.
2026년 6월 26일, Bleeping Computer는 예측 시장 플랫폼 폴리마켓이 제3자 공급업체 침해를 통한 공급망 공격(supply chain attack)으로 약 300만 달러의 고객 자금을 잃었다고 보도했다. 공격은 플랫폼의 자체 서버가 아닌 프론트엔드에 로드되는 외부 스크립트를 변조해 발생했으며, 폴리마켓은 전액 환불 방침을 공식화했다. 이번 사건은 코드 감사와 스마트 계약 검토를 통과한 서비스조차 외부 벤더 한 곳의 취약점으로 무너질 수 있음을 다시 한번 확인한 사례로 분석된다.
공격 개요: 폴리마켓 서드파티 벤더에서 시작된 침해
보도에 따르면 이번 사건의 침해 경로는 폴리마켓의 코어 시스템이 아니라 웹 프론트엔드에 통합된 제3자 JavaScript 자원이었다. 공격자는 해당 벤더의 빌드 또는 배포 파이프라인 권한을 확보한 뒤 정상 스크립트 내부에 악성 코드를 삽입했고, 사용자의 브라우저가 폴리마켓 도메인에 접속하는 순간 자동으로 악성 로직이 실행되도록 구성한 것으로 파악된다.
| 구분 | 내용 |
|---|---|
| 피해 플랫폼 | Polymarket (예측 시장) |
| 보도 시점 | 2026-06-26 18:04:12 UTC |
| 추정 피해 규모 | 약 300만 달러 |
| 공격 벡터 | 제3자 벤더 침해를 통한 프론트엔드 스크립트 변조 |
| 플랫폼 대응 | 피해 고객 대상 전액 환불 공식 발표 |
| 주요 1차 출처 | Bleeping Computer |
즉 공격 표면은 폴리마켓이 통제할 수 있는 영역 바깥에 존재했고, 전통적인 내부 코드 감사와 스마트 계약 검토만으로는 이를 사전에 탐지하기 어려운 구조적 한계가 드러났다. 폴리마켓 측이 비교적 빠르게 손실을 인식하고 전액 환불이라는 사용자 보호 결정을 내린 점은 플랫폼 신뢰도 관리 측면에서는 긍정적인 사례로 평가되지만, 근본적인 차단 실패라는 사실 자체는 별개로 검토되어야 한다.
CSP 엄격화 및 SRI 기반 무결성 검증
가장 즉시 도입 가능한 1차 방어선은 콘텐츠 보안 정책(CSP)과 서브리소스 무결성(SRI)이다. CSP에서 script-src를 self와 검증된 도메인으로만 한정하고 nonce 또는 hash 기반 정책을 적용하면 변조된 외부 스크립트의 실행을 차단할 수 있다. SRI는 script 태그에 integrity 속성과 함께 해시 값을 선언해 빌드 산출물의 변조 여부를 브라우저 단에서 검증하도록 강제하는 방식으로, 이번 사건처럼 정상 스크립트가 악성 스크립트로 교체되는 시나리오에서 핵심적인 무결성 게이트 역할을 한다. 다만 SRI는 동적으로 변하는 스크립트에는 적용이 어렵기 때문에 정적 자원과 동적 자원의 분리가 선행되어야 효과적이다.
SBOM 도입과 벤더 보안 평가 절차 강화
단기 대응을 넘어선 중장기 과제는 소프트웨어 자재명세서(SBOM) 기반의 공급망 가시성 확보다. SBOM을 통해 프론트엔드에 로드되는 모든 제3자 컴포넌트의 버전과 출처, 라이선스, 알려진 취약점을 추적할 수 있으며, 이는 사고 발생 시 영향 범위 분석과 패치 우선순위 결정을 크게 단축시킨다. 여기에 신규 벤더 온보딩 시 보안 설문과 침투 테스트 보고서 검토, 그리고 분기 단위 재평가를 결합한 벤더 위험 평가 절차를 표준화하는 것이 필요해 보인다.
침해 경로 분석: 악성 스크립트가 어떻게 주입됐나
공급망 공격은 일반적으로 다음 네 단계 중 하나 이상의 경로로 발생한다. 첫째, 의존 라이브러리나 패키지의 공식 저장소 계정 탈취를 통한 정상 업데이트로 위장한 악성 코드 배포다. 둘째, 빌드 파이프라인 서버 침해를 통한 산출물 변조다. 셋째, CDN 또는 호스팅 계정의 권한 탈취를 통한 정적 자원 교체다. 넷째, 내부 개발자 PC의 멀웨어 감염을 통한 빌드 단계 코드 삽입이다. 폴리마켓 사건의 정확한 침투 경로가 아직 공개적으로 완전히 확인된 것은 아니지만, 외부 스크립트가 변조되어 그대로 사용자 브라우저에 전달되었다는 점에서 위 단계 중 빌드 파이프라인 또는 CDN 계정 침해 시나리오가 가장 유력한 것으로 보인다. 참고로 다른 캠페인에서는 초기 침투 후 정상적인 도메인을 악용해 악성 스크립트를 유포하는 사례도 보고된 바 있어(예: New SharkLoader Malware), 공격자들이 신뢰할 수 있는 인프라를 악용하려는 경향이 점점 확대되고 있음을 알 수 있다.
악성 스크립트가 사용자 측에서 수행할 수 있는 행동의 범위는 매우 넓다. 클립보드 모니터링을 통한 지갑 주소 교체, 가짜 트랜잭션 요청 생성, 세션 토큰 탈취, 그리고 사용자 서명 요청의 페이로드를 변조해 자금을 공격자 주소로 송금하도록 유도하는 행위까지 포함될 수 있다. 폴리마켓 사건의 정확한 페이로드 시퀀스는 추가 조사 결과가 나와야 확정할 수 있으나, 자금 탈취라는 최종 결과로 미루어 볼 때 사용자의 지갑 연결 또는 트랜잭션 서명 단계 중 하나가 변조된 것으로 판단된다.
웹3 서비스의 공급망 리스크가 커지는 이유
웹3 서비스는 전통적인 웹 서비스 대비 공급망 공격의 파급력이 훨씬 크다. 이유는 세 가지로 정리된다. 첫째, 트랜잭션의 비가역성이다. 블록체인에 서명되고 전송된 트랜잭션은 중앙 관리자의 개입 없이 되돌리기 어렵기 때문에, 일단 자금이 탈취되면 피해 회복이 플랫폼의 재원 부담으로 귀결된다. 둘째, 사용자 자가 보관 지갑과 서비스 커스터디 지갑이 혼재한다는 점이다. 서비스 측 세션이 변조되면 사용자는 정상 인터페이스로 오인한 상태에서 서명을 진행할 가능성이 높아진다. 셋째, 프론트엔드와 온체인 로직이 분리되어 있다는 점이다.어 사용자가 신뢰해야 할 신뢰 지점이 코드뿐 아니라 화면과 도메인까지 확장된다는 점이다.
이러한 구조적 특성 때문에 폴리마켓이 전액 환불을 발표했음에도 근본적인 위협은 해소되지 않은 것으로 평가된다. 환불은 이번 사건의 피해만을 메우는 일회성 조치이며, 동일하거나 유사한 침투 시나리오가 재현될 경우 또다시 유사한 규모의 손실이 발생할 가능성은 여전히 존재한다.
실무 보안 권고 사항
- 즉시 적용 가능한 1차 통제: CSP nonce/hash 정책 적용, script-src 화이트리스트 운영, SRI integrity 속성을 통한 외부 스크립트 해시 검증, 변조 감지 시 즉시 차단하는 fail-closed 정책 설계.
- 공급망 가시성 확보: 프론트엔드 포함 모든 빌드 산출물에 대한 SBOM 생성 및 주기적 갱신, 신규 및 기존 서드파티 벤더 대상 보안 평가 절차 표준화, 의존성 업데이트 시 자동 취약점 스캔 파이프라인 운영.
- 권한 및 빌드 환경 강화: 빌드 파이프라인 서버의 다 요소 인증과 최소 권한 원칙 적용, 배포 키의 하드웨어 보안 모듈 보관, 배포 산출물에 대한 외부 서명 및 감사 로그 도입.
- 런타임 모니터링과 이상 트랜잭션 탐지 체계: 사용자 행동 패턴 및 트랜잭션 패턴을 실시간으로 분석해 비정상 서명 요청, 평소와 다른 지갑 주소, 짧은 시간 내 다수의 출금 시도를 탐지하는 체계 구축.
- 사고 대응 준비: 프론트엔드 무결성 침해 전담 플레이북 작성, 영향 범위 산정 및 사용자 통보 절차 사전 정의, 온체인 자금 동결 및 추적을 위한 분석사 사전 협업 체계 마련.
런타임 모니터링과 이상 트랜잭션 탐지 체계
사전 예방이 실패했을 때 피해 확산을 최소화하는 마지막 방어선은 런타임 모니터링이다. 클라이언트 단에서는 정상 도메인에서 로드된 스크립트의 무결성을 주기적으로 재검증하고, 예상치 못한 script 태그 주입을 감지하면 즉시 사용자 세션을 중단시키는 안전 모드로 전환해야 한다. 서버 단에서는 사용자별 트랜잭션 빈도, 평균 금액, 수신 지갑 주소의 신규 여부, IP 및 디바이스 핑거프린트 변화 등을 결합한 이상 점수 모델을 운용해 자동 차단 및 추가 인증을 트리거하는 것이 권고된다. 이러한 다층 방어 체계는 단일 통제의 실패를 다른 계층이 보완하는 구조를 제공하며, 공급망 공격의 불확실성이 높은 환경에서 운영 회복력을 크게 향상시키는 것으로 분석된다.
Bleeping Computer 원문 기사 바로가기 및 The Hacker News 관련 참고 사례를 함께 검토하면, 신뢰할 수 있는 인프라를 악용해 초기 침투를 시도하는 공격 트렌드의 실제 사례를 확인할 수 있다.
정리 포인트
- 이번 폴리마켓 사건의 핵심은 공격 표면이 플랫폼 자체가 아닌 제3자 벤더였다는 점이며, 이것이 전통적인 코드 감사의 사각지대를 드러냈다.
- 즉시 도입 가능한 통제는 CSP 엄격화와 SRI 기반 무결성 검증이며, 중장기적으로는 SBOM과 벤더 보안 평가 절차의 표준화가 필요하다.
- 웹3 환경의 트랜잭션 비가역성, 지갑 연결 구조, 신뢰 지점 확대로 인해 공급망 공격의 파급력이 일반 웹 서비스보다 크다.
- 전액 환불 발표는 사용자 신뢰 보호 측면에서는 긍정적이나, 근본 위협이 해소된 것은 아니므로 런타임 모니터링과 사고 대응 체계 강화가 병행되어야 한다.