블로그로 돌아가기
[TUTORIAL]

AI 코딩 에이전트 0-click 취약점 Plugin4Shell, 내 환경 점검 6단계

퀀텀점프클럽 정상록퀀텀점프클럽 정상록14분 읽기2 views
#Plugin4Shell#AI 코딩 에이전트 보안#AI 에이전트 플러그인 마켓플레이스#제로클릭 RCE#Claude Code 취약점

무료 자료

PDF · 무료

내 AI 코딩 도구, 지금 안전한가요 — 비개발자를 위한 쉬운 가이드

긴 글을 다 읽기 전에, 실무 가이드부터 먼저 챙겨가세요.

AI 코딩 에이전트 0-click 취약점 Plugin4Shell, 내 환경 점검 6단계

Claude Code·Codex·Copilot·Gemini CLI 플러그인 설치 로직에 커밋 검증 누락 결함이 있었습니다. 원리와 패치 상태, 내 환경 점검법을 6단계로 정리했습니다.

결론부터 말씀드리면, 이 취약점 때문에 오늘 당장 AI 코딩 에이전트 사용을 멈출 필요는 없습니다. 다만 어떤 마켓플레이스를 쓰고 있는지에 따라 위험도는 꽤 크게 갈립니다. AI 코딩 에이전트를 매일 쓰는 분이라면 이런 생각이 드실 겁니다. "그럼 나도 지금 뚫려 있는 상태인가요?" 헤드라인만 보면 4대 코딩 에이전트가 전부 해킹당할 수 있다는 얘기처럼 들리니 당연한 걱정입니다. 이 글에서는 Plugin4Shell이라는 이 취약점이 정확히 무엇을 노리는지, 어디까지가 사실이고 어디부터가 과장인지, 그리고 5분 안에 내 환경을 스스로 점검하는 방법까지 순서대로 짚어보겠습니다.

Plugin4Shell, 무슨 일이 있었던 걸까요

2026-09-17, 보안 스타트업 AIR Security(연구자 Or Nevo, Dor Granat, Niv Hoffman)가 자사 블로그에 새로운 취약점 하나를 공개했습니다. 이름은 Plugin4Shell. 대상은 지금 가장 널리 쓰이는 AI 코딩 에이전트 4종, Claude Code·OpenAI Codex·GitHub Copilot·Gemini CLI였습니다.

Plugin4Shell이란? AI 코딩 에이전트의 플러그인 마켓플레이스가 특정 커밋(코드의 한 시점)을 핀으로 고정해 설치하면서도, 설치 후 실제로 그 커밋이 맞는지 검증하지 않아 발생하는 결함입니다. 저장소 소유자가 조건을 맞추면 검증된 버전 대신 다른 코드가 조용히 실행될 수 있습니다.

다음 날인 2026-09-18에는 The Hacker News가 로컬 환경에서 이 동작을 직접 재현하며 독립 검증에 나섰고, Help Net Security·SecurityWeek 같은 보안 전문 매체도 잇달아 다뤘습니다. AI 코딩 에이전트 보안 이슈치고는 이례적으로 짧은 시간에 여러 매체가 몰린 사례입니다.

공격 경로는 프롬프트 인젝션이 아니라 "체크아웃 검증 누락"

이 부분이 가장 많이 오해되는 지점입니다. AI 코딩 에이전트 관련 사고라고 하면 흔히 프롬프트 인젝션(악성 텍스트로 AI를 속이는 공격)이나 MCP(에이전트가 외부 도구와 연결되는 표준 방식) 서버 경유 공격을 떠올리기 쉽습니다. Plugin4Shell은 둘 다 아닙니다.

실제 원인은 훨씬 평범합니다. 플러그인 마켓플레이스의 git checkout 검증 누락입니다. 에이전트가 플러그인을 설치할 때 마켓플레이스는 특정 커밋 SHA(코드 상태를 가리키는 40자리 고유값)를 핀으로 고정해 둡니다. 문제는 그 커밋을 checkout(내려받아 실제 파일로 반영)한 뒤, 작업 트리에 정말 그 커밋이 놓였는지를 확인하지 않는다는 점이었습니다.

OpenAI가 이 결함을 수정하며 커밋 메시지에 남긴 설명이 원리를 가장 정확히 짚습니다.

"Git can interpret a requested commit SHA as a branch name when the remote's default branch has the same name. This can cause a marketplace plugin source to materialize a different commit than the one it pinned." (요청한 커밋 SHA를 git이 브랜치 이름으로 해석할 수 있습니다. 원격 저장소의 기본 브랜치가 같은 이름일 때 그렇습니다. 이 경우 마켓플레이스 플러그인 소스가 핀으로 지정한 커밋과 다른 커밋을 실체화하게 됩니다.)

저장소 소유자가 40자리 SHA와 똑같은 이름의 브랜치를 만들어 그것을 기본 브랜치로 지정해 두면, git은 커밋 대신 그 브랜치를 우선 해석해 버립니다. 검증 절차 자체가 없었으니 이 차이를 잡아낼 방법이 없었습니다.

진짜 위험해지는 조건은 따로 있습니다

여기부터가 실무 판단에서 가장 중요한 부분입니다. 취약점이 "존재한다"는 것과 "내 환경이 실제로 노출된다"는 것은 다른 얘기니까요. 변종은 두 가지고, 각각 성립 조건이 명확합니다.

변종 A: Claude Code·Codex·Copilot (브랜치명 충돌)

이 조건이 두 개 모두 맞아야 공격이 성립합니다.

  • 코드 호스트가 40자리 16진수 브랜치 이름을 허용해야 합니다. GitHub는 이런 이름을 애초에 거부합니다. 반면 Bitbucket과 자체 호스팅 git 서버는 허용합니다.
  • 그 브랜치가 저장소의 기본 브랜치여야 합니다. 기본 브랜치가 아니면 checkout은 정상적으로 커밋으로 해석됩니다.

두 조건이 다 맞아떨어지는 경우만 실제 위험입니다. GitHub 저장소만 쓴다면 첫 번째 조건에서 이미 막힙니다.

변종 B: Gemini CLI (FETCH_HEAD 충돌)

Gemini CLI는 조금 다른 방식으로 뚫립니다. --ref로 핀을 지정하고 shallow clone 후 fetch, 그다음 FETCH_HEAD(방금 받아온 커밋을 가리키는 임시 이름)를 checkout하는 3단계로 설치하는데, 저장소의 기본 브랜치 이름 자체가 FETCH_HEAD이면 checkout이 엉뚱한 브랜치를 해석해 버립니다. GitHub의 SHA 형태 이름 금지 규칙은 이 이름은 막지 않습니다. 그래서 Gemini CLI는 GitHub 저장소를 쓰더라도 안전하다고 단정할 수 없습니다.

0-click이 되는 진짜 이유는 자동 업데이트입니다

설치 시점에만 발동하는 버그였다면 사용자가 뭔가를 눌러야 하니 위험도는 낮았을 겁니다. 문제는 같은 checkout 로직이 백그라운드 플러그인 자동 업데이트에서 그대로 반복 실행된다는 점입니다. Claude Code와 Codex는 이게 기본 동작입니다. 마켓플레이스가 핀 SHA를 새 버전으로 올리는 순간, 이미 설치돼 있던 플러그인이 사용자 확인 없이 조용히 교체됩니다. 공격자가 새 플러그인을 설치시킬 필요조차 없습니다. 이미 정상적으로 쓰고 있던 플러그인이 그대로 표적이 됩니다.

제품별 패치 상태, 확실한 것과 애매한 것

제품상태확인 수준
Claude Code2.1.179(2026-06-16)에서 수정부분 확인. 릴리스 노트에 보안 언급 없음
OpenAI Codex0.146.0(2026-07-29)에서 수정확인. 커밋·PR·릴리스 전부 공개
GitHub Copilot클라이언트 패치 없음GitHub는 플랫폼 차원 완화가 있다는 입장
Gemini CLI영구 미패치확인. Google이 지원 종료 결정

Claude Code 쪽은 조금 조심스럽게 읽어야 합니다. 2.1.179 릴리스 노트 9개 항목 전부가 연결 끊김·스크롤·포커스 같은 버그 수정이고, 보안 수정이라는 문구는 어디에도 없습니다. AIR는 이 버전에서 수정을 확인했다고 밝혔지만, 그 근거는 현재로선 AIR의 주장 하나뿐입니다. 패치가 없었다는 뜻은 아니고, 벤더가 이걸 보안 수정으로 공표하지 않았다는 뜻입니다.

반대로 OpenAI 쪽은 근거가 단단합니다. 수정 커밋 690995b(2026-07-22 머지)가 codex-rs/core-plugins/src/loader.rs를 고쳤고, 회귀 테스트도 함께 추가됐습니다. checkout 이후 실제 HEAD를 resolve해서 요청한 SHA와 정확히 일치하지 않으면 그 소스를 거부하는 방식입니다.

과장과 사실을 구분해 보겠습니다

이 취약점을 다룬 기사들 중에는 "keys to the kingdom(왕국의 열쇠)"이라는 표현이 자주 등장합니다. 이건 실제 유출 사고가 있었다는 뜻이 아니라, 플러그인이 그것을 실행하는 사용자와 동일한 권한으로 동작한다는 권한 상속 구조를 가리키는 표현입니다. 실제로 확인된 사실과 아직 입증되지 않은 주장을 나눠 보면 이렇습니다.

입증된 것

  • git의 ref 우선 해석 동작 자체. The Hacker News가 직접 재현했습니다.
  • 수정이 필요한 실제 결함이었다는 점. OpenAI가 회귀 테스트까지 붙여 고쳤습니다.

입증되지 않았거나 명시적으로 부정된 것

  • 실제 악용 사례는 보고된 바 없습니다. AIR 스스로도 in-the-wild 증거가 없다고 밝혔습니다.
  • CVE 번호는 2026-09-18 기준 할당되지 않았고, 4개 벤더 모두 보안 권고문을 내지 않았습니다.
  • "수백만 대의 에이전트가 영향받는다"는 식의 큰 숫자는 발견 기업 자체의 추정치이며, 제3자가 검증한 값이 아닙니다.

여기서 짚고 넘어갈 게 하나 있습니다. 가장 상세한 기술 문서는 AIR Security의 자사 블로그인데, 같은 문서에 자사 제품("Air Marketplace와 Air Filter를 쓰는 기업은 영향받지 않았다") 홍보가 함께 실려 있습니다. CVE도 벤더 권고문도 없는 지금 단계에서는 심각도에 대한 서술이 상당 부분 발견 기업의 표현에 기대고 있다는 점을 감안하고 읽어야 합니다.

실제 노출 범위도 헤드라인보다 훨씬 좁습니다. GitHub는 애초에 SHA 형태의 브랜치명을 만들지 못하게 막아 두었고, The Hacker News가 2026-09-18에 확인한 바로는 Anthropic 커뮤니티 카탈로그와 Claude Code·Copilot 기본 카탈로그의 플러그인이 전부 GitHub 저장소를 가리켰습니다. 즉 기본 마켓플레이스만 쓰는 사용자라면 변종 A에는 애초에 노출되지 않습니다. 실질 위험은 Bitbucket, GitLab, 자체 호스팅 git을 백엔드로 쓰는 마켓플레이스에 몰려 있습니다.

흥미로운 대목은 개발자 커뮤니티의 반응입니다. Hacker News 스레드는 11 포인트, 댓글 3개에 그쳤고, 그중 한 댓글은 "패키지 매니저로서는 꽤 나쁜 버그지만, 하네스나 에이전트에서는 예상되는 수준"이라고 평했습니다. 심각하긴 해도 놀랍지는 않다는 업계 체감을 보여주는 반응입니다. 언론 보도량에 비해 개발자 커뮤니티의 확산은 크지 않았습니다.

지금 확인해야 할 6단계 점검법

여기서부터는 실행 단계입니다. 아래 명령은 2026-09-20 기준으로 로컬에서 직접 실행해 동작을 확인한 것들입니다.

1단계: 버전부터 확인하세요 (2분, 가장 중요)

claude --version     # 2.1.179 이상이면 패치됨
codex --version      # 0.146.0 이상이면 패치됨

2026-09-20 기준 최신 버전은 Claude Code 2.1.278(2026-09-19 릴리스), Codex 0.155.1(2026-09-18 릴리스)입니다. 자동 업데이트를 꺼두지 않았다면 이미 안전 버전 이상일 가능성이 높습니다.

2단계: 마켓플레이스 호스트를 확인하세요

claude plugin marketplace list    # 등록된 마켓플레이스 전체 목록
claude plugin list                # 설치된 플러그인 목록

여기가 위험도를 가르는 진짜 기준입니다. GitHub 호스팅 마켓플레이스만 있다면 브랜치명 변종에서는 상대적으로 안전합니다. Bitbucket·GitLab·자체 호스팅 git 주소가 섞여 있다면 우선 점검 대상으로 올려야 합니다. Gemini CLI를 쓰고 있다면 호스트와 무관하게 영구 미패치 상태이니 별도 판단이 필요합니다.

3단계: 자동 업데이트 설정을 점검하세요

0-click을 만드는 것은 백그라운드 자동 업데이트입니다. 마켓플레이스별로 끄려면 /plugin → Marketplaces → 대상 마켓플레이스 선택 → Disable auto-update 순서로 진행하면 됩니다. 전체를 끄려면 환경변수 DISABLE_AUTOUPDATER를 설정하고, 본체만 고정하고 플러그인은 계속 업데이트하려면 FORCE_AUTOUPDATE_PLUGINS=1을 함께 주면 됩니다.

여기서 놓치기 쉬운 함정이 하나 있습니다. plugin-name@marketplace-name 형태로 설치했다면, 자동 업데이트를 껐거나 DISABLE_AUTOUPDATER를 설정했더라도 Claude Code가 조회 전에 해당 마켓플레이스를 강제로 새로고침합니다(v2.1.232 이후 동작). 그러니까 자동 업데이트를 끄는 것만으로는 설치 경로가 완전히 차단되지 않습니다. 1단계의 버전 업데이트가 1차 방어이고, 자동 업데이트 해제는 어디까지나 보조 수단입니다.

4단계: 설치된 플러그인을 정리하세요

claude plugin list                  # 설치 목록 확인
claude plugin details <name>        # 개별 플러그인 구성요소 확인
claude plugin uninstall <name>      # 미사용 플러그인 제거
claude plugin prune                 # 더 이상 필요 없는 자동 설치 의존성 제거

자동 업데이트는 설치된 모든 플러그인을 대상으로 합니다. 안 쓰는 플러그인이 남아 있으면 그것도 그대로 공격 표면입니다. 업데이트가 이미 교체된 플러그인까지 되돌리는지는 어느 출처도 확인해 주지 않았습니다. 출처가 불분명한 플러그인이라면 제거 후 재설치하는 쪽이 안전합니다.

5단계: 제품별로 다르게 대응하세요

  • Gemini CLI 사용자: 패치가 나오지 않습니다. Google은 2026-06에 소비자용 Gemini CLI 제공을 중단했고, 2026-08-04에 미패치를 확정 통보했습니다. AIR에 따르면 Antigravity는 마켓플레이스 플러그인 SHA 피닝 구조 자체가 없어 이 공격이 닿지 않는다고 합니다.
  • GitHub Copilot 사용자: 클라이언트 패치가 없으니 GitHub 호스팅 마켓플레이스로 한정하고, 외부 호스팅 마켓플레이스 등록은 보류하는 게 좋습니다.
  • 조직·팀 단위: 사내에서 자체 git 서버나 Bitbucket에 플러그인 마켓플레이스를 운영 중이라면 이번 건의 직접 대상입니다. 에이전트 버전 하한선을 정책으로 강제하고, 마켓플레이스 백엔드에서 40자리 16진수 브랜치명과 FETCH_HEAD 브랜치명 생성을 막아야 합니다.

6단계: 구조적으로 재발을 막으세요

AIR가 제시하고 OpenAI가 실제로 구현한 검증은 한 줄로 요약됩니다. checkout 이후 작업 트리의 실제 커밋을 resolve해서 핀 SHA와 다르면 중단하는 것입니다.

test "$(git rev-parse HEAD)" = "<pinned-sha>" || abort

요청한 ref가 아니라 resolve된 HEAD를 봐야 한다는 점이 핵심입니다. Gemini CLI 변종이 빠져나가는 지점이 정확히 이 차이입니다. 사내에서 플러그인·의존성을 SHA로 고정해 배포하는 파이프라인을 직접 운영한다면, 같은 검증이 들어 있는지 확인해 볼 가치가 있습니다. 특정 제품 하나의 실수가 아니라 4개 팀이 똑같이 반복한 설계 착오였다는 점이 이 사례의 진짜 교훈입니다.

마무리

Plugin4Shell은 실제로 존재하는 결함이지만, 사고는 아니었습니다. 악용 보고도 없고, CVE도 없고, 벤더 권고문도 없습니다. 그런데도 이 사례가 눈여겨볼 만한 이유는 원인이 화려한 신종 공격이 아니라 "핀으로 고정했다고 믿었던 것을 실제로 확인하지 않았다"는 아주 단순한 설계 누락이었다는 점입니다. AI 에이전트 플러그인 마켓플레이스처럼 새로 생긴 인프라일수록 이런 기본 검증이 빠지기 쉽습니다.

우리 팀 환경이 여기 해당하는지부터 따져보셔도 충분합니다. 판단에 필요한 기준은 위 6단계에 정리해 두었습니다.

자주 묻는 질문 (FAQ)

Q: 이 취약점, 실제로 해킹 피해 사례가 있었나요?

아니요. 공개 시점인 2026-09-18 기준으로 실제 악용(in-the-wild) 사례는 보고된 바 없습니다. CVE 번호도 아직 할당되지 않았고, 4개 벤더 모두 보안 권고문을 내지 않았습니다. 사고가 아니라 사전에 공개된 취약점으로 이해하시면 됩니다.

Q: 에이전트를 최신 버전으로 업데이트하면 완전히 안전해지나요?

버전 업데이트가 1차 방어이지만, 자동 업데이트를 끈 상태에서도 plugin@marketplace 형태로 설치된 플러그인은 마켓플레이스를 강제로 새로고침한다는 예외가 있습니다. 또한 업데이트가 이미 교체된 플러그인까지 되돌리는지는 어떤 출처도 확인해 주지 않았습니다. 버전 확인과 함께 설치된 플러그인 목록도 한 번 점검하시는 걸 권합니다.

Q: GitHub 마켓플레이스만 쓰면 완전히 안전한가요?

변종 A(Claude Code·Codex·Copilot)는 GitHub가 SHA 형태의 브랜치명을 막아 두어 상대적으로 안전합니다. 다만 Gemini CLI의 FETCH_HEAD 변종은 GitHub 저장소를 쓰더라도 방어되지 않으므로, Gemini CLI 사용자는 호스트와 무관하게 별도로 대응해야 합니다.

참고 자료