[라온 보안동향보고서] 2026년 6월 주요 보안 이슈

1. 악성코드 현황

1.1. 악성코드 동향

2026년 5월, Google Android 운영체제의 핵심 디버깅 구성요소에 심각한 인증 우회 취약점이 확인되었습니다. CVE-2026-0073은 Android Debug Bridge 데몬(adbd)의 무선 인증서 검증 함수에 존재하는 인증서 검증 로직 오류로, 인접 네트워크에 위치한 공격자가 사용자 조작 없이 원격 shell 권한을 획득하는 제로클릭 공격을 가능하게 합니다. CVSS 3.1 기준 8.8점(High), Google Android 자체 분류 기준 Critical로 분류된 이 취약점은 Android 14부터 Android 16까지 영향을 미칩니다.

취약점의 핵심 원인은 OpenSSL의 `EVP_PKEY_cmp()` API가 반환하는 다중 정수값을 단순 boolean 조건문으로 처리하는 구현 오류에 있습니다. 이는 CWE-303(인증 알고리즘의 잘못된 구현)에 해당하며, 암호화 라이브러리 반환값을 엄밀하게 검증하지 않을 때 인증 로직 전체가 무력화될 수 있음을 보여줍니다. 유사 사례로는 CVE-2020-16088(OpenIKED 인증 우회)이 있으며, 인증·암호화 처리 구간에서는 라이브러리 함수의 반환값을 명확히 검증해야 합니다.

adbd는 Android 기기의 개발자 디버깅을 지원하는 시스템 서비스로, 무선 ADB 연결 시 TLS 기반 상호 인증을 통해 허가된 호스트만 접근을 허용합니다. 그러나 CVE-2026-0073이 악용되면 이 인증 절차가 완전히 우회되어 공격자가 shell 사용자(uid=2000) 권한으로 기기에 원격 접속할 수 있습니다. 무선 디버깅 기능은 Android 개발자 옵션에 포함된 기능으로, 활성화된 경우 TCP 5555 포트와 mDNS를 통해 서비스가 네트워크에 노출됩니다.

공격자가 이 취약점을 악용하려면 세 가지 조건이 필요합니다. 피해 기기에서 무선 디버깅이 활성화되어 있어야 하고, 기존에 등록된 RSA ADB 호스트 키가 한 개 이상 존재해야 하며, 공격자가 동일 Wi-Fi 또는 인접 네트워크에 위치해야 합니다. 이 조건들이 충족되면 공격자는 별도의 사전 인증이나 권한 없이 즉시 인증을 우회할 수 있습니다.

Google은 2026년 5월 Android 보안 공지를 통해 이 취약점을 공개하고, 2026-05-01 보안 패치 레벨 이상으로 업데이트 시 수정됨을 안내했습니다. 공개 시점 기준으로 실제 공격에 악용된 사례는 확인되지 않았으나, 제로클릭 방식의 원격 접근이 가능하다는 점에서 개발자 기기 및 기업 테스트 환경에 대한 신속한 패치 적용이 권고됩니다. 수정 패치는 Project Mainline 구성 요소로 포함되어 Google Play 시스템 업데이트를 통해서도 배포됩니다.

1. 취약점 요약 표

2. 기술적 분석

(1) 취약점 상세

CVE-2026-0073은 Android System 컴포넌트의 adbd 내 `auth.cpp` 파일에 위치한 `adbd_tls_verify_cert` 함수에서 발견된 인증서 검증 로직 오류입니다. 이 함수는 무선 ADB 연결 시 TLS 핸드셰이크 과정에서 클라이언트가 제출한 인증서를 검증하며, OpenSSL의 `EVP_PKEY_cmp()` API를 호출해 인증서 공개 키와 기기에 등록된 ADB 호스트 키를 비교합니다.

`EVP_PKEY_cmp()` 함수의 반환값 의미는 다음과 같이 정의됩니다.

- 1: 두 키가 완전히 일치

- 0: 두 키가 불일치

- -1: 키 타입이 서로 다름

- -2: 해당 키 타입에서 지원하지 않는 연산

올바른 인증 구현에서는 `EVP_PKEY_cmp()`의 반환값이 성공을 의미하는 1인 경우에만 인증을 허용해야 합니다. 그러나 취약한 구현에서는 반환값을 세부적으로 구분하지 않고, 성공 여부를 단순 조건으로만 판단했습니다. C/C++에서는 0이 아닌 정수값이 모두 참(true)으로 평가되기 때문에, 오류를 의미하는 -1 또는 -2도 조건식을 통과할 수 있습니다. 이로 인해 공격자가 기기에 등록된 RSA 키와 다른 알고리즘의 인증서(EC P-256, Ed25519 등)를 제출할 경우, 키 비교 과정에서 오류가 발생하더라도 인증이 성공한 것으로 처리될 수 있습니다. AOSP 패치에서는 `EVP_PKEY_cmp()`의 반환값이 1인지 명시적으로 확인하도록 인증 로직을 보완했습니다.

(2) 공격 메커니즘

CVE-2026-0073을 악용한 공격은 다음 세 단계로 진행됩니다.

1단계 — 취약 기기 탐지: 공격자는 동일 네트워크에서 무선 ADB가 활성화된 기기를 탐색합니다. 무선 ADB는 기본적으로 TCP 5555 포트를 사용하며, mDNS를 통해 `_adb-tls-connect._tcp` 서비스 정보가 로컬 네트워크에서 발견될 수 있습니다. 따라서 네트워크 포트 스캔이나 mDNS 질의를 통해 공격 대상 기기를 식별할 수 있습니다.

2단계 — 알고리즘 불일치 인증서 제출: 공격자는 피해 기기에 등록된 RSA 키와 알고리즘 타입이 다른 EC P-256 인증서를 생성하여 ADB TLS 핸드셰이크 과정에서 제출합니다. `adbd_tls_verify_cert` 함수는 `EVP_PKEY_cmp()`를 호출해 등록된 키와 제출된 인증서의 키를 비교합니다. 두 키의 알고리즘 타입이 다르면 `EVP_PKEY_cmp()`는 오류(타입 불일치)를 의미하는 -1을 반환합니다.

3단계 — 인증 우회 및 shell 세션 확립: `EVP_PKEY_cmp()`의 반환값을 성공 값인 1과 명시적으로 비교하지 않고, 단순 조건식으로 처리합니다. C/C++에서는 0이 아닌 정수값이 모두 참(true)으로 평가되기 때문에, 오류 값인 -1도 인증 성공으로 잘못 처리될 수 있습니다. 그 결과 공격자는 shell 사용자 (uid=2000, SELinux 컨텍스트 `u:r:shell:s0`) 권한으로 ADB 세션을 확립할 수 있습니다. 이 과정은 사용자 조작이나 추가 승인 없이 진행될 수 있어 제로클릭 공격으로 이어질 수 있습니다.

(3) 영향 분석

CVE-2026-0073 악용에 성공한 공격자는 shell(uid=2000) 권한을 획득하며, 이를 통해 다음과 같은 작업을 수행할 수 있습니다.

- 시스템 속성 조회 및 설치 앱 목록 확인

- 시스템 로그 및 디버그 로그 접근

- `pm`(패키지 관리자), `am`(액티비티 관리자), `cmd` 등 shell 유틸리티 실행

- 디버그 가능(debuggable) 앱의 데이터 파일 접근

단, shell 권한만으로는 root 권한 또는 커널 실행 권한이 자동 부여되지 않으며, TEE(신뢰 실행 환경) 등 하드웨어 보호 영역에도 접근이 불가합니다. root 수준의 권한을 획득하거나 기기 전체를 제어하기 위해서는 이 취약점 악용 이후 별도의 로컬 권한 상승 공격이 추가로 필요합니다.

영향 대상은 Android 14, 15, 16, 16-QPR2 베타 버전 전체이며, 2026-05-01 이전 보안 패치 레벨이 적용된 기기 중 무선 디버깅을 활성화한 경우에 한정됩니다. 기업 내 Android 앱 개발팀, 모바일 QA 팀, 기기 테스트 환경이 주요 위험 대상에 해당합니다.

3. 공격 시나리오

시나리오 1: 공용 Wi-Fi 환경에서의 개발자 기기 침해

Android 앱 개발자가 카페나 공항 등 공용 Wi-Fi에서 무선 디버깅을 활성화한 채 기기를 사용 중입니다. 동일 네트워크에 접속한 공격자는 mDNS 스캔으로 해당 기기의 ADB 포트(TCP 5555)를 발견합니다. 공격자는 EC P-256 인증서를 생성하여 ADB TLS 연결을 시도하고, 취약한 `adbd_tls_verify_cert` 함수가 -1 반환값을 참으로 처리해 인증을 허용합니다. 개발자의 개입 없이 shell 권한이 부여된 공격자는 기기에 설치된 앱 목록, 개발 중인 앱의 디버그 로그, 테스트 계정 인증정보가 포함된 로그 파일 등에 접근합니다.

시나리오 2: 기업 내부망 테스트 기기 다수 접근

모바일 QA 팀이 사내 Wi-Fi에 다수의 Android 테스트 기기를 연결하고 편의를 위해 무선 디버깅을 상시 활성화해 사용합니다. 내부 네트워크에 접근한 공격자는 네트워크 스캔으로 취약 기기 전체 목록을 파악하고, 각 기기에 순차적으로 ADB 인증 우회를 시도해 복수 기기에 shell 접근을 확보합니다. 이후 `pm install` 명령을 이용해 악성 앱을 설치하거나, 테스트 환경에 저장된 API 키·토큰·인증서 등 민감 정보를 수집하는 추가 공격을 수행합니다.

시나리오 3: 공용 Wi-Fi 환경에서의 표적 공격

공용 Wi-Fi 환경에서는 공격자가 특정 개발자 또는 보안 연구자와 동일한 네트워크에 접속할 수 있습니다. 공격자는 무선 ADB가 활성화된 대상 기기를 탐지한 뒤, 인증 우회를 통해 shell 권한을 획득할 수 있습니다. 이후 `am start` 명령으로 특정 앱을 원격 실행하거나, 설치된 앱의 추가 취약점을 확인해 권한 상승 등 후속 공격의 발판으로 활용할 수 있습니다.

4. 대응 방안

(1) 즉각 조치

보안 패치 즉시 적용: 모든 Android 14~16 기기를 2026-05-01 보안 패치 레벨 이상으로 업데이트합니다. 기기의 설정 → 소프트웨어 업데이트에서 최신 패치 적용 여부를 확인합니다. Project Mainline 구성 요소로서 Google Play 시스템 업데이트를 통해서도 패치가 배포되므로, Play 스토어의 시스템 앱 업데이트도 함께 확인합니다.

무선 디버깅 즉시 비활성화: 개발 작업이 진행 중이 아닐 때는 설정 → 개발자 옵션 → 무선 디버깅을 비활성화합니다. 패치 적용 전까지 공용 Wi-Fi 또는 신뢰하기 어려운 네트워크 환경에서의 무선 디버깅 사용을 전면 중단합니다.

등록된 ADB 기기 점검 및 정리: 설정 → 개발자 옵션 → 무선 디버깅 → 등록된 기기 목록에서 인식하지 못하는 호스트 키를 즉시 제거합니다. 의심스러운 항목이 있는 경우 전체 등록 목록을 초기화합니다.

(2) 장기 대응

기업 MDM 정책 강화: 기업 환경의 Android 기기에 MDM(모바일 기기 관리) 정책을 적용해 개발자 옵션 및 무선 디버깅 활성화를 통제합니다. 보안 패치 적용 현황을 주기적으로 점검하고 패치되지 않은 기기의 네트워크 접근을 제한합니다.

개발 환경 네트워크 분리: Android 개발 및 테스트 기기 전용 격리 네트워크(VLAN)를 구성해 동일 네트워크 또는 주변 네트워크에서 발생할 수 있는 공격 노출 범위를 최소화합니다. 공개 Wi-Fi와 사내 개발 환경 네트워크 간의 완전한 분리를 유지합니다.

암호화 API 반환값 처리 코드 리뷰: 자체 개발 소프트웨어에서 `EVP_PKEY_cmp()` 등 다중 정수 반환값을 사용하는 암호화 비교 API 호출 코드를 점검합니다. 단순 boolean 조건(`if (result)`)으로 처리하는 패턴을 `if (result == 1)`과 같은 명시적 비교로 수정합니다. 이 패턴은 OpenSSL 외에도 다양한 암호화 라이브러리에서 동일하게 발생할 수 있습니다.

보안 업데이트 자동 적용 활성화: 업무용 Android 기기의 시스템 업데이트 자동 적용을 활성화해 신규 취약점 패치가 즉시 배포되도록 합니다. 제조사 사용자 정의(OEM 커스텀 ROM)가 적용된 기기는 별도 업데이트 채널을 통해 패치 배포 일정을 확인합니다.

5. IOC (침해 지표)

현재 공개된 IOC 없음.

6. 탐지 규칙

현재 공개된 탐지 규칙 없음. 공식 보안 업데이트 적용을 권고합니다.

7. 참고 자료 URL 목록

- https://nvd.nist.gov/vuln/detail/CVE-2026-0073

- https://source.android.com/docs/security/bulletin/2026/2026-05-01

- https://cybersecuritynews.com/android-zero-click-vulnerability/

- https://www.penligent.ai/hackinglabs/cve-2026-0073-android-adbd-zero-click-shell-through-wireless-adb/

- https://securityaffairs.com/191710/breaking-news/critical-android-vulnerability-cve-2026-0073-fixed-by-google.html

- https://www.securityweek.com/critical-remote-code-execution-vulnerability-patched-in-android-2/

1.2. 악성코드 수집 현황

TouchEn mVaccine을 통해 최근 4개월간 수집된 악성코드 샘플 현황과 악성코드 데이터베이스 반영 결과를 정리하였습니다. 수집 건수는 해당 기간 동안 확보된 전체 샘플 수를 의미하며, 반영 건수는 이 중 분석 및 검토를 거쳐 악성코드 데이터베이스에 등록된 건수를 의미합니다.

최근 4개월간 월별 수집 건수는 2월 2,350건, 3월 2,378건, 4월 2,563건, 5월 2,489건으로 집계되었습니다. 4월에 최고치인 2,563건을 기록한 이후 5월에는 2,489건으로 전월 대비 2.9% 감소하였으나, 2월·3월 수준보다는 여전히 높은 수치를 나타내었습니다. 반영 건수는 2월 1,038건, 3월 1,206건, 4월 1,094건, 5월 1,226건으로, 5월이 최근 4개월 중 최고치를 기록하였으며 전월 대비 12.1% 증가하였습니다. 수집 건수는 전월 대비 감소하였음에도 반영 건수가 오히려 늘어나, 5월에 처리·등재된 악성코드 샘플의 비중이 높아진 양상을 보였습니다.

5월 유형별 반영 현황은 Trojan 666건(54.3%), Riskware 356건(29.0%), Generic 66건(5.4%), Adware 56건(4.6%), Linux 42건(3.4%), Etc 40건(3.3%) 순으로 나타났습니다. 전월 대비 변화를 보면, Trojan이 528건에서 666건으로 26.1% 증가하였고, Generic은 42건에서 66건으로 57.1%, Adware는 38건에서 56건으로 47.4% 급증하였습니다. 반면 4월에 8건 탐지되었던 VoicePhishing은 5월에 집계되지 않았고, Riskware도 394건에서 356건으로 9.6% 감소하였습니다.

5월 주차별 수집 현황은 1주차 626건, 2주차 595건, 3주차 652건, 4주차 616건으로 집계되었습니다. 3주차에 652건으로 월중 최고치를 기록하였으나, 최솟값(2주차 595건)과 최댓값(3주차 652건)의 차이가 57건에 그쳐 월 전반에 걸쳐 비교적 균등한 수집 분포를 나타내었습니다.

1.3. 악성코드 유형별 비율 및 전월 비교

2026년 5월 악성코드 반영 건수는 1,226건으로, 전월(4월) 1,094건 대비 132건(+12.1%) 증가하였습니다. 반면 수집 건수는 2,489건으로 전월 2,563건 대비 74건(-2.9%) 소폭 감소하였습니다. 수집 건수는 줄었지만 반영 건수가 증가한 점을 고려하면, 5월에는 수집 샘플 중 악성코드 데이터베이스에 반영된 비율이 전월보다 높아진 것으로 볼 수 있습니다. 최근 4개월 반영 건수 추이는 2월 1,038건, 3월 1,206건, 4월 1,094건, 5월 1,226건으로, 3월의 고점 이후 4월에 일시 감소하였다가 5월에 다시 증가세로 전환하였습니다.

월별 유형별 반영 현황은 아래 표와 같습니다.

Generic 급증(+57.1%) — 신변종 유입 확대

Generic 유형은 4월 42건(3.8%)에서 5월 66건(5.4%)으로 24건 증가하여 57.1%의 가장 높은 증가율을 기록하였습니다. Generic은 기존에 알려진 특정 악성코드 패밀리로 분류되지 않고 범용 탐지 시그니처나 휴리스틱 규칙에 의해 식별된 샘플군입니다. 이 수치의 급증은 기존 탐지 패턴을 우회하기 위해 코드 구조나 실행 방식을 변형한 신종 또는 변종 악성코드의 유입이 증가한 결과입니다. 특정 패밀리로 규정하기 어려운 샘플의 비중이 늘어날수록 시그니처 기반 탐지만으로는 방어에 한계가 발생하므로, 행위 기반 탐지 역량 강화와 지속적인 룰 업데이트가 중요합니다.

Adware 급증(+47.4%) — 광고성 악성코드 4개월 연속 확산

Adware는 4월 38건(3.5%)에서 5월 56건(4.6%)으로 18건 증가하며 47.4%의 증가율을 기록하였습니다. 최근 4개월 추이를 보면 2월 4건(0.4%), 3월 16건(1.3%), 4월 38건(3.5%), 5월 56건(4.6%)으로 4개월 연속 증가하고 있으며, 절대 건수 기준으로 매달 증가 폭이 확대되고 있습니다. Adware는 사용자 동의 없이 광고를 삽입·표시하거나 클릭을 유도하는 악성 소프트웨어로, 불법 앱 마켓이나 리패키징된 애플리케이션, 서드파티 APK 배포 경로를 통해 확산됩니다. 4개월 연속으로 증가 폭이 커지고 있다는 점은 광고 수익 기반의 악성코드 배포 생태계가 점차 규모를 키우고 있음을 보여줍니다.

VoicePhishing 0건 — 신규 탐지 없음

보이스피싱 관련 악성코드는 3월 6건, 4월 8건이 탐지되었으나, 5월에는 관련 샘플이 확인되지 않았습니다. 다만 보이스피싱 악성코드는 금융 정보 탈취, 통화 가로채기, 원격 제어 기능과 결합될 경우 피해 규모가 커질 수 있는 유형입니다. 5월 탐지 건수가 0건으로 감소했더라도 단기간의 수집 결과만으로 위협이 사라졌다고 판단하기는 어렵습니다. 향후 유포 방식이나 변종 변화에 따라 다시 탐지될 가능성이 있으므로 지속적인 모니터링이 필요합니다.

Trojan 반등(+26.1%) — 최다 탐지 유형 유지

Trojan은 5월 666건(54.3%)으로 전월 528건(48.3%) 대비 138건 증가하였습니다. 최근 4개월간 Trojan 비율은 2월 59.2%, 3월 63.3%, 4월 48.3%, 5월 54.3%로, 4월에 일시 하락하였다가 5월에 다시 반등하였습니다. Trojan은 정보 탈취, 원격 접속, 백도어 설치 등 복합적 기능을 수행하는 다목적 악성코드로, 건수와 비율 모두에서 타 유형을 크게 앞서며 가장 많이 확인된 유형으로 유지되고 있습니다.

기타 유형 동향

Riskware는 5월 356건(29.0%)으로 전월 394건(36.0%) 대비 38건(-9.6%) 감소하였으나, 여전히 전체의 약 29%를 차지하며 Trojan 다음으로 높은 비중을 유지하고 있습니다. Riskware는 악성코드로 분류되지는 않으나 정보 유출, 시스템 변조 등 잠재적 보안 위협 요소를 내포한 소프트웨어군으로, 꾸준히 높은 비중을 보이는 만큼 지속적인 주의가 필요합니다. Linux 악성코드는 42건(3.4%)으로 전월 38건 대비 4건(+10.5%) 소폭 증가하였으며, Etc 유형은 46건에서 40건으로 6건(-13.0%) 감소하였습니다.

위협 트렌드 요약

- Generic·Adware 증가: Generic은 전월 대비 57.1%, Adware는 47.4% 증가하며 5월 반영 건수 증가에 영향을 주었습니다. Generic은 특정 유형으로 분류하기 어려운 신변종 샘플이 포함될 수 있고, Adware는 광고 노출이나 수익화 기능과 결합되는 경우가 많아 지속적인 추적이 필요합니다.

- Trojan 최다 반영 유형 유지: Trojan은 4월 48.3%에서 5월 54.3%로 증가하며, 최근 4개월간 전체 반영 건수의 절반 이상을 차지했습니다. 5월에도 가장 높은 비중을 보인 만큼 주요 악성코드 유형으로 계속 확인되고 있습니다.

- 보이스피싱 악성코드 5월 탐지 0건: 3~4월에 연속적으로 탐지된 보이스피싱 악성코드는 5월에 관련 샘플이 확인되지 않았습니다. 다만 금전 피해로 이어질 수 있는 유형인 만큼, 단기간의 감소만으로 위협이 해소되었다고 보기는 어렵습니다.

- 반영 건수 증가: 5월 수집 건수는 전월 대비 감소했으나, 악성코드 데이터베이스 반영 건수는 12.1% 증가했습니다. 이에 따라 수집 샘플 중 DB 반영 대상으로 판단된 비중이 전월보다 높아진 것으로 볼 수 있습니다.

2. 루팅 및 에뮬레이터, 원격 앱 탐지 현황

2.1. 루팅 탐지 현황(Emulator)

모바일 금융 서비스와 보안이 중요한 애플리케이션에서 루팅/탈옥 탐지는 필수적인 보안 요소입니다. 루팅된 기기는 시스템 보안 메커니즘을 우회할 수 있어, 악성코드 감염이나 데이터 탈취에 취약해집니다. 본 섹션에서는 2026년 5월 기준 루팅 및 에뮬레이터 탐지 현황과 최신 우회 기법 동향을 분석합니다.

2026년 5월 에뮬레이터별 루팅 탐지 유무 테스트를 진행한 결과는 다음과 같습니다.

2.2. 루팅 탐지 현황(Real Device)

2026년 5월 루팅 단말을 대상으로 자사 백신에서 루팅 탐지 테스트를 진행한 결과는 다음과 같습니다.

2.3. 에뮬레이터 탐지 현황

2026년 5월 에뮬레이터별로 자사 백신에서 에뮬레이터 탐지 테스트를 진행한 결과는 다음과 같습니다.

2.4. 원격 탐지 현황

2026년 5월 원격 기능을 제공하는 앱을 대상으로 자사 백신에서 원격제어 앱 감지 유무 테스트를 진행한 결과는 다음과 같습니다.

3. 국내외 보안 동향

3.1. 티빙(TVING) 회원 개인정보 약 1,953만 명 대규모 유출

1. 사건 개요

(1) 피해 대상 및 사고 유형:

CJ ENM이 운영하는 국내 OTT 서비스 티빙(TVING)에서 2026년 5월 30일 신원 미상의 해커가 회원 개인정보 데이터베이스에 직접 침입하여 약 1,953만 명분의 개인정보를 외부로 유출시킨 침해 사고가 발생했습니다. 단순한 계정 탈취나 피싱이 아닌, 서버 데이터베이스에 직접 침투하여 개인정보 파일 자체를 외부로 전송하는 방식의 공격이었습니다.

(2) 국내 역대 순위 및 서비스 특성:

피해 회원 수 기준으로 이번 사고는 국내 역대 4번째 규모의 개인정보 유출 사건에 해당합니다. 월정액 구독 기반의 OTT 서비스 특성상 실명 인증정보와 환불 계좌번호까지 등록된 회원이 다수이기 때문에, 유출된 정보를 활용한 2차 금융 피해 및 신원 도용 가능성이 높습니다.

2. 사건 경위

(1) 이상 징후 탐지에서 유출 확인까지:

2026년 5월 30일 오후 6시 1분, 티빙의 데이터베이스 서버 CPU 사용률이 100%에 도달하는 비정상적인 급등 현상이 최초 감지되었습니다. 이 시점에 공격자는 이미 대용량 개인정보 파일을 외부로 전송하는 작업을 진행 중이었습니다. 이상 징후 탐지로부터 약 21시간이 경과한 5월 31일 오후 3시 9분에 유출 사실이 공식 확인되었으며, 침해 인지 시점부터 정확히 23시간 59분이 경과한 2026년 6월 1일 오후 3시 8분에 한국인터넷진흥원(KISA)에 신고가 접수되었습니다.

(2) 공격자 침입 방식 및 사후 차단 조치:

공격자가 사용한 계정 및 인증정보 차단, AWS 액세스 키 폐기, GitHub 인증정보 교체 등의 조치가 이루어진 것으로 보도되었습니다. 이는 클라우드 인증정보나 개발 환경 접근 정보가 침해 과정에 악용되었을 가능성을 보여줍니다. 침해 사실이 확인되는 즉시 AWS 액세스 키를 폐기하고 GitHub 인증정보를 포함해 공격자가 사용한 계정 정보를 전면 교체하는 긴급 차단이 이루어졌으나, 이 시점에는 이미 데이터 외부 전송이 완료된 상태였습니다. 공격 경로의 정확한 진입 지점과 추가 피해 가능성에 대한 조사는 사고 이후에도 지속되고 있습니다.

3. 기술적 분석

(1) 데이터베이스 직접 침투와 탐지 지연의 구조적 문제:

이번 공격에서 처음 포착된 이상 신호는 CPU 사용률 급등이었습니다. 대용량 파일을 외부로 전송하는 과정에서 서버 자원이 집중 소모된 결과로, 이는 공격자가 이미 데이터베이스에 접근을 완료한 이후에야 탐지가 이루어졌음을 의미합니다. 침입 자체가 아닌 데이터 추출 단계에서 비로소 이상 징후가 나타난 점은, 데이터베이스 자체에 대한 비인가 접근을 조기에 탐지하는 체계가 부족했음을 보여줍니다. 실시간 쿼리 이상 탐지나 데이터 유출 방지(DLP) 솔루션을 적용했다면, 대용량 전송이 완료되기 전에 이상 행위를 더 빠르게 식별하는 데 도움이 되었을 것으로 보입니다.

(2) 클라우드 인증정보 관리의 취약점:

사후 조치로 AWS 액세스 키를 폐기했다는 점은 공격자가 클라우드 인증정보를 확보하여 데이터베이스에 접근했을 가능성을 보여줍니다. 클라우드 환경에서 액세스 키가 코드 저장소, 설정 파일, 환경 변수 등 보안상 부적절한 위치에 보관되거나, 과도한 권한을 가진 키가 장기간 교체 없이 사용될 경우 침해 경로로 악용될 수 있습니다.

(3) 암호화 적용 현황과 CI·DI 유출의 위험:

유출 데이터 중 비밀번호는 단방향 암호화, 휴대폰 번호 마지막 4자리·이메일 ID 부분·환불 계좌번호에는 암호화가 적용되어 있었습니다. 그러나 이름·생년월일·성별·CI(연계정보)·DI(중복가입확인정보)는 암호화가 적용되지 않은 상태였습니다. CI와 DI는 본인 인증 연계 식별자로서, 이 정보가 유출되면 단순 비밀번호 변경만으로는 방어가 불가능한 타 서비스 계정 연계 공격으로 이어질 수 있습니다.

4. 피해 현황

(1) 유출 확인 정보 항목:

이번 사고로 유출이 확인된 개인정보 항목은 아이디, 이름, 생년월일, 성별, CI, DI, 휴대폰 번호(마지막 4자리 암호화), 이메일(도메인을 제외한 ID 부분 암호화), 환불 계좌번호(암호화), 비밀번호(단방향 암호화) 등 10개 항목입니다. 유출 항목에는 개인 식별 정보와 계정 정보, 금융 관련 정보가 함께 포함되어 있어 추가 피해로 이어질 가능성이 있습니다.

(2) 예상 2차 피해 경로:

스미싱 및 보이스피싱 공격자는 이름·휴대폰 번호·생년월일 조합만으로도 대상을 특정해 신뢰도 높은 사칭 공격을 시도할 수 있습니다. 동일한 아이디와 비밀번호를 다른 서비스에서도 사용하는 회원은, 유출된 계정정보를 다른 사이트에 대입해 로그인을 시도하는 공격에 노출될 수 있습니다. CI·DI가 유출된 경우 금융·통신·공공 서비스의 본인 인증 절차와 연계된 공격에 악용될 가능성도 있어 단기간 내 2차 피해가 발생할 수 있습니다.

5. 대응 현황

(1) 초기 기술 대응:

침해 확인 직후 공격자가 사용한 AWS 액세스 키를 폐기하고 해당 계정 정보를 교체하여 추가적인 외부 접근 가능성을 차단했습니다. 침해 원인 규명 및 피해 범위 확정을 위한 상세 조사가 사고 이후에도 지속되고 있으며, 관련 보안 인프라 전반에 대한 재점검이 병행되고 있습니다.

(2) 이용자 고지 및 기관 신고:

2026년 6월 1일 KISA에 침해 사실을 신고하고, 6월 3일 공식 공지를 통해 피해 회원에게 유출 사실을 고지했습니다. 티빙은 비밀번호 변경을 강력히 권고하면서 동일한 계정 정보를 타 서비스에 사용하는 경우 해당 서비스의 비밀번호도 즉시 변경할 것을 당부했습니다.

6. 시사점

(1) 클라우드 인증정보 수명 주기 관리 체계 구축 필수:

이번 사고는 클라우드 환경에서 액세스 키 등 인증정보가 적절히 관리되지 않을 경우 천만 단위의 개인정보 유출 사고로 직결될 수 있음을 분명히 보여줍니다. 최소 권한 원칙에 따른 계정 권한 설계, 인증정보의 주기적 교체 자동화, 비인가 접근 실시간 알람 체계 구축이 클라우드 기반 서비스 운영의 기본 요건이 되어야 합니다.

(2) CI·DI 등 고위험 식별자의 저장 필요성 재검토:

대형 OTT 플랫폼이 본인 인증 연계에 필요한 CI·DI를 장기 보관하는 현행 구조는 침해 시 피해 범위를 크게 확장시킵니다. 서비스 제공에 필수적이지 않은 민감 식별자는 저장을 최소화하거나, 저장이 불가피한 경우 접근 권한을 최소화하고 별도의 분리된 저장소에 보관하는 방식으로 위험을 분산시켜야 합니다.

(3) 대규모 침해 사고에 대비한 이용자 선제 통보 체계 마련:

법적 신고 기한(72시간) 이행과 별도로, 수백만 명 이상의 이용자에게 영향을 미치는 대규모 침해 사고에서는 공식 조사가 진행 중이더라도 알려진 사실 범위 안에서 가능한 한 신속하게 이용자에게 통보하고 비밀번호 변경 등의 자체 보호 조치를 안내하는 선제적 고지 체계를 마련해야 합니다.

▶출처/참고자료:

- https://m.boannews.com/html/detail.html?idx=143935

- https://www.tving.com/help/notice/143752

- https://www.boho.or.kr/kr/bbs/view.do?searchCnd=&bbsId=B0000133&searchWrd=&menuNo=205020&pageIndex=1&categoryCode=&nttId=72078

- https://m.boannews.com/html/detail.html?idx=144054

- https://en.sedaily.com/finance/2026/06/03/tving-apologizes-after-personal-data-breach-exposes-user

3.2. Trellix 소스코드 저장소 무단 접근 사고

1. 사건 개요

(1) 피해 기업 및 사고 유형:

2026년 5월, 글로벌 보안업체 Trellix가 내부 소스코드 저장소 일부에 대한 무단 접근을 확인했습니다. Trellix는 McAfee Enterprise와 FireEye의 통합으로 출범한 보안 기업으로, 엔드포인트 보안, XDR, 이메일 보안, 위협 인텔리전스 등 다양한 보안 제품을 제공하고 있습니다. 이번 사고는 일반 고객 정보 유출보다는 보안 제품 개발 과정에 사용되는 소스코드 저장소가 외부에 노출된 사례라는 점에서 주목됩니다.

(2) 사고의 주요 특징:

Trellix는 공격자가 소스코드 저장소 일부에 접근한 사실을 확인했으나, 조사 시점 기준으로 소스코드 릴리스 또는 배포 과정이 영향을 받았거나, 접근된 소스코드가 실제 공격에 악용된 증거는 확인되지 않았다고 밝혔습니다. 다만 보안업체의 소스코드가 노출될 경우, 공격자가 제품 내부 동작 방식이나 탐지 로직을 분석해 향후 우회 기법 개발에 활용할 수 있어 장기적인 보안 위험으로 이어질 수 있습니다.

2. 사건 경위

(1) 무단 접근 확인 및 공식 발표:

Trellix는 2026년 5월 초 내부 소스코드 저장소 일부에 대한 무단 접근을 확인하고, 해당 사실을 공식 입장문을 통해 공개했습니다. 회사는 사고를 인지한 직후 외부 포렌식 전문가와 함께 조사에 착수했으며, 법 집행기관에도 관련 사실을 통보했다고 밝혔습니다.

(2) 공격자 주장 및 추가 확인 상황:

이후 RansomHouse 랜섬웨어 그룹이 2026년 5월 7일 자신들의 유출 사이트에 Trellix를 피해 기업으로 등재하고 공격 책임을 주장한 것으로 보도되었습니다. 다만 Trellix는 해당 주장과 실제 무단 접근 사고의 직접적인 연관성을 공식적으로 확인하지는 않았습니다. 또한 공격자가 어떤 방식으로 저장소에 접근했는지, 접근 기간이 얼마나 되었는지, 정확히 어떤 소스코드가 노출되었는지는 조사 중인 사항으로 남아 있습니다.

3. 기술적 분석

(1) 소스코드 저장소 접근 통제의 중요성:

소스코드 저장소는 제품의 기능 구현, 탐지 로직, 빌드 구성, 내부 개발 이력 등이 포함될 수 있는 핵심 개발 자산입니다. 일반적인 업무 문서나 고객 데이터와 달리, 소스코드는 공격자가 제품 구조와 보안 로직을 분석하는 데 활용될 수 있습니다. 특히 보안 제품의 경우 탐지 규칙, 예외 처리 방식, 내부 모듈 구성 등이 노출되면 향후 탐지 우회나 취약점 분석에 악용될 가능성이 있습니다.

(2) 보안업체 침해가 갖는 특수성:

보안업체는 고객사의 보안 운영에 직접 연결되는 제품과 서비스를 제공하기 때문에, 자체 개발 환경 침해가 일반 기업보다 더 큰 신뢰 문제로 이어질 수 있습니다. 이번 사고에서 현재까지 고객 환경이나 배포된 제품이 영향을 받았다는 증거는 확인되지 않았지만, 보안 제품 개발 코드가 외부에 노출되었다는 사실만으로도 고객사 입장에서는 제품 신뢰성과 공급망 보안 점검 필요성이 커질 수 있습니다.

(3) 릴리스·배포 과정 영향 여부의 중요성:

Trellix가 공식 입장에서 소스코드 릴리스 또는 배포 과정이 영향을 받지 않았다고 밝힌 점은 중요한 부분입니다. 소스코드 저장소 접근 사고가 실제 제품 배포 과정 침해로 이어질 경우, 정상 업데이트나 패치 파일에 악성 코드가 포함되는 공급망 공격으로 확대될 수 있기 때문입니다. 따라서 이번 사고의 핵심은 단순히 코드 접근 여부뿐 아니라, 제품 빌드·서명·배포 과정이 안전하게 유지되었는지 확인하는 데 있습니다.

4. 피해 현황

(1) 확인된 피해 범위:

공식 발표 기준으로 확인된 피해는 Trellix 내부 소스코드 저장소 일부에 대한 무단 접근입니다. Trellix는 조사 시점 기준으로 소스코드 릴리스 또는 배포 과정이 영향을 받았다는 증거, 접근된 소스코드가 악용되었다는 증거는 확인되지 않았다고 밝혔습니다. 또한 외부 보안 자문 자료에서는 이번 사고가 고객 환경이나 고객 데이터 침해로 이어졌다는 증거는 확인되지 않은 것으로 정리되었습니다.

(2) 잠재적 2차 위험:

소스코드가 외부에 노출될 경우 즉각적인 고객 피해가 없더라도 장기적인 위험이 남을 수 있습니다. 공격자는 노출된 코드를 분석해 제품의 탐지 방식, 예외 처리 조건, 내부 로직을 파악할 수 있으며, 이를 기반으로 탐지 회피 기법이나 새로운 공격 경로를 연구할 수 있습니다. 특히 보안 제품은 여러 고객사 환경에 설치되어 운영되기 때문에, 제품 내부 구조에 대한 정보가 공격자에게 축적될 경우 향후 표적 공격에 활용될 가능성이 있습니다.

5. 대응 현황

(1) Trellix의 공식 대응:

Trellix는 소스코드 저장소 일부에 대한 무단 접근을 확인한 뒤 외부 포렌식 전문가와 함께 조사에 착수했습니다. 또한 법 집행기관에 관련 사실을 통보했으며, 침해 원인과 접근 범위 확인을 위한 조사를 진행 중이라고 밝혔습니다. Trellix는 현재까지의 조사에서 소스코드 릴리스 또는 배포 과정이 영향을 받았거나, 접근된 소스코드가 실제 공격에 악용된 정황은 확인되지 않았다고 밝혔습니다.

(2) 후속 정보 공개 및 고객 영향 확인:

Trellix는 조사가 완료되는 대로 필요한 추가 정보를 공유하겠다고 밝혔습니다. 현재까지 공개된 공식 입장에서는 고객 데이터 유출, 배포 제품 변조, 보상 계획 등에 대한 별도 발표는 확인되지 않았습니다. 다만 RansomHouse가 공격 책임을 주장한 것으로 보도되었으며, Trellix는 해당 주장에 대해 인지하고 조사 중인 것으로 알려졌습니다.

6. 시사점

(1) 보안업체도 예외가 아닌 공급망 위험:

이번 사고는 보안 제품을 제공하는 기업 역시 공급망 공격과 개발 환경 침해의 대상이 될 수 있음을 보여줍니다. 보안 솔루션은 고객사의 주요 시스템에 높은 권한으로 설치되는 경우가 많기 때문에, 제품 개발사 자체의 소스코드 관리와 배포 절차 보안은 고객사 보안 수준과도 직접 연결됩니다.

(2) 소스코드 저장소 접근 권한 관리 강화 필요:

기업은 소스코드 저장소 접근 권한을 최소화하고, 개발자·관리자 계정에 대한 다중 인증과 주기적인 권한 검토를 적용해야 합니다. 또한 비정상적인 저장소 접근, 대량 코드 다운로드, 외부 위치에서의 접근 시도 등을 탐지할 수 있도록 로그 모니터링 체계를 강화해야 합니다.

(3) 빌드·서명·배포 과정의 독립 검증 필요:

소스코드 저장소 침해가 실제 공급망 공격으로 이어지는 것을 막기 위해서는 코드 저장소 보안뿐 아니라 빌드, 서명, 배포 단계의 독립적인 검증이 필요합니다. 배포 파일의 무결성 검증, 코드 서명 키 보호, 배포 권한 분리, 빌드 환경 접근 로그 점검을 통해 개발 환경 침해가 고객사로 확산되는 것을 차단해야 합니다.

▶출처/참고자료:

- https://www.trellix.com/statement/

- https://www.bleepingcomputer.com/news/security/trellix-discloses-data-breach-after-source-code-repository-hack/

- https://thehackernews.com/2026/05/trellix-confirms-source-code-breach.html

- https://insights.integrity360.com/threat-advisories/security-advisory-unauthorised-access-to-trellix-internal-source-code

- https://csrc.nist.gov/pubs/sp/800/218/final

3.3. Foxconn 북미 공장 사이버 공격 — Nitrogen 그룹, 8TB 데이터 탈취 주장

1. 사건 개요

(1) 피해 기업 및 공격 주체:

세계 최대 전자기기 OEM 제조사인 Foxconn의 북미 공장이 Nitrogen 랜섬웨어 그룹의 사이버 공격을 받았으며, 공격자 측은 2026년 5월 11일 다크웹 유출 사이트에 Foxconn을 등재하면서 8TB 이상의 기업 데이터를 탈취했다고 주장했습니다. Foxconn은 Apple, Google, Dell, Nvidia, Intel, AMD 등 주요 글로벌 IT 기업의 핵심 위탁 제조 파트너로, 이번 침해가 납품처 기업의 기밀 자산에 미치는 파급 가능성이 있습니다.

(2) 다크웹 공개 및 공식 확인 경과:

Nitrogen 그룹은 2026년 5월 11일 자신의 다크웹 유출 사이트에 Foxconn을 피해자로 등재하며 공격 사실을 공개했습니다. Foxconn은 다음 날인 5월 12일 침해 사실을 공식 확인하고, 사이버보안팀을 통해 조사와 대응 조치에 착수했다고 밝혔습니다.

2. 사건 경위

(1) 공격 전개 및 데이터 탈취:

Nitrogen 랜섬웨어 그룹은 Foxconn 북미 공장 IT 시스템에 침투하여 8TB 이상, 1,100만 개 이상의 파일을 탈취했다고 주장하며 5월 11일 다크웹 유출 사이트에 Foxconn을 등재하고 탈취한 자료를 공개하겠다고 압박했습니다. 공격자 측은 탈취 파일에 Apple, Intel, Google, Dell, Nvidia, AMD와 관련된 기밀 지침서, 내부 프로젝트 문서, 기술 도면이 포함되어 있다고 주장했습니다.

(2) 생산 영향 및 즉각 대응:

Foxconn은 침해 이후 사이버보안팀이 조사와 대응 조치에 착수했으며, 생산 차질을 줄이기 위한 비상 운영 조치를 시행했다고 밝혔습니다. 침해가 발생한 공장은 이후 정상 생산 복귀 절차를 진행했으며, Foxconn은 고객사 납품에 차질이 발생하지 않도록 대응에 집중했습니다.

3. 기술적 분석

(1) Nitrogen 랜섬웨어의 계보와 특성:

Nitrogen 랜섬웨어는 과거 내부 분쟁으로 소스코드가 외부에 공개된 Conti 2 빌더를 기반으로 개발된 변종으로 알려져 있습니다. Conti 계열 빌더는 기업 환경 침투에 활용될 수 있는 기능을 포함하고 있으며, 코드 유출 이후 여러 공격 그룹이 이를 변형해 자체 랜섬웨어 공격에 사용해 왔습니다. Nitrogen 그룹 역시 이 코드를 기반으로 기업 데이터를 탈취한 뒤, 공개를 압박 수단으로 활용하는 조직으로 알려져 있습니다.

(2) OEM 제조사 공격의 특징:

Foxconn과 같은 대형 OEM 기업은 여러 빅테크 기업의 제품 생산과 관련된 문서와 기술 자료를 보유하고 있어 공격자에게 매력적인 표적이 될 수 있습니다. 특히 미출시 제품 도면이나 기술 문서가 포함될 경우, Foxconn뿐 아니라 고객사에도 부담이 커질 수 있습니다. 공격자는 Foxconn 단독 피해가 아니라 Apple·Nvidia 등 주요 고객사와 관련된 자료를 언급하며 압박 수위를 높인 것으로 보입니다.

(3) 제조 IT·OT 환경의 연계 위험:

전자기기 위탁 제조 공장은 기업 IT 시스템과 생산 설비 제어(OT) 환경이 혼재하는 구조입니다. Foxconn이 생산 차질을 줄이기 위한 조치를 별도로 언급한 것은 IT 침해가 생산라인에 영향을 미쳤거나 그 가능성에 선제 대응했음을 의미합니다. IT 침해가 OT 영역으로 전파될 경우, 납품 계약 위반 및 부품 공급망 차질이라는 물리적 피해로 연결됩니다.

4. 피해 현황

(1) 탈취 데이터 규모 및 민감도:

공격자는 8TB 이상, 1,100만 개 이상의 파일을 탈취했다고 주장하며, 내용으로 Apple·Intel·Google·Dell·Nvidia·AMD 등 주요 IT 기업 관련 기밀 지침서, 내부 프로젝트 문서, 기술 도면을 거론했습니다. 해당 주장의 전부 또는 일부가 사실일 경우, 관련 기업들의 미출시 제품 설계 정보 및 핵심 기술 자산이 외부에 노출된 것입니다.

(2) 공급망 파급 가능성:

탈취된 기술 도면과 프로젝트 문서가 경쟁사나 국가 지원 위협 행위자에게 전달될 경우, 역설계 및 기술 탈취로 이어질 수 있습니다. Foxconn을 공통 공급자로 사용하는 기업들은 자사가 직접 침해받지 않았더라도 공급망 경유 기밀 유출 위험에 노출된 상태입니다.

5. 대응 현황

(1) Foxconn의 공식 대응:

Foxconn은 침해 인지 즉시 사이버보안팀을 통해 조사와 대응 조치에 착수하고, 생산 및 납품 차질을 줄이기 위한 비상 운영 조치를 시행했다고 공식 발표했습니다. 침해가 발생한 공장은 정상 생산 복귀 절차를 진행 중이며, 침해 원인과 피해 범위에 대한 조사가 이루어지고 있습니다.

(2) 관련 기업 조치:

탈취 파일에 언급된 Apple·Nvidia·Dell·Intel 등 해당 IT 기업들은 자사 기밀 정보의 포함 여부를 자체적으로 확인하는 작업에 착수한 것으로 알려졌습니다. 공급망 침해 사고의 특성상, 직접 피해 기업 외에도 연관 기업들이 자사 데이터 자산에 대한 피해 현황을 독립적으로 파악해야 합니다.

6. 시사점

(1) 주요 제조 협력사 침해에 따른 공급망 피해 가능성:

Foxconn과 같은 대형 제조사는 여러 고객사의 제품 생산과 관련된 기밀 자료를 함께 보유하고 있습니다. 이 때문에 한 제조사가 침해되더라도 여러 고객사의 기술 자료와 사업 정보가 동시에 노출될 수 있습니다. 고객사 입장에서는 주요 제조 협력사의 보안 수준을 계약 조건에 포함하고, 정기적으로 점검하는 관리 체계가 필요합니다.

(2) 제조업 분야 사이버보안 투자 확대 필요:

제조업은 금융·IT 업종에 비해 사이버보안 투자와 전문 인력이 부족한 경우가 많아 랜섬웨어 공격의 주요 표적이 되고 있습니다. 특히 여러 고객사의 생산 정보와 기술 자료를 다루는 대형 제조사는 그에 맞는 보안 인프라와 전문 인력을 갖추어야 합니다.

(3) IT 침해가 생산 시스템으로 확대되지 않도록 IT·OT 망 분리 강화:

제조 환경에서는 사무용 IT 시스템 침해가 생산 설비나 공장 운영 시스템으로 확산되지 않도록 차단하는 것이 중요합니다. 이를 위해 IT와 OT 네트워크를 물리적 또는 논리적으로 분리하고, 생산 시스템 접근 권한을 별도로 관리해야 합니다. 또한 사이버 사고 발생 시 생산 차질을 줄일 수 있도록 비상 대응 절차를 정기적으로 점검해야 합니다.

▶출처/참고자료:

- https://www.honhai.com/en-us/about/group-profile

- https://www.theregister.com/cyber-crime/2026/05/12/foxconn-confirms-cyberattack-after-nitrogen-claims-apple-nvidia-data-theft/5239144

- https://www.halcyon.ai/ransomware-alerts/nitrogen-ransomware-on-a-manufacturer-attack-spree

- https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final

- https://www.cisa.gov/resources-tools/resources/foundations-ot-cybersecurity-asset-inventory-guidance-owners-and-operators

- https://www.bleepingcomputer.com/news/security/electronics-giant-foxconn-confirms-cyberattack-on-north-american-factories/

3.4. TanStack npm 공급망 자동 확산형 악성 패키지 공격 — CI/CD 파이프라인 탈취로 170개 패키지 감염

1. 사건 개요

(1) 공격 방식과 주요 특징:

2026년 5월 11일, TeamPCP 위협 그룹은 오픈소스 자바스크립트 생태계에서 널리 사용되는 TanStack 라이브러리의 공식 릴리스 과정을 악용해 악성 패키지를 배포했습니다. 이 공격은 npm 계정 탈취 없이도 유효한 SLSA(Supply-chain Levels for Software Artifacts) 보안 서명이 포함된 악성 패키지를 공식 배포 경로를 통해 유포했다는 점에서 주목됩니다. 또한 악성 패키지가 다른 패키지로 연쇄 확산될 수 있는 구조를 갖추고 있어, npm 생태계에서 확인된 자동 확산형 악성 패키지 사례로 평가됩니다.

(2) CVE 지정 및 영향 규모:

이번 공격에 사용된 취약점은 CVE-2026-45321(CVSS 9.6 Critical)로 지정되었습니다. @tanstack 네임스페이스 42개 패키지(84개 악성 버전)에서 시작된 감염이 Mistral AI, UiPath, OpenSearch를 포함한 170개 이상의 npm·PyPI 패키지로 전파되었으며, @tanstack/react-router 단일 패키지의 주간 다운로드 수만 약 1,200만 건에 달합니다.

2. 사건 경위

(1) 릴리스 자동화 과정 장악 및 악성 버전 배포:

TeamPCP 그룹은 2026년 5월 11일 GitHub Actions의 `pull_request_target` 이벤트 취약점 악용, 캐시 포이즈닝, OIDC 토큰 메모리 추출을 연계해 TanStack의 공식 릴리스 자동화 과정을 장악했습니다. 공격자는 TanStack의 신뢰된 OIDC 식별 정보(ID)를 이용해 악성 코드가 포함된 패키지를 npm 공식 패키지 저장소에 배포했습니다.

(2) 의존 프로젝트를 통한 확산:

악성 버전 패키지는 TanStack을 의존성으로 채택하고 있는 다른 오픈소스 및 상용 프로젝트의 빌드 과정에서 자동으로 설치·실행되며 여러 프로젝트로 확산되었습니다. 이 과정에서 Mistral AI, UiPath, OpenSearch를 포함한 170개 이상의 npm 및 PyPI 패키지에 악성 버전이 포함된 것으로 알려졌습니다. TanStack은 5월 12일 사고 분석 글을 공개하고, 문제가 된 악성 버전을 패키지 저장소에서 일괄 삭제했습니다.

3. 기술적 분석

(1) 3단계 연계 공격 기법의 구조:

이번 공격은 GitHub에서 코드 검토와 배포가 자동으로 이루어지는 과정을 악용해 진행되었습니다. 첫 번째 단계에서는 외부 기여자가 올린 코드 변경 요청이 높은 권한으로 실행되도록 GitHub Actions 설정을 악용했습니다. 이로 인해 일반적으로 접근할 수 없어야 하는 저장소 내부 인증정보에 접근할 수 있는 환경이 만들어졌습니다.

두 번째 단계에서는 캐시 포이즈닝 기법이 사용되었습니다. 캐시는 빌드 속도를 높이기 위해 이전 작업 결과나 임시 파일을 다시 사용하는 기능인데, 공격자는 이 캐시에 악성 코드를 섞어 넣어 이후 빌드 과정에서 해당 코드가 실행되도록 만들었습니다.

세 번째 단계에서는 자동 배포 과정에서 사용되는 임시 인증값인 OIDC 토큰을 빌드 환경에서 추출했습니다. 이 토큰은 TanStack이 공식적으로 패키지를 배포할 때 사용하는 신뢰 정보로 활용되기 때문에, 공격자는 npm 계정 비밀번호나 배포 토큰을 직접 탈취하지 않고도 악성 패키지를 공식 배포 경로에 올릴 수 있었습니다.

(2) 보안 서명만으로는 악성 여부 판단이 어려운 문제:

이번 공격에서는 악성 패키지에도 정상적인 SLSA 보안 서명이 포함되었습니다. SLSA는 소프트웨어가 어떤 빌드 과정을 거쳐 만들어졌는지 확인하기 위한 보안 체계입니다. 일반적으로 SLSA 서명이 있으면 해당 패키지가 공식적인 빌드 절차를 거친 것으로 판단할 수 있습니다.

그러나 공격자가 배포 절차 자체를 장악한 경우에는 악성 패키지에도 정상 서명이 붙을 수 있습니다. 이 경우 사용자는 서명 검증만으로 패키지가 안전한지 판단하기 어렵습니다. 이번 사례는 보안 서명이 패키지의 출처를 확인하는 데는 도움이 되지만, 패키지 내부 코드가 실제로 안전한지까지 보장하지는 못한다는 점을 보여줍니다.

(3) 대응 조치를 악용한 자동 삭제 기능:

악성 코드에는 특정 조건이 발생하면 자동으로 동작하는 삭제 기능이 포함되어 있었습니다. 이른바 데드맨 스위치라고 부르는 방식으로, 보안팀이 탈취된 OIDC 토큰을 폐기하면 피해 개발자의 홈 디렉토리 파일을 삭제하도록 설계되어 있었습니다.

이는 정상적인 사고 대응 조치가 오히려 추가 피해로 이어지도록 만든 방식입니다. 일반적으로 침해가 확인되면 탈취된 인증값을 폐기하는 것이 기본 대응 절차이지만, 이번 악성 코드는 그 조치가 실행되는 순간 파일 삭제가 발생하도록 만들어 대응을 어렵게 했습니다.

(4) 클라우드 및 개발 환경 인증정보 수집 기능:

악성 패키지에는 AWS, GCP, Kubernetes, GitHub 등 클라우드 서비스와 개발·배포 환경에서 사용하는 인증정보를 수집하는 기능이 포함되어 있었습니다. 이 기능은 개발자 PC나 회사의 자동 빌드·배포 환경에서 실행될 경우, 저장된 토큰과 접근 키 등을 외부로 전송할 수 있도록 설계되었습니다.

4. 피해 현황

(1) 악성 버전이 배포된 패키지 범위:

@tanstack 네임스페이스의 42개 패키지에서 84개 악성 버전이 생성·배포되었습니다. 이후 의존성 연쇄를 통해 Mistral AI, UiPath, OpenSearch를 포함한 170개 이상의 npm·PyPI 패키지로 확산된 것으로 집계되었습니다. 다만 보안업체(Wiz) 분석에 따르면 @uipath·@mistralai 등 일부 패키지의 악성 코드는 버그로 인해 실제로는 정상 동작하지 않은 것으로 확인되어, 실제 피해 범위는 패키지 수보다 작을 수 있습니다. @tanstack/react-router 단일 패키지의 주간 다운로드 수가 약 1,200만 건이라는 점을 고려하면, 악성 버전이 배포된 기간 동안 설치된 사례는 상당했을 가능성이 있습니다.

(2) 클라우드·개발 환경으로의 피해 확대 가능성:

악성 버전이 개발자 PC에서 실행된 경우 개인 또는 개발용 클라우드 인증정보가 노출될 수 있습니다. 회사의 빌드·배포 환경에서 실행된 경우에는 조직의 클라우드 인프라 접근 권한까지 공격자에게 넘어갈 수 있어, 단순 패키지 감염을 넘어 내부 시스템 접근이나 추가 공급망 공격으로 이어질 가능성이 있습니다.

5. 대응 현황

(1) TanStack의 즉각 대응:

TanStack은 2026년 5월 12일 사고 원인과 대응 내용을 정리한 공개 설명 자료를 게시하고, 악성 버전을 npm 패키지 저장소에서 일괄 제거했습니다. GitHub Actions 워크플로를 수정하여 `pull_request_target` 이벤트 관련 권한을 재조정하고, 침해된 OIDC 토큰을 폐기했습니다. 특정 대응 조치 실행 시 자동 삭제 기능으로 인한 추가 피해를 방지하기 위해 토큰 폐기 절차와 함께 영향받은 환경에 대한 사전 격리 조치가 병행되었습니다.

(2) 보안 커뮤니티 권고 사항:

보안 커뮤니티는 영향받은 패키지를 의존성으로 사용하는 모든 프로젝트에 대해 패키지 버전 고정(lockfile 강제 사용), 감염된 버전이 실행된 CI/CD 환경의 모든 클라우드 인증정보 즉시 교체, GitHub Actions 워크플로 권한 설정 전수 점검, npm 신뢰 게시자(Trusted Publisher) 설정 검토를 권고했습니다.

6. 시사점

(1) CI/CD 파이프라인이 공급망 공격의 핵심 표적으로 부상:

이번 사고는 소스 코드나 패키지 저장소 자체가 아닌, 자동화된 빌드·배포 파이프라인이 공급망 공격의 핵심 진입점이 되고 있음을 명확히 보여줍니다. GitHub Actions 워크플로 권한 설정과 이벤트 트리거 구성이 보안 관리의 중요 관리 대상으로 다루어져야 하며, 과도한 권한을 가진 워크플로에 대한 정기 감사가 요구됩니다.

(2) 코드 서명과 SLSA만으로는 공급망 보안 보장 불충분:

유효한 SLSA 서명이 첨부된 악성 패키지가 배포된 이번 사례는, 서명 기반 무결성 검증이 파이프라인 탈취 공격에 대한 완전한 방어책이 될 수 없음을 입증합니다. 패키지 도입 시 서명 검증에만 의존하지 않고, 소프트웨어 구성 분석(SCA) 도구를 통한 의존성 취약점 점검, 런타임 행위 모니터링, 패키지 버전 고정 정책을 병행하는 다층 방어가 필요합니다.

(3) 개발자 로컬 환경과 자동 빌드·배포(CI/CD) 환경 인증정보의 분리 관리:

이번 악성 코드에는 특정 대응 조치가 실행되면 개발자 PC의 파일을 자동으로 삭제하는 기능이 포함되어 있었습니다. 이는 개발자 개인 작업 환경도 조직 전체 보안에 영향을 줄 수 있음을 보여줍니다. 따라서 개발자 환경에도 최소 권한 원칙을 적용하고, 자동 빌드·배포 환경에서 사용하는 클라우드 인증정보는 개발자 PC와 분리해 관리해야 합니다. 이를 통해 개별 개발 환경이 침해되더라도 조직의 클라우드 인프라 전체로 피해가 확대되는 것을 줄일 수 있습니다.

▶출처/참고자료:

- https://tanstack.com/blog/npm-supply-chain-compromise-postmortem

- https://www.stepsecurity.io/blog/mini-shai-hulud-is-back-a-self-spreading-supply-chain-attack-hits-the-npm-ecosystem

- https://snyk.io/blog/tanstack-npm-packages-compromised/

- https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target

- https://slsa.dev/spec/v1.2/build-requirements

- https://cheatsheetseries.owasp.org/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.html

- https://w