docker-credential-acr-env는 Azure Container Registry(ACR)를 쓰는 환경에서 자격증명을 대신 공급하는 credential helper입니다. 이 헬퍼가 '어느 호스트가 ACR인가'를 가르는 방식에 결함이 있습니다. 호스트명 안에 .azurecr.io라는 문자열만 들어 있으면 공격자가 세워둔 서버도 유효한 ACR로 통과하고, 통과한 호스트명이 그대로 토큰 교환 호출에 쓰입니다. 그 결과 Azure AD(AAD) 액세스 토큰이 공격자 통제 호스트로 전송됩니다. 업스트림 이슈와 Go 취약점 데이터베이스가 같은 원인과 결과를 지목하고 있으므로, 이 헬퍼를 설치한 기록이 있는 조직은 '토큰이 어떤 호스트로 나가도록 허용하고 있는가'부터 다시 확인할 필요가 있습니다.
개요
확인된 내용은 좁고 분명합니다. 헬퍼는 레지스트리 호스트명이 ACR인지 판별할 때 앵커(anchoring) 없이 .azurecr.io 문자열의 포함 여부만 검사하는 패턴을 사용합니다. 그래서 evil.azurecr.io.attacker.com처럼 이름 중간에 .azurecr.io를 품은 공격자 통제 호스트도 유효한 ACR 레지스트리로 분류됩니다. 검사를 통과한 호스트명은 토큰 교환(exchange) 클라이언트 구성에 그대로 사용되고, 헬퍼는 그 호스트의 oauth2/exchange 엔드포인트로 POST 요청을 보내며 AAD 액세스 토큰을 전송합니다. Go 취약점 데이터베이스는 이 문제를 GO-2026-6225로 등록하고 ACRCredHelper.Get이 공격자 통제 호스트로 AAD 액세스 토큰을 보낸다고 기록했습니다.
이 글이 근거로 삼는 범위는 여기까지입니다. 앵커되지 않은 호스트명 검사가 공격자 통제 호스트를 ACR로 오인하게 만들고, 그 호스트의 oauth2/exchange 엔드포인트로 AAD 액세스 토큰이 전송될 수 있다는 점이 업스트림 이슈 #21과 Go 취약점 데이터베이스 GO-2026-6225가 겹쳐 확인한 지점입니다. 유출이 실제로 성립하기 위해 필요한 나머지 조건들, 예를 들어 그 호스트로 가는 이름 해석 경로와 TLS 인증서 처리, 받는 서버가 요청자를 검증하는지 여부는 두 출처에서 확인되지 않았습니다.
아직 확인되지 않은 부분에도 선을 그을 필요가 있습니다. 정확한 취약 버전과 수정 버전 번호, 이 취약점을 가리키는 CVE 번호와의 공식 매핑, 벤더 권고문, CISA KEV 등재 여부, 실제 악용 사례, 공개 PoC의 존재는 이번에 확보된 근거에서 확인되지 않았습니다.
영향 범위
영향의 기본 단위는 docker-credential-acr-env 헬퍼의 호스트명 검증 결함이고, 점검 범위는 그 헬퍼가 설치된 실행 환경으로 넓어집니다. 헬퍼가 레지스트리 인증 경로의 자격증명 공급자로 놓여 있고, 참조되는 레지스트리 호스트명이 공격자가 준비한 이름이 될 수 있다면 자격증명이 밖으로 나가는 조건이 성립합니다.
유출되는 대상은 AAD 액세스 토큰이므로, 노출 범위는 그 토큰이 실제로 가진 권한을 넘지 않습니다. 조건별로 정리하면 다음 차이가 납니다.
- 토큰이 특정 레지스트리 접근용으로만 발급된 환경이라면, 노출은 해당 레지스트리와 그 이미지에 집중됩니다.
- 발급된 토큰이 더 넓은 권한을 담고 있다면, 레지스트리를 넘어 그 토큰이 접근할 수 있는 다른 Azure 자원으로 영향이 확장될 수 있습니다. 어느 쪽인지는 토큰 발급 구성을 확인해야 판단할 수 있습니다.
- 실행 환경에서 임의의 외부 호스트로 나가는 요청이 차단되어 있다면, 메커니즘이 존재해도 유출이 실행되지 않습니다. 이 조건이 실제 위험도를 크게 좌우합니다.
확인이 필요한 지점은 유출 지점의 위치가 아니라 헬퍼가 어떤 호스트명을 통과시키도록 설정되었느냐입니다. 헬퍼는 판별을 통과한 호스트의 oauth2/exchange로 AAD 액세스 토큰을 전송하므로, 통과 조건이 곧 유출 대상이 됩니다.
취약 버전과 수정 버전 번호가 확보된 근거에 없으므로, '특정 버전 이상이면 안전하다'고 말할 수 있는 상태가 아닙니다. 조사 첫 단계는 버전 비교가 아니라 헬퍼 사용 여부의 확인이 됩니다. 헬퍼가 어떤 종류의 실행 환경에 놓이는지, 그 환경에서 토큰이 어떤 방식으로 획득되는지는 이번에 확보된 근거에 없어 자동화 환경 특유의 노출이나 탐지 난이도는 단정하지 않습니다.
기술적 분석
호스트명 검사가 갈라지는 지점
동작은 두 단계로 나뉩니다. 첫 단계는 '이 호스트가 ACR인가'를 판별하는 검사이고, 둘째 단계는 통과한 호스트를 대상으로 토큰 교환 클라이언트를 구성하는 일입니다. 결함은 첫 단계에 있고, 그 결과는 둘째 단계에서 그대로 실행됩니다.
정규식이 앵커되지 않아 접두나 접미가 붙은 이름도 통과합니다. 즉 .azurecr.io로 끝나는 실제 ACR 호스트와 evil.azurecr.io.attacker.com처럼 중간에 같은 문자열을 심은 공격자 호스트가 검사대에서 구분되지 않습니다. 판별을 통과한 호스트명은 토큰 교환 클라이언트 구성에 그대로 사용되고, 헬퍼는 그 호스트의 oauth2/exchange 엔드포인트로 POST 요청을 보내 AAD 액세스 토큰을 전송합니다. 제공된 근거가 확인하는 범위는 여기까지이며, 토큰이 요청의 어느 부분에 담기는지 또는 받는 서버가 요청자를 검증하는지는 확인된 바 없습니다.
악용 가능성에 대한 판단
기술적 악용 메커니즘은 업스트림 이슈와 Go 취약점 데이터베이스로 교차 확인되었습니다. 반면 실제 악용 사례와 공개 PoC는 조사 범위에서 발견되지 않았습니다. 두 사실의 방향은 다릅니다.
확인된 두 출처가 그리는 경로는 판별 실패와 그 호스트로의 토큰 전송까지이며, 이 범위 안에서 보면 유출 경로가 DNS 이름 하나로 만들어지는 단순한 구조입니다. 그래서 기술 분석은 악용 난이도를 낮게 평가하는 것이 타당하다고 판단합니다. 다만 그 평가는 기법이 얼마나 간단한가에 대한 것이지, 공격이 실제로 일어나고 있다는 증거는 아니며, 이름 해석이나 TLS 경로처럼 유출이 실제로 도달하는 데 필요한 개별 전제조건은 출처에서 확인되지 않았습니다. KEV 등재와 실제 악용 여부가 확인되지 않은 현 상태에서는 '지금 활발히 악용 중'이라는 표현도 '주목받지 못하는 문제'라는 표현도 근거를 잃습니다. 따라서 판단은 '단순한 구조의 유출 경로가 존재하고, 광범위한 악용 신호는 아직 관측되지 않음'으로 두는 편이 현재 자료에 맞습니다.
탐지 신호로 볼 수 있는 것
공식 탐지 지침이 확인되지 않았으므로, 아래는 메커니즘에서 도출한 조건부 관찰점입니다.
- 로그에
.azurecr.io를 포함하면서도 실제 ACR 호스트 형식이 아닌 이름으로 나간oauth2/exchangePOST 요청 흔적이 남는지 확인합니다. - 헬퍼가 놓인 환경이 예상치 못한 외부 호스트로 연결을 여는지, 아웃바운드 흐름을 모니터링합니다.
두 항목 모두 메커니즘을 거꾸로 들여다본 관찰점일 뿐이며, 실제로 어떤 로그와 네트워크 흐름이 남는지는 이번에 확보된 근거로 확인되지 않았습니다. 유출이 의심되는 상황에서의 토큰 처리나 관련 계정 점검 절차에 관한 공식 지침도 제공된 근거에 없어 이 글에서는 다루지 않습니다.
대응 방안
우선순위를 정하는 순서
수정 버전이 확인되기 전까지 대응 순서는 버전 번호가 아니라 다음 질문에서 갈립니다. 우리 환경에 이 헬퍼가 있는가, 그 헬퍼가 참조할 수 있는 레지스트리 호스트명은 무엇인가, 헬퍼가 임의의 외부 호스트로 요청을 보낼 수 있는가.
- 이미지 빌드와 배포 자동화를 포함한 실행 환경에서
docker-credential-acr-env사용 여부를 먼저 확인합니다. - 헬퍼가 쓰이는 환경의 레지스트리 호스트명 설정과 credential helper 구성을 점검합니다.
- 헬퍼가 임의의 외부 호스트로 요청을 보낼 수 없도록 이그레스(egress) 제한 적용을 검토합니다.
구조적인 대응
- 앵커된 호스트명 검증이 적용된 수정 버전으로 업그레이드합니다. 정확한 수정 버전 번호는 확인이 필요하므로, 벤더 안내가 나오기 전까지는 '확인 후 적용'을 전제로 계획합니다.
- 임시 완화로서 헬퍼 사용을 중단하고 다른 자격증명 방식으로 전환하는 방법을 검토할 수 있습니다. 유출 지점 자체를 없애는 방향이라 판별 로직의 리스크를 우회합니다.
- 레지스트리 접근을 허용된 ACR 호스트로 제한하는 네트워크 정책을 유지합니다. 위 두 조치가 들어가기 전에도 유효한 방어선입니다.
남은 과제
정확한 취약 및 수정 버전, CVE 공식 기록과의 매핑, 벤더 권고문, CISA KEV 등재와 실제 악용 여부가 후속 확인 항목입니다. 버전 정보와 공식 패치 안내가 없는 현 단계의 조치 목록은 메커니즘에서 도출한 조건부 권고이며, 공식 지침을 대체하지 않습니다.
참고자료
- Azure AD token disclosed to attacker-controlled hosts: ACR hostname pattern is unanchored (issue #21)
- GO-2026-6225: Unanchored regex in docker-credential-acr-env sends AAD token to attacker hosts
함께 읽으면 좋은 글
- CVE-2026-121419: SurrealDB MCP 세션 탈취 가능성 점검
- CVE-2026-110447: Collabora Online 내장 CODE 서버 OS 명령 주입, KEV 등재와 26.4.303 미만 영향 범위
- CVE-2026-121458: Instatic AI/MCP 콘텐츠 읽기 도구의 인가 누락, 무엇이 드러나나
본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.
댓글 (0)
댓글을 작성하려면 로그인이 필요합니다.
로그인아직 댓글이 없습니다.
첫 번째 댓글을 작성해보세요!