Plugin4Shell이 말해준 것: AI 코딩 에이전트 플러그인은 이제 공급망이다

2026.09.22ops

AIR Security가 공개한 Plugin4Shell은 Claude Code, Codex, Copilot, Gemini CLI의 플러그인 SHA pinning을 우회할 수 있음을 보여줬다. 핵심은 공포가 아니라, 에이전트 플러그인을 npm 의존성처럼 재고·검증·격리하는 운영 습관이다.

개발자 노트북 위에 AI agent plugin, pinned SHA, git branch가 경고선으로 연결된 어두운 편집 그래픽
Plugin4Shell의 핵심은 ‘검토한 커밋을 요청했다’와 ‘그 커밋이 실제로 실행됐다’가 다를 수 있다는 점이다.

결론부터

2026년 9월 18일 전후 공개된 Plugin4Shell은 AI 코딩 에이전트를 쓰는 개발자에게 꽤 실무적인 경고다.[1][2] Claude Code, OpenAI Codex, GitHub Copilot, Gemini CLI처럼 플러그인·스킬을 설치하는 에이전트가 “이 커밋으로 고정했다”고 말해도, 실제 디스크에 내려온 코드가 그 커밋인지 확인하지 않으면 pinning은 잠금장치가 아니라 안내문에 가깝다.

이 글에서 가져갈 한 문장은 이것이다.

AI 에이전트 플러그인은 설정 파일이 아니라 실행 가능한 공급망이다.
설치 목록, 업데이트 방식, Git host, 권한 범위를 npm dependency처럼 관리해야 한다.

공포를 키우려는 글은 아니다. GitHub.com은 40자리 해시처럼 보이는 branch/tag 이름을 막는다고 알려졌고, The Hacker News는 기본 GitHub 기반 marketplace만 쓰는 경우 branch-name 변종의 노출이 제한적이라고 정리했다.[2] 반대로 Bitbucket, self-hosted Git, 외부 marketplace, Gemini CLI의 FETCH_HEAD 변종처럼 예외도 있다.[1][2] 그러니 핵심은 “모두 당장 털렸다”가 아니라 “내 에이전트가 어디에서 어떤 코드를 자동으로 가져와 실행하는지 오늘 확인하자”다.

기준 시점은 2026년 9월 22일이다. 아래 내용은 AIR Security 공개 글, The Hacker News 보도, Help Net Security 보도, Cloud Security Alliance 연구 노트를 대조해 정리했다.[1][2][3][4]

무슨 일이 있었나

AIR Security는 Plugin4Shell을 “AI agent ecosystem의 첫 공급망 취약점”이라고 불렀다.[1] 표현은 크지만, 메커니즘은 단순하다.

AI 코딩 에이전트 플러그인 marketplace는 보통 “검토한 특정 commit SHA”를 pin으로 저장한다. 사용자는 marketplace가 검토한 버전만 설치된다고 믿는다. 문제는 일부 에이전트가 Git에게 git checkout <SHA> 같은 요청을 보낸 뒤, checkout 결과의 실제 HEAD가 그 SHA와 같은지 다시 확인하지 않았다는 점이다.[1][4]

공격자가 플러그인 저장소를 제어하고, Git host가 40자리 해시처럼 생긴 branch 이름을 허용하면 이상한 일이 생긴다. 공격자는 pin과 같은 이름의 branch를 만들고 그 branch를 악성 코드로 가리킨다. Git 참조 해석이 branch ref를 commit object보다 먼저 잡는 상황에서는, 에이전트가 “고정된 SHA”를 요청했는데 실제로는 branch 쪽 코드가 내려올 수 있다.[1][3]

Gemini CLI는 조금 다른 변종으로 설명된다. AIR와 여러 보도는 Gemini CLI가 commit을 fetch한 뒤 FETCH_HEAD를 checkout하는 흐름에서, default branch 이름이 FETCH_HEAD일 때 의도와 다른 코드가 디스크에 놓일 수 있다고 설명했다.[2][4]

40자리 커밋 해시처럼 보이는 브랜치가 pinned commit 경로를 가로채는 모습을 표현한 git ref 지도
pinning은 요청 문자열이 아니라 checkout 뒤의 실제 HEAD를 확인할 때 보안 통제가 된다.

왜 ‘zero-click’이라는 말이 붙었나

zero-click이라는 표현은 “피해자가 새로 설치 버튼을 누르지 않아도 된다”는 뜻에 가깝다. AIR는 Claude Code와 Codex에서 플러그인 자동 업데이트가 배경에서 동작할 수 있고, 이미 설치한 신뢰 플러그인이 업데이트되면서 바뀐 pin을 다시 checkout하는 순간 악성 코드가 들어올 수 있다고 설명했다.[1][3]

중요한 차이가 있다. 이것은 아무 웹페이지나 열면 감염되는 류의 브라우저 취약점과 다르다. 조건이 필요하다.

  • 에이전트가 marketplace 플러그인·스킬을 설치하고 실행한다.
  • 공격자가 해당 플러그인 저장소를 제어하거나, 나중에 저장소를 탈취한다.
  • Git host 또는 설치 방식이 해시처럼 보이는 ref, FETCH_HEAD 같은 모호한 이름을 허용한다.
  • 에이전트가 checkout 뒤 실제 HEAD를 pinned SHA와 비교하지 않는다.
  • 자동 업데이트가 켜져 있으면 사용자 개입 없이 다시 내려받을 수 있다.

그래서 이 사건의 실무적 의미는 “AI 모델이 위험하다”가 아니다. “에이전트가 가져오는 주변 코드가 위험하다”다. 모델은 텍스트를 만들지만, 플러그인은 로컬 파일을 읽고 명령을 실행하고 네트워크를 호출할 수 있다. 내 SSH key, cloud credential, internal repo에 닿는 쪽은 모델보다 실행 환경이다.

각 도구 상태를 어떻게 봐야 하나

공개 자료 기준 상태는 다음과 같이 정리된다.[1][2][3][4]

에이전트 공개된 상태 오늘 할 일
Claude Code AIR 기준 2.1.179에서 수정 확인 2.1.179 이상인지 확인하고, 플러그인 자동 업데이트·외부 host 사용 여부를 본다
OpenAI Codex AIR 기준 0.146.0에서 수정 확인 0.146.0 이상인지 확인한다. 오래된 CLI/standalone binary를 남겨두지 않는다
GitHub Copilot AIR는 client fix가 없다고 주장. GitHub는 github.com이 SHA-shaped branch/tag를 막는다고 설명 Copilot 플러그인이 GitHub.com 외 host를 쓰는지 확인한다. 조직 정책으로 허용 host를 제한한다
Gemini CLI Google이 deprecated했고 AIR 기준 수정하지 않음 계속 써야 한다면 plugin 사용을 중단하거나 Antigravity 등 대체 경로를 검토한다

여기서 가장 조심할 점은 “패치됐다”는 말만 보고 끝내지 않는 것이다. The Hacker News는 Anthropic 2.1.179 release notes에 이 수정이 명시적으로 보이지 않는다고 지적했다.[2] 즉 운영자는 vendor blog 한 줄보다 로컬 버전, 설치 경로, 플러그인 캐시, 조직 정책을 함께 봐야 한다.

Claude Code, Codex, Copilot, Gemini CLI 플러그인을 호스트, 자동 업데이트, 권한, 패치 상태로 분류한 운영 보드
먼저 해야 할 일은 새 도구 설치가 아니라, 이미 설치된 에이전트와 플러그인의 재고를 적는 것이다.

이번 사건이 익숙하게 느껴지는 이유

전통적인 package manager 세계에서는 이미 비슷한 교훈을 여러 번 겪었다. lockfile, checksum, signature, provenance, registry policy, maintainer takeover, dependency confusion 같은 것들이다. 차이점은 AI 코딩 에이전트 플러그인이 더 조용하고 더 넓은 권한에서 움직일 수 있다는 점이다.

npm 패키지를 설치하면 적어도 package.json, lockfile, CI log, dependency review 같은 흔적이 남는다. 반면 에이전트 플러그인은 “생산성을 높이는 도구”로 받아들여져서 재고 목록이 없거나, 개인 개발자 로컬 프로필에만 있거나, 자동 업데이트가 켜진 채 방치되기 쉽다.

또 하나의 차이는 실행 맥락이다. AI 코딩 에이전트는 보통 소스코드 전체, issue, PR, terminal, local credential, dev server, cloud CLI와 가까이 있다. 같은 악성 코드라도 브라우저 확장 프로그램보다 더 깊은 개발 맥락을 볼 수 있다.

그래서 플러그인 보안은 “설치하지 말자”가 아니라 “어디까지 보게 할 것인가”로 접근해야 한다.

실무 체크리스트: 90분 안에 할 수 있는 일

아래 표는 팀 규모와 상관없이 바로 쓸 수 있다.

점검 질문 바로 할 일
에이전트 재고 누가 어떤 AI coding agent를 쓰는가 Claude Code, Codex, Copilot, Gemini CLI, Cursor/기타 agent CLI 설치 경로와 버전을 적는다
플러그인 목록 어떤 plugin/skill/MCP가 설치돼 있는가 사용자 홈 디렉터리, agent config, marketplace cache를 확인해 목록화한다
출처 플러그인 source repo가 어디인가 GitHub.com, Bitbucket, GitLab, self-hosted Git, zip archive를 구분한다
업데이트 자동 업데이트가 켜져 있는가 외부 host 플러그인은 auto update를 끄거나 승인형으로 바꾼다
권한 플러그인이 무엇을 읽고 실행할 수 있는가 shell/file/network/cloud CLI 접근을 최소화한다
검증 pin이 실제 HEAD와 일치하는가 설치 후 git rev-parse HEAD와 expected SHA를 비교하는 wrapper/gate를 둔다
격리 플러그인 실패가 어디까지 번지는가 production credential 없는 worktree, dev container, sandbox에서 먼저 실행한다

가장 간단한 수동 점검은 “플러그인 저장소가 detached HEAD 상태로 expected SHA에 있는지” 보는 것이다. agent별 플러그인 저장 위치는 다르지만, Git repo 형태라면 원리는 같다.

# 예시: 플러그인 디렉터리에서 실행
expected="<marketplace가 pin으로 기록한 40자리 SHA>"
actual="$(git rev-parse HEAD)"
branch="$(git symbolic-ref --short -q HEAD || true)"

test "$actual" = "$expected" || echo "PIN MISMATCH: $actual != $expected"
test -z "$branch" || echo "NOT DETACHED: currently on branch $branch"

이 스크립트가 완전한 해결책은 아니다. agent가 설치 직후 무엇을 실행하는지, 플러그인 cache가 어디인지, marketplace metadata가 어디에 있는지는 도구마다 다르다. 그래도 운영 관점에서는 좋은 시작점이다. “pin이 있다”가 아니라 “받은 코드가 pin과 같다”를 확인하는 습관을 만든다.

에이전트 플러그인이 source code, credentials, network 접근권한과 방화벽으로 분리된 보안 샌드박스 장면
플러그인은 편의 기능이 아니라 내 파일과 토큰에 닿을 수 있는 실행 코드다. 권한 경계를 작게 잡아야 한다.

내 자동화에 남길 규칙

이번 글을 쓰며 seonoh.dev 자동화에도 바로 남길 규칙이 생겼다. 블로그 파이프라인도 AI agent, browser automation, image generation, admin upload, Cloudflare deploy가 이어진다. 편의를 위해 도구를 붙이다 보면 “검토되지 않은 코드가 배포 키와 같은 공간에 놓이는” 구조가 생기기 쉽다.

다음 자동화 규칙은 이렇게 잡는다.

  1. agent plugin은 dependency로 취급한다. 새 플러그인이나 skill을 쓰면 이름, 출처, pin, update 정책을 작업 산출물에 남긴다.
  2. 배포 키가 있는 환경에서 외부 플러그인을 처음 실행하지 않는다. 초안 작성, 이미지 생성, preview 생성은 가능한 한 production deploy key와 분리한다.
  3. zip·preview·업로드 전에 diff를 확인한다. 의도한 글과 이미지 외에 agent config, token, plugin cache가 섞이면 fail한다.
  4. 자동 업데이트는 ‘편의 기능’이 아니라 변경 채널이다. 외부 host 기반 플러그인은 자동 업데이트를 기본 허용하지 않는다.
  5. 검증은 read-back으로 끝낸다. “업데이트했다”보다 실제 버전과 실제 checkout 결과가 맞는지가 중요하다.

이 규칙은 거창하지 않다. 하지만 AI 도구가 로컬 개발 권한을 점점 많이 갖는 상황에서는 이런 작고 지루한 표가 사고를 줄인다.

독자가 오늘 적용할 1가지

오늘 하나만 한다면 이것이다.

AI 코딩 에이전트별로 “설치된 플러그인/스킬/MCP 목록, source host, 자동 업데이트 여부, 현재 버전”을 한 장 표로 만든다.

표를 만들다 보면 바로 보이는 것들이 있다. 더 이상 쓰지 않는 plugin, 개인 테스트로 설치한 외부 Git repo, self-hosted Git에서 가져오는 skill, 자동 업데이트가 켜진 CLI, 팀원이 버전을 모르는 agent가 나온다. 그중 가장 위험한 하나만 제거하거나 업데이트해도 충분히 의미 있다.

운영자가 노트북에서 에이전트 버전 업데이트, 플러그인 호스트 확인, auto update 제한 체크리스트를 점검하는 장면
오늘 할 일은 단순하다. 업데이트하고, 외부 Git host 플러그인을 확인하고, 자동 업데이트와 권한을 줄인다.

FAQ

Plugin4Shell은 실제 침해 사례가 확인됐나?

공개 보도 기준으로는 실제 악용이 확인됐다는 신호는 없다. The Hacker News는 9월 18일 기준 CVE와 vendor security advisory가 없고, 실제 공격 징후도 확인되지 않았다고 정리했다.[2] 다만 AIR는 working PoC를 만들고 vendor에게 6월에 알렸다고 밝혔다.[1]

GitHub.com에 있는 플러그인도 위험한가?

branch-name 변종은 GitHub.com이 40자리 commit SHA처럼 보이는 branch/tag 이름을 막기 때문에 제한된다고 알려졌다.[2] 하지만 모든 플러그인이 GitHub.com에만 있는 것은 아니고, Gemini CLI 변종은 FETCH_HEAD 흐름을 다룬다. 따라서 “GitHub라서 끝”이 아니라 source host와 agent별 동작을 함께 봐야 한다.

Claude Code와 Codex는 업데이트만 하면 끝인가?

패치 버전 이상이면 공개된 SHA checkout 우회는 막힌 것으로 알려졌다.[1][3] 그래도 플러그인 재고, 자동 업데이트, 권한 범위, 오래된 binary 잔존 여부는 별도 문제다. 업데이트는 시작이지 전체 공급망 관리의 끝은 아니다.

Copilot은 어떻게 해야 하나?

AIR는 Microsoft가 client fix를 내지 않았다고 주장했고, GitHub 쪽은 GitHub.com의 branch/tag 이름 제한을 근거로 노출을 낮게 설명했다.[2][4] 실무적으로는 Copilot 플러그인이 GitHub.com 밖의 host를 쓰는지, 조직 정책으로 외부 plugin source를 제한할 수 있는지, plugin 실행 권한을 줄일 수 있는지 확인하는 것이 안전하다.

AI 에이전트 플러그인을 아예 금지해야 하나?

그럴 필요는 없다. 다만 플러그인을 “프롬프트 모음”처럼 가볍게 보지 말아야 한다. 실행 코드라면 의존성 검토, 버전 pin, 실제 checkout 검증, 최소 권한, sandbox, 로그가 필요하다. 특히 cloud credential과 source code가 있는 개발 머신에서는 더 그렇다.

타깃 유입 키워드

Plugin4Shell, AI 코딩 에이전트 보안, Claude Code 플러그인 취약점, Codex 0.146.0, Copilot plugin supply chain, Gemini CLI FETCH_HEAD, agent plugin SHA pinning

Sources

[1] https://www.air.security/blog-posts/plugin4shell — Plugin4Shell - Zero Click RCE Vulnerability found in top 4 most popular coding agents
[2] https://thehackernews.com/2026/09/plugin4shell-lets-repository-owners.html — Plugin4Shell Lets Repository Owners Swap Pinned Plugin Code Across Four AI Coding Agents
[3] https://www.helpnetsecurity.com/2026/09/18/plugin4shell-ai-coding-agents-vulnerability/ — Zero-click RCE vulnerability hit four major AI coding agents, two remain unpatched
[4] https://labs.cloudsecurityalliance.org/research/csa-research-note-plugin4shell-ai-coding-agent-supply-chain/ — Plugin4Shell: SHA-Pinning Bypass Enables AI Coding Agent RCE

← 글 목록