wfx-loot은 탈취한 GitHub 계정으로 저장소를 탐색하고, 쓰기 권한이 있는 곳에는 CI(지속적 통합) 환경의 비밀정보를 훔치는 코드를 심은 캠페인입니다. Aikido는 계정 4,837개가 저장소 61,764곳에 탐색용 풀 리퀘스트를 보냈으며, 공개 집계 기준 최소 1,835곳에서 페이로드가 실행돼 인증정보가 유출됐다고 밝혔습니다.
4
9
언제 발생했고, 얼마나 이어졌나
활동은 2026년 11월 10일 12시 45분(UTC) 무렵 시작됐습니다. 한 보고서는 탐색용 풀 리퀘스트가 **11월 11일 15시(UTC)**까지 이어졌다고 기록했습니다. 관측된 탐색 구간은 약 26시간 15분입니다.
6
7 다만 이는 탐색 활동이 관측된 기간이지, 이후 페이로드 실행이나 탈취한 인증정보의 사용까지 모두 끝났다는 뜻은 아닙니다.
캠페인 규모를 나타내는 수치는 서로 다른 단계를 가리킵니다.
- 계정 4,837개가 침해된 것으로 보고됐습니다.
- 저장소 61,764곳이 탐색용 풀 리퀘스트를 받았습니다. 이 수치는 공격자가 접근을 시험한 저장소 수이지, 악성코드가 실행된 저장소 수가 아닙니다.
- Aikido가 공개한 집계에서는 최소 1,835곳에서 페이로드 실행과 인증정보 유출이 확인됐습니다.
9
일부 당시 보도는 더 낮은 수치인 1,806곳을 인용했습니다.
6
10 제공된 보도만으로는 두 수치의 차이를 설명하기 어려우므로, 하나로 합치기보다 각각 별도로 발표된 집계로 보는 편이 정확합니다. 6만 6,000곳이 넘는 대상 가운데 약 1,970건이 공개적으로 확인됐다는 후속 주장도 제공된 자료로는 뒷받침되지 않습니다.
공격자는 어떻게 접근을 확인했나
공격자는 wfx-docs라는 브랜치에서 docs: dependency audit notes라는 제목의 풀 리퀘스트를 열었습니다. 이는 탈취한 계정으로 해당 저장소에 변경 사항을 쓸 수 있는지 확인하기 위한 탐색 단계였습니다.
3
4
9
쓰기 권한이 확인된 경우에는 CI 환경에서 비밀정보를 훔치는 페이로드를 넣었습니다. 공격의 핵심은 GitHub Actions의 취약점이 아니라 유효한 도용 계정 정보였습니다.
4
9 OX Security는 악성코드가 약 1,500줄 분량의 단일 셸 스크립트였다고 설명했습니다.
31
일부 사례에서는 악성 변경 사항과 워크플로 실행 기록이 삭제돼 사후 조사가 어려워졌다는 보도가 나왔습니다.
1
6 다만 확인된 자료가 뒷받침하는 것은 탐색, 페이로드 실행, 흔적 삭제라는 전반적인 패턴입니다. 보도된 모든 배포 방식이나 커밋 메시지가 모든 감염 사례에서 사용됐다고 단정할 수는 없습니다.
무엇을 노렸나
확인된 공격 목표는 CI 작업이 접근할 수 있는 인증정보였습니다. 여기에는 GitHub Actions 시크릿과 클라우드 인증정보가 포함되며, AI 서비스 토큰을 노린 시도도 보도됐습니다.
3
9 OX Security의 분석에는 AWS, Azure, Google Cloud 인증정보가 표적 목록에 포함돼 있습니다.
31 별도 보도는 악성코드가 러너 프로세스 메모리에서 시크릿을 찾으려 했다고 전했지만, 제공된 자료만으로는 그 방법이 얼마나 자주 성공했는지 알 수 없습니다.
17
29
수집된 요약 자료는 AWS 신뢰 정책을 바꾸고 Azure 페더레이션 자격 증명을 추가해 접근을 이어가려는 시도가 있었다고 전합니다.
5 이는 보고된 공격 방식이지, 모든 피해 저장소나 클라우드 계정이 실제로 변경됐다는 증거는 아닙니다. 확인된 증거의 중심은 인증정보 탈취이며, 소스 코드나 고객 데이터베이스를 훔쳤다는 사실까지 입증된 것은 아닙니다.
9
15
탐지 관련 수치, 어떻게 읽어야 하나
한 보도에 따르면 협력자 또는 조직 권한으로 제출된 탐색용 풀 리퀘스트 **10,431건 가운데 92%**가 확인 당시에도 열린 상태였습니다.
10
19 이는 상당수 요청이 아직 처리되지 않았음을 시사하지만, 저장소 소유자나 보안팀이 공격을 알아채지 못했다는 뜻은 아닙니다. 이 비율을 전체 풀 리퀘스트에 적용해서도 안 됩니다.
조사 플레이북은 Fly.io GitHub App을 통한 사용자 토큰을 사용해 19개 계정이 탐색용 풀 리퀘스트 173건을 보냈다고 기록했습니다. 이 사실만으로 Fly.io 인프라가 침해됐거나, 해당 토큰이 닿은 모든 저장소에서 페이로드가 실행됐다고 볼 수는 없습니다.
37
대응할 때 확인할 사항
조직이 영향을 받았을 가능성이 있다면 사고 조사에서 탐색, 페이로드 삽입, 페이로드 실행, 인증정보 유출을 구분해야 합니다. 서로 같은 의미가 아닙니다.
- 탐색 흔적을 찾으세요. 계정이 쓸 수 있는 저장소에서
docs: dependency audit notes 제목의 풀 리퀘스트와 wfx-docs 브랜치를 확인합니다.
9
- CI와 감사 기록을 살펴보세요. 워크플로 실행, 커밋, 브랜치 활동과 클라우드 로그를 검토합니다. 보고된 실행 기록 삭제를 고려하면 워크플로 실행 번호가 비는 구간은 조사 단서가 될 수 있지만, 공백만으로 침해가 입증되지는 않습니다.
1
24
- 영향받은 접근 권한을 폐기하세요. 침해가 의심되는 GitHub 토큰을 폐기하고 계정, 협력자, GitHub App의 접근 권한을 점검합니다.
- 노출 가능성이 있는 시크릿을 폭넓게 교체하세요. 페이로드가 실행됐다면, 남아 있는 로그에 보이는 정보뿐 아니라 해당 워크플로가 접근할 수 있었던 시크릿과 클라우드 역할도 침해됐을 가능성을 고려해야 합니다.
3
9
- 클라우드에 남은 접근 경로를 확인하세요. 예상하지 못한 AWS 신뢰 정책 변경, Azure 애플리케이션 또는 페더레이션 자격 증명 변경, 승인되지 않은 키나 기타 권한 변경을 조사합니다.
5
- 증거를 보존하세요. 정리 작업에 앞서 남아 있는 감사 기록과 로그를 저장하고, 어떤 공격 단계가 증거로 확인됐는지 기록합니다.