Plugin4Shell AI 에이전트 취약점, 신뢰된 플러그인을 우회해 두 코딩 도구는 미패치 상태

Plugin4Shell은 검토된 플러그인을 설치하는 통상적인 절차를 사용자가 따랐음에도 4개 AI 코딩 에이전트의 핵심 보호 장치를 무력화했다. 보안 기업 AIR는 이 결함이 Claude Code, OpenAI Codex, GitHub Copilot, Gemini CLI에 영향을 미쳤다고 밝혔다. 연구진은 네 제품 모두에서 작동하는 원격 코드 실행을 입증했다.

Anthropic과 OpenAI는 AIR의 공개 제보를 받은 뒤 수정 사항을 배포했다. AIR는 2026년 9월 17일 조사 결과를 발표했을 당시 GitHub Copilot에 해당 패치가 없었다고 보고했다. 또한 Google은 영향을 받은 Gemini CLI 동작을 패치하지 않고 사용자에게 Antigravity를 사용하도록 안내했다고 밝혔다.

이러한 불균일한 대응이 핵심 문제다. 플러그인 마켓플레이스는 검토와 커밋 핀이 승인 이후의 코드 변경으로부터 개발자를 보호한다고 약속한다. Plugin4Shell AI 에이전트 취약점은 부주의한 설치, 의심스러운 승인, 또는 새로운 클릭 없이도 이 약속을 무너뜨린 것으로 전해진다.

Plugin4Shell, 신뢰된 업데이트를 원격 코드 실행으로 전환

이 공격은 프롬프트에 어떻게 답할지 결정하는 언어 모델이 아니라 플러그인 배포 과정을 표적으로 삼았다.

AI 코딩 에이전트는 점차 플러그인, 스킬, 확장 프로그램 및 기타 애드온을 지원하고 있다. 이러한 패키지는 워크플로를 맞춤화하고, 서비스를 연결하거나, 개발 환경 내에서 코드를 실행할 수 있다. 이들은 흔히 에이전트가 보유한 파일 접근, 셸 명령 실행, 인증된 시스템과의 상호작용 권한을 물려받는다.

이러한 접근 권한 때문에 에이전트 플러그인은 수동적인 텍스트 프롬프트보다 로컬 애플리케이션에 가깝다. 악성 코드가 플러그인 디렉터리에 도달하면, 에이전트를 실행하는 개발자에게 부여된 권한으로 동작할 수 있다.

AIR에 따르면 Plugin4Shell은 SHA 핀을 우회해 이 지점에 도달했다. SHA는 특정 Git 커밋을 지칭하는 데 일반적으로 사용되는 암호학적 식별자다. 플러그인을 이 식별자에 고정하면, 이후 리포지터리가 변경되더라도 설치된 코드는 고정된 상태로 유지돼야 한다.

Plugin4Shell 연구에 따르면, 영향을 받은 에이전트는 고정된 커밋을 요청했지만 실제로 체크아웃된 커밋을 검증하지 못했다. 업스트림 리포지터리를 제어하는 공격자는 Git의 이름 해석 동작을 악용해 다른 코드를 대체할 수 있었다.

마켓플레이스 레코드에는 여전히 예상된 커밋 식별자가 표시될 수 있다. 에이전트도 설치가 성공했다고 보고할 수 있다. 그러나 작업 디렉터리의 파일은 검토된 커밋이 아니라 공격자가 제어하는 브랜치에서 가져오게 된다.

AIR는 두 가지 실질적인 진입 경로를 설명했다. 공격자는 정상적인 플러그인을 게시해 사용자를 확보한 뒤, 후속 업데이트 중 리포지터리를 악성 상태로 전환할 수 있다. 또는 기존 플러그인을 지원하는 리포지터리를 탈취할 수도 있다.

두 번째 경로가 중요한 이유는 책임의 초점이 개별 플러그인 작성자에게서 벗어나기 때문이다. 플러그인은 정상 프로젝트로 시작해 모든 검토를 통과할 수 있다. 리포지터리는 개발자와 보안팀이 이를 신뢰한 뒤에야 적대적으로 변할 수 있다.

AIR는 연구진이 2026년 5월 이 문제를 발견해 6월에 4개 공급업체에 공개했다고 밝혔다. 이 회사는 9월 17일 기술 분석을 게시했다. Help Net Security는 다음 날 이 결과를 보도했다.

두 조직이 인용한 공개 증거에는 공개 이전 실제 피해자를 대상으로 Plugin4Shell이 악용됐다는 내용이 없었다. 입증된 영향은 문서화된 범죄 캠페인이 아니라 AIR의 개념 증명 테스트에서 나온 것이다.

이 구분은 즉각적인 침해에 대해 주장할 수 있는 범위를 제한한다. 그러나 손상된 통제의 중요성을 낮추지는 않는다. 성공적인 공격은 조직이 이미 검토하고 승인한 구성 요소를 통해 코드를 실행하게 된다.

이 문제는 플러그인 배포에 관한 AIR의 이전 연구도 뒤따른다. 회사는 테스트 스킬 하나가 제거되기 전 2만6,000개 이상의 에이전트에 도달했다고 밝혔다. 별도 연구에서는 13만4,000개 에이전트에 영향을 미친 925개의 탈취된 스킬을 확인한 것으로 전해진다.

이 수치는 AIR가 제시한 것이며 Plugin4Shell 공개 자료에서 독립적으로 재현되지는 않았다. 이는 연구진의 더 광범위한 주장을 보여준다. 배포 기반을 확보하고 업스트림 리포지터리를 침해하는 일은 단지 이론적 전제 조건이 아니라 현실적인 단계라는 것이다.

Plugin4Shell AI 에이전트 취약점이 SHA 핀을 우회한 방식

Plugin4Shell은 영향을 받은 각 에이전트가 최종 체크아웃된 커밋을 검증하는 대신 요청된 Git 참조를 신뢰했기 때문에 작동했다.

Claude Code, Codex, GitHub Copilot은 하나의 변형을 공유한 것으로 알려졌다. 이들의 플러그인 설치 프로그램은 리포지터리를 복제한 뒤 고정된 40자 커밋 식별자를 git checkout에 전달했다.

많은 호스팅 구성에서 Git은 커밋 식별자와 유사한 브랜치 이름을 허용한다. 하나의 이름이 브랜치와 객체를 모두 식별할 수 있으면 Git은 모호성 경고를 출력하면서 이를 참조로 해석할 수 있다.

플러그인 리포지터리를 제어하는 공격자는 고정된 커밋과 정확히 같은 이름의 브랜치를 만들 수 있다. 이후 공격자는 해당 브랜치를 리포지터리의 기본 브랜치로 설정하고 악성 코드를 가리키게 할 수 있다.

초기 복제는 공격자의 기본 브랜치를 내려받는다. 이후 체크아웃은 겉보기 커밋 식별자를 해당 로컬 브랜치로 해석할 수 있다. 그러면 에이전트는 마켓플레이스가 검토한 것과 다른 파일을 로드하거나 실행하게 된다.

이 기법이 모든 호스팅 서비스에서 동일하게 작동하는 것은 아니다. GitHub는 브랜치 이름 제한에 따르면 완전한 Git 객체 식별자처럼 보이는 브랜치 및 태그 이름을 차단한다.

그러나 AIR는 Bitbucket과 자체 호스팅 Git 서비스가 이러한 이름을 허용할 수 있다고 밝혔다. 일부 에이전트 마켓플레이스는 GitHub 외부에 호스팅된 리포지터리를 공식 지원하므로, 더 넓은 구성 범위가 노출된 상태로 남는다.

Gemini CLI는 같은 결과에 이르는 별도 경로를 사용한 것으로 전해진다. 이 설치 프로그램은 고정된 커밋을 가져온 뒤 일반적으로 가져온 콘텐츠를 가리키는 Git 참조인 FETCH_HEAD를 대상으로 체크아웃을 실행했다.

AIR는 리포지터리가 FETCH_HEAD를 기본 브랜치 이름으로 사용할 수 있음을 발견했다. 그러면 체크아웃은 가져온 커밋이 담긴 특수 파일이 아니라 해당 브랜치로 해석될 수 있다.

두 변형 모두 최종 비교가 누락된 데 의존했다. 체크아웃을 완료한 뒤 에이전트는 HEAD를 해석하고 그것이 마켓플레이스에 고정된 SHA와 일치하는지 검증해야 했다.

이 검사는 작지만, 그 위치가 중요하다. 마켓플레이스는 클라이언트가 결국 로컬 작업 트리에 무엇을 배치했는지 확인할 수 없다. 검증은 복제와 체크아웃을 수행하는 에이전트 내부에서 이뤄져야 한다.

제로클릭이라는 표현은 백그라운드 업데이트에서 비롯된다. AIR에 따르면 Claude Code와 Codex는 기본적으로 설치된 플러그인을 자동 업데이트한다. 따라서 악성 대체 코드는 마켓플레이스가 핀을 변경한 뒤 별도의 설치 결정 없이 도착할 수 있다.

피해자는 새로운 악성 플러그인을 찾을 필요가 없다. 공격자는 이미 시스템에 존재하는 플러그인을 표적으로 삼고 에이전트의 업데이트 프로세스를 기다리면 된다.

원격 코드 실행 또는 RCE는 공격자가 제어하는 명령이 대상 시스템에서 실행되는 것을 뜻한다. 그에 따른 영향 범위는 영향을 받은 에이전트가 사용할 수 있는 계정, 환경, 샌드박스, 자격 증명 및 네트워크 접근에 따라 달라진다.

AIR는 잠재적 영향을 도구를 실행하는 직원이 가진 접근 권한과 동등한 것으로 설명한다. 이는 최악의 경우를 설명한 것이지 모든 설치 환경을 보편적으로 측정한 것은 아니다.

강하게 격리된 에이전트는 임시 작업 공간만 노출할 수 있다. 반면 클라우드 자격 증명, 소스 리포지터리, 서명 키 또는 프로덕션 접근 권한을 보유한 로컬 설치 에이전트는 훨씬 더 큰 잠재적 피해 반경을 만든다.

이러한 가변성 때문에 버전 인벤토리만으로는 충분하지 않다. 보안팀은 각 에이전트가 어디서 실행되는지, 어떤 플러그인을 로드하는지, 그리고 해당 실행 경계 안에서 어떤 자격 증명을 사용할 수 있는지도 파악해야 한다.

플러그인 검토는 의도대로 작동했지만, 설치된 코드는 여전히 변경됐다

핵심 충돌은 불변의 검토라는 약속과 클라이언트 측 Git 해석의 현실 사이에 있다.

소프트웨어 공급망 통제는 흔히 승인과 실행을 분리한다. 검토자는 알려진 버전을 평가하고, 해당 다이제스트를 기록하며, 시스템이 그 버전만 설치하도록 허용한다.

이 모델은 다이제스트가 실행될 파일을 식별한다는 가정에 기반한다. Plugin4Shell은 눈에 보이는 핀은 유지하면서 그 핀과 최종 작업 트리 사이의 연결을 끊은 것으로 전해진다.

이는 사용자에게 알려지지 않은 확장 프로그램을 경계하라고 경고하는 것보다 더 심각하다. 연구진에 따르면 플러그인이 신뢰할 수 있는 마켓플레이스에서 제공되고, 검토를 통과하며, 고정 상태를 유지하더라도 공격은 여전히 작동한다.

따라서 마켓플레이스의 평판만을 바탕으로 한 보안 지침은 취약한 단계를 놓치게 된다. 로컬 에이전트가 체크아웃 과정에서 속을 수 있다면 공격자는 마켓플레이스 데이터베이스를 침해할 필요가 없다.

같은 한계는 내부 플러그인 카탈로그에도 적용된다. 기업은 모든 패키지를 검토하고 승인된 메타데이터를 미러링할 수 있다. 하지만 직원 클라이언트가 해석된 커밋을 검증하지 않으면 이러한 통제는 여전히 불완전하다.

AIR는 Plugin4Shell을 AI 에이전트 생태계 최초의 공급망 취약점이라고 부른다. 이는 회사의 규정이며 다소 신중하게 받아들일 필요가 있다.

AI 개발 도구는 이미 리포지터리 오염, 프롬프트 인젝션, 악성 구성 파일, 확장 프로그램 관련 취약점에 직면해 왔다. Plugin4Shell은 고정된 에이전트 애드온과 업데이트 경로에 초점을 맞춘다는 점에서 더 좁은 범주의 문제다.

그럼에도 이 메커니즘은 뚜렷한 신뢰 실패를 드러낸다. 검토된 에이전트 기능이 리포지터리에서 개발자의 시스템으로 이동하는 방식을 공격한다.

최근 연구는 이것이 고립된 취약 지점이 아님을 보여준다. Wiz는 2026년 7월 6개의 AI 코딩 어시스턴트를 테스트한 뒤 GhostApproval을 공개했다. 이 문제는 심볼릭 링크를 이용해 예상된 작업 공간 경계 밖의 파일에 접근했다.

GhostApproval 조사 결과는 Amazon, Anthropic, Augment, Cursor, Google, Windsurf의 제품에 영향을 미쳤다. 공급업체의 대응은 다양했으며, 여러 수정과 최소 한 건의 위협 모델 관련 이견이 있었다.

GhostApproval과 Plugin4Shell은 서로 다른 기술적 수단을 사용한다. 하나는 심볼릭 링크를 통한 경로 해석을 악용한다. 다른 하나는 플러그인 설치와 업데이트 중 Git 참조 해석을 악용한 것으로 전해진다.

두 문제를 연결하는 패턴은 사용자가 눈으로 확인한 결정과 시스템의 실제 동작 사이의 간극이다. 경로는 로컬처럼 보이지만 다른 곳으로 해석된다. 핀은 불변처럼 보이지만 다른 코드로 해석된다.

권한 프롬프트만으로는 이러한 불일치를 해결할 수 없다. 인터페이스가 신뢰된 이름을 보여주는 동안 실제 작업이 다른 대상을 향하면 사용자는 정보에 근거한 결정을 내릴 수 없다.

Anthropic은 Claude Code를 위한 보완적 보호 장치로 파일 시스템 및 네트워크 격리를 공개적으로 설명해 왔다. 샌드박싱 모델은 주입된 프로세스가 민감한 파일이나 승인되지 않은 네트워크 대상으로 접근하는 것을 막는 것을 목표로 한다.

샌드박싱은 악성 플러그인 코드의 영향을 줄일 수 있다. 특히 플러그인이 같은 제한 밖에서 실행되거나 더 광범위한 권한을 부여받는 경우, 이는 정확한 패키지 검증을 대체하지 못한다.

따라서 기업에는 두 개의 독립적인 경계가 필요하다. 설치 과정은 검토된 코드가 실제로 설치됐는지 검증해야 한다. 런타임은 실행 후 해당 코드가 접근할 수 있는 범위를 제한해야 한다.

한 계층에서의 실패가 자동으로 워크스테이션이나 클라우드 계정 탈취로 이어져서는 안 됩니다. Plugin4Shell이 중요한 이유는 많은 에이전트 배포 환경이 여전히 변경 가능한 확장 기능과 가치 있는 로컬 자격 증명을 함께 사용하기 때문입니다.

네 가지 코딩 에이전트, 네 가지 서로 다른 보안 결과

이번 공개는 유사한 플러그인 워크플로를 구현한 도구들 사이의 파편화된 패치 프로세스를 드러냈습니다.

AIR에 따르면 Anthropic은 Claude Code 취약점을 버전 2.1.179에서 수정했습니다. 회사는 Anthropic이 수정 사항을 확인한 날짜를 2026년 6월 17일로 기록했습니다.

AIR에 따르면 OpenAI는 버전 0.146.0에서 영향을 받은 Codex 동작을 수정했습니다. 연구 타임라인은 회사가 8월 12일 해당 릴리스를 수정 완료로 확인했다고 밝힙니다.

이들 제품 사용자는 자동 업데이트가 성공적으로 완료됐다고 가정해서는 안 됩니다. 관리형 워크스테이션, 오프라인 환경, 패키지 잠금, 내부 배포 시스템으로 인해 이전 버전이 계속 설치된 상태일 수 있습니다.

조직은 실제 엔드포인트를 조회하고 해당 버전을 수정된 릴리스와 비교해야 합니다. 또한 배포 프로세스가 실행 중인 에이전트 프로세스를 교체하지 않는다면 장시간 실행 중인 세션도 재시작해야 합니다.

GitHub Copilot은 다른 문제를 제기합니다. AIR는 Microsoft가 동일한 취약점 보고를 받았지만 연구가 공개될 당시까지 수정 사항을 배포하지 않았다고 밝혔습니다.

GitHub는 최근 에이전트 작업을 위한 중앙집중식 제어 기능을 확장했습니다. 9월 9일 발표에서는 관리자가 managed agent permissions를 통해 셸 명령, 파일 작업, 네트워크 도메인을 차단, 허용 또는 승인 요구 대상으로 설정할 수 있다고 설명했습니다.

이러한 제어 기능은 영향을 줄일 수 있지만, Plugin4Shell 패치의 증거는 아닙니다. 패치되지 않은 설치 프로그램과 제한적인 런타임 정책은 공격의 서로 다른 단계에 대응합니다.

따라서 Copilot 관리자는 제품별 권고문, 수정 버전 또는 벤더 확인을 찾아야 합니다. 그때까지 조직은 마켓플레이스 플러그인 업데이트를 중단하거나 에이전트를 자신들이 통제하는 승인된 리포지터리로 제한할 수 있습니다.

Gemini CLI의 상태는 가장 복잡합니다. AIR는 Google이 8월 4일 영향을 받은 워크플로를 패치하지 않겠다고 확인했고 Antigravity로의 마이그레이션을 권고했다고 밝혔습니다.

Google은 이미 개인 사용자를 Gemini CLI에서 Antigravity CLI로 이전하기 시작했습니다. 6월 발표에 따르면 Gemini CLI는 개인 계정의 요청 처리를 중단했지만 엔터프라이즈 및 API 키 사용은 계속 이용할 수 있었습니다.

그러나 Google의 이전 전환 공지에서는 오픈소스 Gemini CLI 프로젝트가 엔터프라이즈 고객을 위해 모델 업데이트, 버그 수정 및 보안 수정을 계속 제공할 것이라고도 밝혔습니다.

이 공개 문구는 모든 Gemini CLI 설치가 무기한 취약한 상태로 남을 것이라는 주장과 깔끔하게 부합하지 않습니다. 이는 관리자에게 중요한 검증 공백을 남깁니다.

Google의 9월 변경 로그는 소비자 전환 이후에도 Gemini CLI 릴리스가 계속되고 있음을 보여 줍니다. 또한 특정 checkout 결함과는 무관한 보안 강화 항목도 나열합니다. 이러한 활동이 Plugin4Shell 수정 사항을 입증하는 것은 아닙니다.

신중한 결론은 더 제한적입니다. AIR는 공개 당시 Gemini CLI용 Plugin4Shell 패치가 없었다고 보고하며 Antigravity를 권고했습니다. Google은 엔터프라이즈 용도의 Gemini CLI 일부를 계속 유지보수했지만, 인용된 릴리스 노트 중 이 특정 수정 사항을 식별하는 것은 없습니다.

엔터프라이즈 사용자는 일반적인 유지보수 문구만으로 안전하다고 추론해서는 안 됩니다. 확장 기능 설치 또는 업데이트 후 자신의 릴리스가 최종 checkout된 커밋을 검증한다는 직접적인 확인이 필요합니다.

또한 마이그레이션을 단순한 이름 변경으로 취급해서도 안 됩니다. 검토 없이 구성을 이전하면 skills, hooks, MCP servers, 자격 증명을 새 에이전트로 옮기는 과정에서 다른 위험이 재현될 수 있습니다.

AIR는 Antigravity가 Plugin4Shell이 악용한 플러그인 SHA-pinning 메커니즘을 사용하지 않는다고 밝혔습니다. 연구자들의 분석에 따르면 이는 이 특정 공격 경로가 적용되지 않는다는 의미입니다.

그렇다고 Antigravity가 악성 플러그인, 프롬프트 인젝션, 안전하지 않은 도구 또는 향후 공급망 실패에 면역이라는 뜻은 아닙니다. 보안팀은 마이그레이션 후에도 동일한 격리 및 최소 권한 요구 사항을 유지해야 합니다.

네 가지 대응은 이 버그를 넘어선 거버넌스 문제를 드러냅니다. 유사한 기능이 공통 공개 관행, 공통 심각도 평가 또는 동기화된 완화 조치 없이 여러 에이전트에 배포될 수 있습니다.

개발자는 개별 변경 로그와 벤더 성명을 추적해야 합니다. 이후 엔터프라이즈 관리자는 이 불균일한 기록을 하나의 시행 가능한 보안 체계로 전환해야 합니다.

개발팀이 즉시 바꿔야 할 사항

첫 번째 우선순위는 취약한 플러그인 업데이트를 중단하고, 에이전트 버전을 검증하며, 모든 코딩 에이전트가 이용할 수 있는 자격 증명을 줄이는 것입니다.

Claude Code의 경우 조직은 모든 설치를 버전 2.1.179 이상으로 옮겨야 합니다. Codex의 경우 AIR는 버전 0.146.0을 수정된 릴리스로 식별합니다.

팀은 설문조사가 아닌 엔드포인트 인벤토리를 통해 버전을 확인해야 합니다. 개발자는 로컬 터미널, IDE 확장 기능, 원격 워크스페이스 및 CI 시스템 전반에서 여러 코딩 에이전트를 사용할 수 있습니다.

GitHub Copilot의 경우 관리자는 GitHub 또는 Microsoft에 명시적인 완화 지침을 요청해야 합니다. 관련 없는 권한 개선을 checkout 취약점이 수정되었다는 확인으로 간주해서는 안 됩니다.

플러그인 기능이 필수적이지 않은 곳에서는 서드파티 마켓플레이스 패키지를 비활성화하는 것이 가장 명확한 임시 완화책입니다. 이를 비활성화할 수 없는 조직은 자동 업데이트를 중단하고 리포지터리 소스를 제한해야 합니다.

Gemini CLI 사용자는 특히 마켓플레이스 확장 기능을 사용하는 경우 Antigravity로의 마이그레이션을 평가해야 합니다. 엔터프라이즈 고객은 자신이 사용하는 정확한 Gemini CLI 릴리스의 상태에 대한 서면 확인도 요청해야 합니다.

공개 후 영향을 받은 플러그인을 제거하는 것은 유용하지만 불완전합니다. 손상된 패키지는 제거 전에 지속성을 만들거나, 시작 파일을 수정하거나, 자격 증명을 복사하거나, 리포지터리를 변경했을 수 있습니다.

사고 대응 담당자는 플러그인 업데이트 이력, Git 활동, 프로세스 실행, 네트워크 연결 및 민감한 파일 변경을 검토해야 합니다. 취약한 자동 업데이트가 활성화돼 있었다면 관련 기간은 공개 이전부터 시작됩니다.

텔레메트리가 예상치 못한 플러그인 코드 실행을 나타낼 경우 팀은 자격 증명을 교체해야 합니다. 우선 대상에는 소스 제어 토큰, 클라우드 자격 증명, 패키지 게시 키, 서명 자료 및 셸 환경에 저장된 시크릿이 포함됩니다.

자격 증명의 범위는 교체만큼 중요합니다. AI 코딩 에이전트는 이를 실행하는 개발자가 해당 권한을 보유한다는 이유만으로 제한 없는 프로덕션 접근 권한을 상속받아서는 안 됩니다.

에이전트 신원을 분리하면 비정상적인 작업을 더 쉽게 차단하고 감사할 수 있습니다. 단기 토큰은 워크스테이션에서 수집된 자격 증명의 가치를 제한합니다.

런타임 격리는 또 다른 계층을 제공합니다. 파일 접근은 기본적으로 활성 프로젝트로 제한해야 하며, 네트워크 접근에는 작업에 적합한 좁은 허용 목록을 사용해야 합니다.

셸 실행에도 유사한 경계가 필요합니다. 개발자 계정으로 어떤 명령이든 호출할 수 있는 플러그인은 생성된 소스 코드에만 적용되는 많은 제어를 우회할 수 있습니다.

조직은 샌드박스 규칙이 플러그인, hooks, 패키지 관리자 및 MCP servers가 생성한 하위 프로세스를 포괄하는지 테스트해야 합니다. 모델의 직접 도구에 대한 제한이 모든 확장 프로세스를 포괄하지는 않을 수 있습니다.

플러그인 거버넌스에도 더 강력한 증거가 필요합니다. 내부 카탈로그에는 검토된 커밋, 리포지터리 출처, 확인된 트리 식별자, 검토자, 승인 날짜 및 배포 버전을 저장해야 합니다.

설치 프로그램은 checkout 후 확인된 HEAD를 검증해야 합니다. 승인된 커밋과 일치하지 않으면 경고 후 계속 진행하는 대신 설치를 중단해야 합니다.

보안팀은 악성 실행을 재현하지 않고도 이 동작을 테스트할 수 있습니다. 통제된 리포지터리가 모호한 참조를 제시하는 동안, 검증 시스템은 설치가 실패 시 안전하게 종료되는지 확인할 수 있습니다.

그 결과는 조달 및 내부 승인 테스트의 일부가 되어야 합니다. 벤더는 클론, 가져오기 및 업데이트 후 에이전트가 플러그인 콘텐츠를 어떻게 검증하는지 설명할 수 있어야 합니다.

팀은 각 플러그인이 존재하는 이유에 대한 신뢰할 수 있는 기록도 필요합니다. 검색 가능한 engineering knowledge base는 승인, 담당자, 사고 및 교체 결정을 연결할 수 있습니다.

이러한 문서화가 악용을 막지는 못합니다. 그러나 또 다른 공개가 발생했을 때 영향을 받은 팀을 식별하고 위험한 통합을 제거하는 데 필요한 시간을 줄입니다.

마지막으로, 개발자가 광고된 pin을 신뢰했다는 이유로 비난받아서는 안 됩니다. Plugin4Shell은 그러한 신뢰를 합리적으로 만들기 위해 설계된 제어를 우회한 것으로 알려졌습니다.

시정 조치는 벤더 코드, 엔터프라이즈 정책 및 런타임 아키텍처 전반에 걸쳐 이뤄져야 합니다. 모든 업데이트를 검사하도록 사용자를 교육하는 것만으로는 설치 프로그램이 승인된 digest와 다른 코드를 실행하는 문제를 보완할 수 없습니다.

에이전트 플러그인 보안이 개선되고 있는지 보여 줄 세 가지 신호

다음 시험대는 벤더가 이 공개를 더 폭넓은 보안 약속이 아니라 검증 가능한 설치 제어로 전환하는지 여부입니다.

첫 번째 신호는 GitHub Copilot에 대한 구체적인 완화 조치입니다. 관리자는 checkout 이후 커밋 검증을 확인하는 보안 권고문, 릴리스 식별자 또는 기술적 성명을 찾아야 합니다.

일반적인 Copilot 업데이트로는 이 질문에 답할 수 없습니다. 관련 증거는 클라이언트가 작업 트리의 HEAD를 확인하고 이를 마켓플레이스 pin과 비교하는지 여부입니다.

GitHub가 이 동작을 문서화하고 지원되는 Copilot 환경 전반에 배포한다면 현재의 패치 공백은 줄어들 것입니다. 계속된 침묵은 일관성 없는 취약점 처리에 대한 우려를 강화할 것입니다.

두 번째 신호는 엔터프라이즈 Gemini CLI 사용자를 위한 Google의 설명입니다. 공개 전환 문구는 엔터프라이즈 접근과 보안 유지보수가 계속된다고 말하는 반면, AIR는 Plugin4Shell 패치가 없다고 보고합니다.

Google은 영향을 받는 버전을 명시하고, 수정 사항의 존재 여부를 설명하며, 지원 일정을 정의함으로써 이 긴장을 해소할 수 있습니다. 구체적인 권고문은 팀이 패치와 마이그레이션 중 선택하는 데 도움이 될 것입니다.

Gemini CLI가 검증된 커밋 검사를 받게 된다면 AIR의 공개 당시 상태는 더 이상 최신이 아닙니다. Google이 이를 제공하지 않겠다고 확인한다면 조직은 마이그레이션을 제품 선호가 아닌 보안 요구 사항으로 다뤄야 합니다.

세 번째 신호는 검증 가능한 클라이언트 동작을 마켓플레이스 수준에서 채택하는 것입니다. 마켓플레이스만으로 최종 checkout을 강제할 수는 없지만, 호환 가능한 에이전트를 요구하고 안전하지 않은 리포지터리 구성을 거부할 수는 있습니다.

유용한 변화에는 서명된 매니페스트, 불변 패키지 아티팩트, 출처 증명 및 확인된 커밋을 포함한 설치 영수증이 포함될 것입니다. 각 제어는 독립적으로 테스트 가능한 상태를 유지해야 합니다.

에이전트 벤더는 플러그인이 생성된 명령과 동일한 샌드박스 안에서 실행되는지도 공개해야 합니다. 검증된 패키지라도 검토 전에 업스트림에서 손상됐거나 간과된 취약점을 포함할 수 있습니다.

더 큰 교훈은 플러그인 자체가 본질적으로 안전하지 않다는 것이 아닙니다. 자율 에이전트가 패키징 오류를 개발자 권한으로 수행되는 작업으로 전환한다는 점입니다.

Plugin4Shell은 구현이 동일한 검증되지 않은 가정에 의존했기 때문에 네 개의 경쟁 제품을 가로지른 것으로 알려졌습니다. 요청된 Git 식별자가 실제 설치된 코드와 동등한 것으로 취급됐습니다.

개발자와 보안 책임자는 이제 모든 코딩 에이전트 벤더에 직접적인 질문을 던져야 합니다. 검토된 코드가 실제로 머신에서 실행되는 코드임을 무엇으로 증명할 수 있는가?

Copilot과 Gemini CLI가 제품별 답변을 내놓기 전까지, 영향을 받는 조직은 플러그인 사용을 제한하고 모든 에이전트 버전을 검증하며 자격 증명을 격리해야 합니다. 패치된 Claude Code 또는 Codex를 사용하는 팀도 설치된 확장 기능을 감사하고 모든 엔드포인트에 업데이트가 도달했는지 확인해야 합니다.

Plugin4Shell AI 에이전트 취약점은 결국 운영 가시성에 대한 시험대다. 귀사의 조직은 다음 백그라운드 업데이트가 실행되기 전에 각 에이전트와 해당 플러그인, 버전, 권한을 식별할 수 있는가?