Gemini CLI가 MCP를 믿기 전에 막은 두 경로: OAuth SSRF와 작업공간 신뢰

원격 MCP 서버를 연결하는 일과 내려받은 저장소에서 코딩 에이전트를 실행하는 일에는 공통점이 있다. 둘 다 외부에서 건네받은 문자열이 네트워크 요청이나 프로세스 실행으로 바뀔 수 있다. 화면에 승인 버튼이 있다는 것만으로는 충분하지 않다. 승인 전에 어떤 설정을 읽었고, 그 설정이 어디로 요청을 보내며, 제한 모드가 실제 실행 경로까지 전달되는지 확인해야 한다.

Google이 9월 2일 공개한 Gemini CLI v0.59.0-preview.0은 이 경계에서 생기는 두 문제를 고쳤다. 하나는 MCP OAuth 메타데이터가 로컬·사설 네트워크로 요청을 돌릴 수 있었던 SSRF 경로다. 다른 하나는 제한된 작업공간에서도 저장소가 정의한 MCP 서버와 도구 설정이 허용 쪽으로 흘러갈 수 있었던 신뢰 판정 경로다. 둘을 함께 보면 에이전트 보안에서 "기본 거부"를 코드 어디에 놓아야 하는지 선명해진다.

요약: 연결 전 검증과 실행 전 필터가 따로 필요하다

첫 번째 수정인 PR #29081은 OAuth discovery, 동적 클라이언트 등록, 토큰 교환·갱신 전에 URL을 검사한다. 원격 endpoint에는 HTTPS를 요구하고, MCP 서버 origin과 resource_metadata의 origin을 대조한다. IP가 직접 적혀 있든 DNS 이름 뒤에 숨어 있든 사설망, loopback, link-local, 클라우드 instance metadata 주소를 거부한다. 로컬 MCP 서버에 연결할 때만 localhost 계열 HTTP를 허용한다.

두 번째 수정인 PR #29099는 환경의 제한 신호를 로컬 설정보다 먼저 평가한다. GEMINI_RESTRICTED_MODE=true 또는 GEMINI_CLI_TRUST_WORKSPACE=false이면 신뢰되지 않은 작업공간으로 판정한다. A2A 서버는 이 판정을 받은 뒤 저장소가 지정한 mcpServers, policyPaths, adminPolicyPaths, tools, telemetry를 설정 객체에서 제거한다.

둘은 같은 패치가 아니다. 네트워크 목적지를 검사하는 층과 저장소 설정의 실행 권한을 결정하는 층이 따로 있다. OAuth URL 검증만으로 악성 로컬 명령을 막을 수 없고, 작업공간 신뢰만으로 허용된 원격 MCP 서버가 돌려준 악성 metadata URL을 막을 수도 없다.

MCP OAuth에서 문자열이 내부 요청으로 바뀌는 과정

원격 MCP 서버가 인증을 요구하면 클라이언트는 WWW-Authenticate 헤더의 resource_metadata를 따라 OAuth 보호 자원 메타데이터를 찾을 수 있다. 여기서 얻은 authorization_servers와 registration endpoint, token endpoint를 다시 호출한다. 이 값들을 그대로 신뢰하면 공격자가 CLI를 대신해 127.0.0.1, 사설망 서비스, 169.254.169.254 같은 클라우드 metadata endpoint에 요청을 보내게 만들 수 있다.

PR #29081은 공통 validateOAuthEndpointUrl 관문을 넣었다. 프로토콜은 HTTP와 HTTPS만 허용하되 원격 대상은 HTTPS여야 한다. resource_metadata는 MCP 서버와 origin이 같아야 한다. hostname은 비동기 DNS 조회 후 반환된 모든 주소를 검사하며, 사설 IPv4·IPv6, loopback, link-local, benchmark, multicast와 broadcast 범위를 막는다. 동적 등록 POST와 authorization code 교환, refresh token 요청도 실제 fetch 직전에 같은 검증을 거친다.

원격 MCP 서버가 제시한 OAuth URL을 HTTPS, origin, 사설 IP, DNS 결과, 등록·토큰 endpoint의 다섯 관문에서 검사한 뒤 공개 HTTPS 요청만 허용하는 흐름도

OAuth discovery는 다음 endpoint를 계속 가리킨다. 최초 metadata뿐 아니라 등록과 token 요청 직전에도 목적지를 다시 검사해야 한다. 출처: github.com/google-gemini/gemini-cli/pull/29081.

여기서 중요한 것은 최초 URL만 검사하지 않았다는 점이다. OAuth는 discovery 결과가 다음 endpoint를 가리키는 연쇄 프로토콜이다. 입구 하나를 검사해도 registration이나 token URL이 별도 검증 없이 요청되면 우회 경로가 남는다. 반대로 로컬 개발까지 전부 막지는 않았다. 사용자가 처음부터 로컬 MCP 서버에 연결하는 경우에만 loopback HTTP 예외를 전달한다. 원격 서버가 로컬 주소로 방향을 바꾸는 경우에는 같은 예외를 주지 않는다.

작업공간 신뢰는 설정 로딩 뒤가 아니라 실행 전에 닫혀야 한다

저장소의 .gemini/settings.json은 편리하지만 단순한 문서가 아니다. mcpServers의 stdio transport는 프로세스를 시작할 수 있고, tools는 사용 가능한 도구를 바꾸며, telemetry는 데이터가 향하는 곳을 지정할 수 있다. 따라서 저장소를 열어 코드를 읽는 행위와 저장소가 제안한 실행 구성을 받아들이는 행위를 같은 신뢰 결정으로 묶으면 위험하다.

공식 Trusted Folders 문서는 신뢰되지 않은 폴더에서 workspace settings와 .env를 무시하고, MCP 서버 연결·custom command·자동 승인 등을 제한한다고 설명한다. PR #29099는 그 정책이 A2A 서버의 실제 설정 조립 과정에서도 유지되도록 고쳤다. 환경 변수가 "제한됨"을 말하면 folder trust 옵션의 permissive fallback보다 먼저 false를 반환한다. 판정값이 없을 때도 Config.isTrustedFolder()는 true를 추측하지 않고 false로 닫힌다.

restricted mode 환경 신호가 신뢰 판정을 false로 만들고 저장소의 MCP 서버, policy, admin policy, tools, telemetry 설정을 실행 전에 제거하는 흐름도

신뢰되지 않은 작업공간에서는 저장소 설정을 읽었다는 사실이 실행 권한으로 이어지지 않도록 영향 있는 설정을 제거한다. 출처: github.com/google-gemini/gemini-cli/pull/29099.

그 뒤가 더 중요하다. trusted=false를 로그에만 남기지 않고 실행 영향을 가진 다섯 설정을 undefined로 바꾼다. 특히 저장소가 지정한 MCP 서버를 걸러내므로 A2A 서버 시작 과정에서 의도하지 않은 child process가 뜨는 경로를 차단한다. policy와 admin policy 경로, 도구, telemetry도 함께 제거해 "MCP만 막았지만 다른 설정이 권한을 다시 넓히는" 틈을 줄였다.

실전 적용: 네 개의 경계를 점검한다

첫째, 설치 버전을 고정한다. 이번 수정은 v0.59.0-preview.0 release에 포함됐지만 preview 채널이다. 릴리스 페이지와 실제 gemini --version을 대조하고, 팀 배포 전에 사용하는 transport와 인증 방식을 작은 테스트 환경에서 재현한다.

둘째, CI에서는 신뢰를 편의상 켜지 않는다. 공식 문서는 headless 환경에서 --skip-trust 또는 GEMINI_CLI_TRUST_WORKSPACE=true로 우회할 수 있다고 안내한다. 이것은 오류를 없애는 옵션이지 안전성을 추가하는 옵션이 아니다. 저장소 출처와 커밋을 별도로 검증한 job에서만 쓰고, 외부 pull request에는 restricted mode와 sandbox를 유지한다.

셋째, MCP 서버는 전송 방식별로 나눈다. stdio 서버는 로컬 프로세스 실행 경로이고, SSE·Streamable HTTP 서버는 원격 네트워크와 OAuth 경로다. 이름이 같은 MCP 서버라도 위험면은 다르다. command·args·env, endpoint origin, redirect와 token endpoint를 각각 검토한다.

검토표에는 최종 주소만 적지 말고 주소가 만들어진 출처도 남긴다. 사용자가 직접 고정한 URL인지, WWW-Authenticate가 준 metadata인지, discovery 문서가 준 token endpoint인지 구분해야 한다. 같은 HTTPS 주소라도 신뢰 경로가 다르면 변경을 승인할 사람과 회귀 테스트가 달라진다. 설정을 합친 뒤의 결과만 저장하면 어느 입력이 실행 권한을 넓혔는지 되짚기 어렵다.

넷째, 회귀 테스트를 "차단 결과"로 쓴다. 원격 MCP가 loopback registration URL을 주면 OAuthSecurityError가 나는지, DNS가 사설 IP를 반환하면 요청 전에 멈추는지, restricted mode에서 repository mcpServers와 tools가 제거되는지 확인한다. 단순히 인증 성공만 테스트하면 보안 관문이 빠져도 알아채기 어렵다.

범위와 주의점

이번 release는 두 수정이 포함됐다는 사실과 코드 변경, 단위 테스트를 공개한다. 그러나 실제 공격이 관찰됐는지, 영향받은 배포가 몇 개인지, CVE가 배정됐는지는 release와 두 PR에서 확인되지 않는다. 그래서 이를 "악용된 취약점"이나 "전체 MCP 보안 해결"로 부르면 근거보다 세다.

DNS 조회 뒤 연결 시점까지 주소가 바뀌는 모든 형태를 이 글만으로 완전히 배제할 수도 없다. PR은 비동기 DNS 해석 결과를 검사한다고 설명하고 테스트를 추가했지만, 이 검토에서는 별도 공격 환경을 만들어 독립 재현하지 않았다. 또한 Trusted Folders 기능은 공식 문서상 기본 비활성화다. 새 fail-closed 경로가 들어갔다고 해서 모든 사용자의 폴더 신뢰 기능이 자동으로 켜지는 것은 아니다.

그래도 설계 원칙은 분명하다. 외부 문자열을 네트워크 요청으로 바꾸기 직전에 목적지를 다시 검증하고, 저장소 설정을 실행 구성으로 바꾸기 직전에 신뢰 판정을 다시 적용해야 한다. 정책 문구보다 마지막 fetch와 child process 생성 앞의 검사가 더 강한 증거다.

참고 자료

  • https://github.com/google-gemini/gemini-cli/releases/tag/v0.59.0-preview.0
  • https://github.com/google-gemini/gemini-cli/pull/29081
  • https://github.com/google-gemini/gemini-cli/pull/29099
  • https://geminicli.com/docs/cli/trusted-folders/
  • https://geminicli.com/docs/tools/mcp-server/
  • https://www.rfc-editor.org/rfc/rfc9728.html#section-7.7
  • https://www.rfc-editor.org/rfc/rfc8414.html

댓글

댓글 쓰기

이 블로그의 인기 게시물

체크아웃은 분리됐는데 Git 상태는 공유된다: Codex 0.154 worktree의 세 경계

이미지
1. --worktree 가 해결하는 충돌은 무엇인가 에이전트 두 개가 같은 저장소에서 동시에 파일을 고치면 가장 먼저 부딪히는 것은 모델이 아니다. 한쪽이 바꾼 작업 트리와 인덱스를 다른 쪽이 읽고, 테스트 산출물이 섞이고, 아직 정리하지 않은 변경을 다음 작업이 자기 입력으로 오해한다. OpenAI는 GitHub 기준 2026년 9월 9일 22:35 UTC, 한국 시각 10일 07:35에 공개한 Codex 0.154.0에 실험적 managed worktree 기능을 넣었다. 새 실행이나 기존 세션의 fork를 --worktree 로 시작할 수 있고, TUI에서는 /worktree 로 새 대화 또는 현재 대화의 fork를 별도 체크아웃에 둘 수 있다. 공식 릴리스 설명은 이를 "isolated checkouts"라고 부른다. 다만 이 표현을 저장소 전체와 외부 환경까지 격리한다는 뜻으로 읽으면 곤란하다. Git worktree가 분리하는 것은 체크아웃의 파일과 작업별 관리 상태다. Git 공식 문서에 따르면 연결된 worktree는 HEAD , index 같은 파일을 따로 갖지만 나머지 저장소 데이터는 공유한다. 따라서 같은 소스 파일을 동시에 편집하는 충돌은 줄일 수 있어도, 같은 원격 브랜치에 push하거나 같은 배포·테스트 데이터베이스를 건드리는 충돌까지 사라지지는 않는다. 그림 1. Codex 0.154 managed worktree는 체크아웃 생성과 thread 소유권을 연결한다. binding 전 실패 시 체크아웃을 보존한다. 출처: github.com/openai/codex/releases/tag/rust-v0.154.0 . 2. Codex는 새 체크아웃을 어떻게 만든다 0.154.0 태그가 가리키는 커밋의 codex-rs/worktree/src/lib.rs 를 보면 생성 순서가 꽤 보수적이다. 먼저 현재 HEAD 를 commit SHA로 확정한다. 그 SHA에서 git worktree add --detach --...
자세한 내용 보기

잠근 작업이 커밋 뒤 다시 나온다: PostgreSQL 에이전트 큐의 소유권 설계

이미지
1. 잠금은 작업을 소비했다는 기록이 아니다 에이전트 작업자를 여러 개 띄웠다. 각 작업자는 PostgreSQL에서 FOR UPDATE SKIP LOCKED 로 작업 하나를 가져온다. 다른 작업자가 잡은 행을 기다리지 않으니 병렬 처리도 잘되는 것처럼 보인다. 그런데 커밋한 뒤 같은 작업이 다시 나온다면 무엇이 빠진 걸까? 핵심은 행을 잠갔다는 사실과 작업을 맡았다는 상태가 서로 다르다 는 점이다. PostgreSQL 공식 문서는 행 잠금이 트랜잭션 종료 때 풀린다고 설명한다. SKIP LOCKED 는 지금 즉시 잠글 수 없는 행을 건너뛰는 옵션이지, 그 작업을 영구히 큐에서 제거하는 명령이 아니다. 공식 PostgreSQL 18.0 소스의 회귀 테스트에도 이 차이가 드러난다. 상태를 바꾸지 않고 조회만 하는 순서에서 세션 A가 작업 1을 잠그면 B는 작업 2를 받는다. A가 커밋한 뒤 B가 다시 조회하면 작업 1이 나온다. 프로젝트가 저장한 기대 출력과 별도로, 이번 글에서는 PostgreSQL 16.2의 격리된 로컬 DB 에서도 이 순서를 실제 확인했다. 문서와 고정 소스는 18 계열, 직접 실행한 엔진은 16.2다. 두 버전을 같은 실험으로 섞거나 최신 버전의 성능 측정이라고 부르지 않는다. 그림 1. 잠금이 해제돼도 작업 상태가 그대로면 같은 작업이 다시 선택된다. 공식 18.0 기대 출력과 별도 16.2 로컬 확인에 근거한 자체 도식. 출처: www.postgresql.org/docs/18/sql-select.html . 조회 결과가 0행일 때도 해석에 주의해야 한다. 모든 후보가 다른 작업자에게 잠겨 있으면 SKIP LOCKED 는 아무것도 반환하지 않을 수 있다. 로컬 확인에서는 일반 조회로 보이는 행이 2개인데 잠금 건너뛰기 조회는 0행이었다. 따라서 “지금 가져올 작업이 없다”와 “큐 자체가 비었다”는 같은 말이 아니다. 공식 문서 역시 이 옵션이 일반적인 일관된 조회에는 적합하지 않고, 큐와 비슷한 테이블의 여러 소비자 사이 경합을...
자세한 내용 보기

코딩 에이전트는 API 문서보다 AGENTS.md를 먼저 읽었다

이미지
코딩 에이전트를 위한 문서를 만든다고 하면 보통 API 레퍼런스나 상세한 개발 가이드부터 떠올린다. 그런데 실제 에이전트의 작업 기록을 분석한 연구에서는 다른 문서가 훨씬 자주 등장했다. AGENTS.md , CLAUDE.md 같은 지시 파일과 계획·작업 노트였다. 2026년 8월 공개된 논문 From Agent Behaviour to Agent-Friendly Documentation 은 공개된 코딩 에이전트 세션과 풀 리퀘스트를 이용해 에이전트가 어떤 문서를 읽고 쓰는지 조사했다. 연구진이 분석한 데이터는 다음과 같다. SWE-chat의 파싱 가능한 세션 557개 개발 이벤트 94,813개 문서 관련 이벤트 3,033개 AIDev의 에이전트 풀 리퀘스트 33,097개 파일·커밋 단위 변경 기록 690,260개 에이전트가 가장 자주 만진 문서 문서 상호작용에서 가장 큰 비중을 차지한 것은 에이전트 지시 파일이었다. 문서 유형 이벤트 수 비중 에이전트 지시 파일 1,074 35.4% 계획·작업 노트 760 25.1% 작업 및 요구사항 문서 301 9.9% 설정 문서 205 6.8% README 197 6.5% API 레퍼런스 40 1.3% 지시 파일과 작업 노트를 합하면 전체 문서 상호작용의 60.5%다. API 레퍼런스는 1.3%에 그쳤다. 지시 파일이 API 레퍼런스보다 약 27배 많이 관찰된 셈이다. 코딩 에이전트의 문서 관련 이벤트 분포. 지시 파일과 계획·작업 노트가 전체의 60.5%를 차지했다. 출처: Gao & Chen, arXiv:2608.20195v1 . 이 수치를 "API 문서는 필요 없다"고 해석하면 곤란하다. 연구가 추적한 것은 저장소 안에서 명시적으로 열린 파일이다. 웹 문서, 모델이 이미 학습한 지식, 코드 주석, 런타임이 자동으로 주입한 문맥은 잡히지 않는다. 정확한 결론은 코딩 에이전트가 저장소 안에서 작업할 ...
자세한 내용 보기