argocd-mcp 무인증 HTTP 노출(CVE-2026-82456)｜영향 범위와 대응

argocd-mcp는 Model Context Protocol 클라이언트가 Argo CD 기능을 호출할 수 있도록 연결하는 서버입니다. CVE-2026-82456은 이 연결 지점에서 ‘누가 요청을 보냈는가’와 ‘서버가 Argo CD에 어떤 권한으로 요청하는가’가 분리되지 않은 문제입니다. 공식 권고에 따르면 0.8.0의 HTTP 전송은 모든 네트워크 인터페이스에서 요청을 받을 수 있고, ARGOCD_API_TOKEN이 환경변수에 설정된 경우 외부 호출자가 별도 인바운드 자격증명을 제시하지 않아도 MCP 세션을 만들 수 있습니다. 서버는 이후 도구 요청을 운영자가 저장한 Argo CD 토큰으로 실행합니다.

따라서 단순한 관리 포트 노출로 보기는 어렵습니다. 리스너에 도달한 요청이 저장 토큰의 권한을 빌려 Argo CD API로 전달되고, 그 권한이 다시 대상 Kubernetes 클러스터의 리소스 변경으로 이어질 수 있습니다. 공식 프로젝트 권고는 0.8.0을 영향 버전으로, 0.9.0을 수정 버전으로 표시하며 심각도를 Critical, CVSS 3.1 기준 10.0으로 평가했습니다. 운영자는 패키지 버전만 바꾸는 데서 멈추지 말고 리스너 범위, 호출자 인증, Argo CD 토큰 권한을 하나의 신뢰 경계로 점검해야 합니다.

노출 경로의 핵심

공격 조건의 출발점은 HTTP 또는 SSE 전송을 네트워크에서 접근할 수 있도록 실행한 0.8.0 인스턴스입니다. 공식 권고는 HTTP 리스너가 호스트를 지정하지 않은 app.listen(port) 형태로 시작되어 모든 인터페이스에 바인딩되고, 사용자 정의 Express 애플리케이션에 Host 검증이 적용되지 않는다고 설명합니다. 같은 환경에서 ARGOCD_API_TOKEN 또는 토큰 레지스트리 경로가 설정되면 저장된 값은 본래 Argo CD로 나가는 요청에 쓰이는 자격증명인데도 호출자 인증처럼 작동할 수 있습니다. 외부 요청이 리스너에 도달할 수 있고 별도의 앞단 인증이 없다면 신뢰 경계가 서버 프로세스 안에서 무너집니다.

이 문제는 인터넷 공개에만 한정되지 않습니다. 사내 개발망, VPN 구간, 공유 테스트망, 쿠버네티스 노드 포트처럼 다른 사용자나 워크로드가 접근 가능한 경로도 점검 대상입니다. 공식 권고는 Origin과 Host 검증 부재 때문에 DNS 리바인딩을 통한 로컬 리스너 접근 가능성도 설명합니다. 방화벽에서 공인 인터넷을 막았다는 사실만으로 끝내기보다 실제 프로세스의 바인딩 주소, 컨테이너 포트 게시, 서비스 타입, 인그레스와 리버스 프록시 설정을 차례로 확인해야 합니다.

저장 토큰이 만드는 권한 확장

argocd-mcp의 도구는 Argo CD 애플리케이션과 클러스터 상태를 읽은 기능뿐 아니라 애플리케이션 생성, 수정, 삭제, 동기화, 프루닝과 리소스 작업을 포함합니다. MCP_READ_ONLY가 활성화되지 않은 기본 흐름에서 쓰기 권한 토큰을 보관했다면, 호출자는 자신의 저장소와 대상 클러스터·네임스페이스를 지정한 Application을 만들고 동기화를 요청할 수 있습니다. 실제 영향은 저장된 토큰과 Argo CD 프로젝트 정책이 허용하는 범위에 따라 달라지지만, 문제의 핵심은 호출자가 토큰 자체를 알 필요 없이 서버가 대신 권한이 부여된 요청을 수행한다는 점입니다.

읽기 권한만 가진 토큰도 무시할 수 없습니다. 애플리케이션, 클러스터, 관리 리소스, 로그와 이벤트처럼 배포 구조와 운영 상태를 보여주는 정보가 노출될 수 있습니다. 반대로 쓰기 권한 토큰과 폭넓은 기본 프로젝트가 결합하면 저장소·배포 대상·리소스 종류가 넓게 열릴 수 있습니다. 그래서 영향 판단은 ‘argocd-mcp가 떠 있는가’에서 끝나지 않고, 전송 모드와 접근 경로, 환경변수 또는 토큰 레지스트리, MCP_READ_ONLY, 연결된 Argo CD 계정, 프로젝트의 sourceRepositories·destinations·clusterResourceWhitelist를 한 줄로 이어서 확인해야 합니다.

수정 버전과 방어 경계

공식 권고가 지정한 수정 버전은 0.9.0입니다. 배포 이미지 태그나 package.json만 보고 판단하지 말고, 잠금파일과 실제 실행 컨테이너 또는 프로세스에서 로드한 버전을 확인해야 합니다. CI/CD가 태그를 고정하지 않았거나 프라이빗 레지스트리에 이전 이미지를 캐시한 환경에서는 배포 선언과 실행 바이너리가 다를 수 있습니다. 업데이트 후에는 새 프로세스가 0.9.0 이상으로 기동했는지, 기존 Pod와 작업 노드에 0.8.0이 남지 않았는지, 롤백용 이미지가 자동으로 다시 배포되지 않는지 검증하는 절차가 필요합니다.

버전 교체와 함께 네트워크 경계를 좁혀야 합니다. 로컬 전용 사용이라면 127.0.0.1에 바인딩하고, 원격 사용이 필요하면 관리망·서비스 메시·인증 프록시처럼 호출자를 식별하는 경로 뒤에 둡니다. 저장된 ARGOCD_API_TOKEN은 서버가 Argo CD로 요청할 때 사용하는 아웃바운드 자격증명이며, 외부 호출자가 누구인지 증명하는 인바운드 자격증명과 목적이 다릅니다. 두 역할을 같은 값으로 취급하지 말고 별도의 호출자 인증, 허용 Host와 Origin, TLS, 네트워크 접근제어를 적용해야 합니다.

운영 환경 점검 순서

1. 실행 중인 argocd-mcp 인스턴스와 컨테이너 이미지에서 0.8.0 사용 여부를 확인합니다.
2. 프로세스의 바인딩 주소, 게시 포트, Kubernetes Service·Ingress, 프록시와 방화벽 경로를 기록합니다.
3. 0.9.0 이상으로 교체한 뒤 모든 복제본과 작업 노드가 새 버전을 실행하는지 확인합니다.
4. 인바운드 호출자 인증을 저장된 Argo CD 토큰과 분리하고 Host·Origin 제한을 적용합니다.
5. MCP_READ_ONLY와 전용 Argo CD 프로젝트·최소 권한 토큰을 적용한 뒤 읽기·쓰기 도구 노출을 재검증합니다.

긴급 완화가 필요한 동안에는 외부에서 리스너로 이어지는 경로를 차단하고 프로세스를 로컬 또는 신뢰 관리망에 한정하는 것이 우선입니다. 동시에 사용 중인 토큰의 권한을 낮추고, 쓰기 작업이 필요하지 않은 환경에서는 MCP_READ_ONLY를 적용합니다. 이미 노출 경로가 있었던 서버는 Argo CD 감사 로그, MCP 서버 접근 로그, 애플리케이션 생성·수정·동기화 기록을 같은 시간대에 맞춰 검토해야 합니다. 토큰 교체가 필요하다면 새 값 배포와 이전 값 폐기를 분리 기록해 공백이나 중복 권한이 생기지 않도록 합니다.

컨테이너 오케스트레이션 환경에서는 Service와 Ingress만 보는 점검으로 부족할 수 있습니다. hostNetwork, hostPort, NodePort, 포트 포워딩, 개발자용 터널과 서비스 메시의 사이드카가 리스너를 다른 네트워크에 노출할 수 있기 때문입니다. 네임스페이스별 NetworkPolicy와 클라우드 방화벽이 실제 트래픽 방향에서 적용되는지 확인하고, 정상 클라이언트가 사용하는 출발지와 포트를 기준으로 허용 규칙을 다시 작성합니다. 배포 자동화에는 0.9.0 미만 이미지 차단, 필수 인바운드 인증과 읽기 전용 기본값을 정책 검사로 넣어 이전 구성이 되살아나는 것을 막은 편이 좋습니다.

업데이트 이후 검증

업데이트 완료 판정은 패키지 설치 성공이 아니라 신뢰 경계가 복구됐는지로 내려야 합니다. 승인되지 않은 네트워크 위치에서 리스너에 도달하지 못하는지, 허용된 경로에서도 인바운드 자격증명 없이는 세션이 생성되지 않는지, Origin과 Host 정책이 의도대로 작동하는지 확인합니다. 이어서 정상 MCP 클라이언트가 필요한 읽기 작업을 수행하는지, 쓰기 도구는 승인된 계정과 프로젝트 범위 안에서만 동작하는지 점검합니다. 이 과정은 취약점 재현이 아니라 정상 운영과 접근 통제가 함께 유지되는지를 확인하는 방어 검증입니다.

장기적으로는 MCP 서버를 단순 개발 보조 도구가 아니라 클라우드 관리 권한을 중계하는 서비스 계정 워크로드로 분류하는 편이 안전합니다. 자산 목록에는 패키지 버전, 전송 모드, 리스너 주소, 앞단 인증, 저장 토큰의 소유자와 권한, 연결된 Argo CD 프로젝트를 함께 남깁니다. 또한 운영 로그에서 새로운 Application 생성, 저장소 주소 변경, 동기화와 프루닝 같은 고위험 작업을 구분해 경보화하면 네트워크 노출과 권한 오용을 한 흐름으로 추적할 수 있습니다. 이번 대응의 목표는 0.8.0을 제거하는 데 그치지 않고 호출자·중계 서버·Argo CD·클러스터 사이의 권한 경계를 다시 분리하는 것입니다.