TanStack, Nx Console, GitHub로 이어진 침해 연쇄 (2026년 5월): 개발자가 확인할 것

영향받은 패키지는 @tanstack/react-router, @tanstack/react-start, @tanstack/router-core, @tanstack/history 등 Router/Start 패키지 42개, 84개 버전입니다(전체 목록은 GitHub 권고 GHSA-g7cv-rxg3-hmpx). TanStack은 Query, Table, Form, Virtual 등 다른 패키지는 영향을 받지 않았다고 밝혔습니다. lockfile의 현재 내용만이 아니라 2026년 5월 11일 전후의 변경 이력도 확인하세요. 악성 버전은 몇 시간 안에 npm에서 제거됐기 때문에, 그 사이의 설치가 지금의 lockfile에는 남아 있지 않을 수 있습니다. CI에서는 5월 11일 19:20(UTC) 이후 설치를 실행한 잡을 찾아보세요.

Nx의 사후 보고서는 code --list-extensions --show-versions로 설치된 버전을 확인하는 방법을 안내합니다(확장 ID에 angular-console이 포함됨). 영향받은 것은 v18.95.0뿐이며, 5월 18일 12:30부터 13:09(UTC) 사이에 배포됐습니다. Nx는 이 시간대에 자동 업데이트를 켠 상태로 Nx Console을 쓰던 사람은, 설치 수치가 결국 어느 쪽으로 확정되든 그 기기를 침해된 것으로 취급하라고 요청합니다. 사후 보고서에는 찾아볼 파일과 프로세스(침해 지표)도 나와 있으니, 영향이 있다면 그 목록을 따라 확인하세요.

TanStack과 Nx는 같은 대상을 듭니다. GitHub 토큰, npm 토큰, SSH 키, 클라우드 인증 정보(AWS, GCP, Azure), Kubernetes, Vault 토큰, 그리고 .env 파일의 내용입니다. Nx는 기기의 도구가 그 시간대에 발급받았을 수 있는 인증 정보(임시 클라우드 인증 정보, GitHub CLI 토큰 등)도 추가하고, 교체 후 기기를 완전히 다시 구축하는 것도 검토하라고 권합니다. 폐기 순서와 상주형 악성 코드 대응은 npm 공급망 웜 방어의 "감염이 의심될 때" 부분을 참고하세요.

TanStack에 따르면 이 코드는 피해자가 관리하는 다른 패키지를 찾아 같은 코드를 심어 다시 배포하려고 했습니다. npm에 패키지를 배포하고 있다면 5월 11일 이후 패키지의 버전 이력에 내가 배포하지 않은 버전이 없는지 확인하세요.

Nx에 따르면 탈취된 인증 정보는 GitHub CLI 토큰이었습니다. 그 환경에서는 디스크의 파일에 저장돼 있어 사용자 권한으로 실행되는 모든 프로세스가 읽을 수 있었고, 74초 안에 GitHub API에 쓰였습니다. gh auth status로 내 토큰이 어디에 저장돼 있는지 확인하고, 평문 파일에 있다면 OS 키체인이나 실행 시에만 인증 정보를 넣어 주는 비밀번호 관리자 연동으로 옮기는 것을 검토하세요. Nx는 사고 후 개발자 기기에서 GitHub CLI를 직접 쓰는 것을 정책으로 금지했습니다. 토큰의 유효 기간과 범위를 좁히는 방법은 npm 공급망 웜 방어를 참고하세요.

Nx에 따르면 침해된 기여자의 프로젝트는 .npmrc에 minimum-release-age=10080(7일)을 설정해 두었지만, 프로젝트가 고정한 pnpm 10.14는 이 설정을 지원하지 않아 조용히 무시했습니다. 지원은 pnpm 10.16부터입니다. 악성 버전은 설치 시점에 공개된 지 77분밖에 안 됐으므로, 설정이 동작했다면 막혔을 것입니다. package.json의 packageManager 필드에 고정된 버전을 확인하고, 충분히 새 버전인지 CI에서 검증하게 하세요. npm에서 같은 역할을 하는 설정은 npm 공급망 웜 방어에서 다룹니다.

5월 26일 GitHub는 GitHub Enterprise Server 업데이트 패키지에 서명하는 키를 포함해 키를 교체하고 있다고 발표했습니다. 관리자는 인스턴스의 GPG 공개 키를 교체해야 하며, 그렇지 않으면 앞으로의 업그레이드가 올바른 GHES 패키지가 아니라는 오류로 실패합니다. 절차와 보조 스크립트의 SHA256 다이제스트는 GitHub의 게시물에 있습니다. GitHub는 GHES 업데이트를 공식 경로에서만 내려받고, 앞으로 몇 달 동안 보안 업데이트가 평소보다 잦을 것에 대비하라고도 요청합니다. GitHub Enterprise Cloud 고객은 별도 조치가 필요 없습니다.

TanStack에 따르면 번들 크기를 재는 워크플로가 pull_request_target으로 실행됐고, 그 안에서 포크 풀 리퀘스트의 코드를 체크아웃해 빌드했습니다. pull_request_target은 기본 저장소의 권한으로 실행되며, TanStack은 첫 기여자에 대한 승인 관문이 이 트리거에는 적용되지 않는다고 지적합니다. 라벨 붙이기나 댓글 달기처럼 외부 코드를 실행하지 않는 작업에만 쓰세요. TanStack은 사고 후 CI에서 pull_request_target 사용을 모두 없앴습니다.

TanStack에 따르면 GitHub Actions 캐시는 저장소 단위로 공유되며, pull_request_target 실행과 main으로의 push가 같은 범위를 씁니다. 워크플로의 permissions:를 읽기 전용으로 해도 캐시 저장은 막히지 않습니다. 그 결과 릴리스 워크플로가 외부 코드를 실행한 잡이 쓴 캐시를 복원했습니다. TanStack은 사고 후 릴리스 파이프라인의 패키지 캐시를 끄고 모든 캐시를 삭제했습니다. 배포하는 워크플로에서는 캐시를 복원하지 않는 것이 가장 단순한 경계선입니다.

TanStack의 릴리스 워크플로는 npm 신뢰 게시(OIDC)를 위해 id-token: write를 갖고 있었습니다. 사후 보고서에 따르면 악성 배포는 워크플로에 정의된 배포 단계에서 나온 것이 아니라, 같은 실행의 다른 단계에서 돌던 코드가 토큰을 꺼내 직접 배포한 것이었습니다. TanStack 자신의 교훈은 신뢰 게시 연결에는 배포마다의 검토가 없다는 것입니다. 배포를 빌드·테스트와 분리된 별도 잡으로 나누고, 그 잡에만 권한을 주고, 필수 검토자(required reviewers)를 지정한 GitHub 환경(environment) 뒤에 두세요. Nx는 사고 후 실행한 사람과 다른 사람의 승인을 배포의 필수 조건으로 만들었습니다.

사고 후 TanStack과 Nx는 모두 액션 참조를 태그나 브랜치가 아니라 커밋 SHA로 고정했습니다. TanStack은 바뀔 수 있는 참조를 "이번 사고와 무관하게 늘 존재하는 공급망 위험"이라고 표현합니다.

Nx는 확장 마켓플레이스가 업로드 때마다 보내는 일상적인 알림 메일로 변조된 릴리스를 발견했습니다. 릴리스를 예상하지 않던 메인테이너가 이상을 알아차리고 약 11분 만에 게시를 내렸습니다. 두 번째 배포 경로에는 그런 알림이 없었고, 제거까지 약 36분이 걸렸습니다. 한편 탈취된 토큰으로 한 활동(워크플로 실행 기록 삭제 등)은 감사 로그에 남아 있었지만 1주일 동안 아무도 알아차리지 못했습니다. 배포 알림이 팀의 누군가에게 도착하는지, 워크플로 실행 기록 삭제를 감사 로그에서 누군가 보고 있는지 확인하세요.