Michael Johnson터미널의 Git을 업데이트했더라도 작업이 끝난 것은 아닙니다. 일부 애플리케이션과 빌드 환경은 자체 복사본을 실행할 수 있습니다. 2026년 11월 10일, Git 프로젝트는 재귀적 복제 중 코드 실행부터 병합 중 메모리 손상까지 이어질 수 있는 취약점 6건의 수정 사항을 공개했습니다. 따라서 셸에서 git --version을 실행한 결과만 확인할 것이 아니라, 저장소나 그 내용을 처리하는 모든 환경을 점검해야 합니다.
이번 업데이트의 변경 사항
수정 사항은 Git 2.56.1에 포함됐으며, 지원되는 브랜치인 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3, 2.50.2에도 백포트됐습니다. 이번 업데이트는 경로, 링크, 서명, 바이너리 패치, 병합, 가져오기 스트림 처리 등 Git의 여러 영역에서 발견된 문제 6건을 해결합니다. GitHub는 11월 10일 취약점 분석과 업데이트 권고를 공개했고, Git 2.56.1 릴리스 노트에는 이번 업데이트에서 수정한 CVE가 나열돼 있습니다.
실무적으로는 세 곳에서 사용하는 Git을 업데이트해야 합니다. 개발자 컴퓨터, 자동화 환경, 자체 Git 빌드를 포함하는 애플리케이션입니다. 마지막 항목은 놓치기 쉽습니다. 시스템 패키지를 업데이트해도 모든 클라이언트나 빌드 이미지에 포함된 버전이 자동으로 바뀌지는 않습니다.
재귀적 clone에 주목해야 하는 이유
가장 이해하기 쉬운 공격 흐름은 신뢰할 수 없는 저장소를 재귀적으로 복제하는 상황에서 시작됩니다. 경로 길이가 잘리는 문제 때문에 지나치게 긴 경로가 한 이름으로 검사를 통과한 뒤, 디스크에는 잘린 이름으로 기록될 수 있었습니다. Git에서 설명한 시나리오에서는 공격자가 서브모듈의 .git 파일을 심볼릭 링크로 바꿔 악성 설정이나 훅이 들어 있는 디렉터리를 가리키게 할 수 있었습니다. 이후 Git이 해당 항목에 접근하면 공격자가 지정한 코드가 실행될 수 있었습니다.
실무상 중요한 점은 이 공격에 특별히 조작된 저장소와 그에 해당하는 작업이 필요하다는 것입니다. 외부 출처의 프로젝트를 --recurse-submodules 옵션으로 자주 복제하는 팀은 클라이언트와 자동화 환경을 우선 업데이트해야 합니다. 수정된 버전은 경로 길이가 잘리기 전에 지나치게 긴 경로를 거부합니다.
Git이 신뢰할 수 없는 데이터를 처리하는 다른 지점
Git protocol v2를 통해 빈 저장소를 복제할 때 발생할 수 있는 문제도 있었습니다. 서버가 디렉터리 탐색 요소가 포함된 브랜치 이름으로 HEAD 참조를 보낼 수 있었고, 이후 브랜치를 갱신하는 과정에서 예상된 참조 디렉터리 밖에 파일이 기록될 수 있었습니다. 수정된 Git 버전은 이런 대상과 프로토콜을 통해 받은 다른 참조 이름을 검사합니다.
병합과 패치 작업에도 별도의 취약점이 있었습니다. 서명을 처리할 때 고정 배열은 최대 두 개의 서명만 예상했습니다. 서명이 더 많이 포함된 메시지를 조작하면 배열 경계를 벗어나 기록해 메모리가 손상될 수 있었습니다. 바이너리 패치를 적용할 때는 압축 전 데이터 크기를 기준으로 검사했지만, 압축된 데이터는 풀린 뒤 훨씬 커질 수 있습니다. 이제 Git은 데이터를 처리하기 전에 지정된 압축 해제 후 크기를 확인합니다.
대규모 병합도 필요한 버퍼 크기를 계산하는 과정에서 오버플로를 일으킨 뒤 버퍼 경계 밖에 기록하게 만들 수 있었습니다. 이는 신뢰할 수 없는 내용을 병합하는 호스팅 서비스와 애플리케이션에도 해당됩니다. 마지막으로 git fast-import의 세 가지 기능은 입력 스트림의 명령에 제한을 받게 됐습니다. rewrite-submodules-from과 rewrite-submodules-to는 임의의 파일을 읽을 수 있었고, export-pack-edges는 파일을 생성하거나 기존 파일에 데이터를 덧붙일 수 있었습니다. 이제 --allow-unsafe-features 플래그를 명시하지 않으면 이 기능들이 차단됩니다. 이 플래그는 신뢰할 수 있는 스트림 생성기에만 사용해야 합니다.
별도 Git 복사본을 찾아볼 곳
개발자는 우선 Git이 실행되는 위치를 목록으로 정리하면 됩니다. 터미널에서 버전을 확인하고 IDE와 데스크톱 Git 클라이언트의 기본 업데이트 확인 기능을 사용하세요. 그런 다음 clone, merge, 바이너리 패치 적용 또는 fast-import 실행을 수행하는 CI 이미지, 컨테이너, 러너, 서버 작업을 점검하세요. 호스트에 최신 Git이 설치돼 있다는 사실만으로 애플리케이션이 그 버전을 사용한다고 보장할 수는 없습니다.
조직에서는 원본 이미지뿐 아니라 이미 배포된 실행 환경도 확인하는 것이 좋습니다. 상시 가동되는 러너나 내부 서비스는 기본 이미지가 업데이트된 뒤에도 오래된 바이너리를 보유하고 있을 수 있습니다. GitHub는 GitHub Enterprise Server의 수정 버전으로 3.19.15, 3.20.11, 3.21.9, 3.22.4를 안내했습니다. 또한 github.com과 GitHub Enterprise Cloud에 데이터 레지던시 옵션을 포함해 수정 사항을 이미 배포했다고 밝혔습니다. 수정된 Git을 포함한 GitHub Desktop과 GitHub Copilot 앱 릴리스는 조율 중이며, Codespaces와 GitHub Actions용 수정 버전도 아직 배포될 예정입니다.
업데이트 전 위험 줄이기
수정을 즉시 적용할 수 없다면 신뢰할 수 없는 데이터와의 접촉을 일시적으로 제한하세요. 신뢰할 수 있는 서버에서만 저장소를 복제하고, 검증되지 않은 프로젝트는 재귀적으로 복제하지 말며, 해당 프로젝트의 내용을 병합하거나 전달받은 바이너리 패치 또는 fast-import 스트림을 적용하지 마세요. 이러한 조치는 구체적인 취약점 악용 시나리오에 노출될 가능성을 낮추지만 업데이트를 대체하지는 않습니다.
실무적으로 핵심은 간단합니다. 프로그램이 실제로 Git을 실행하는 위치에서 수정 사항을 찾아야 합니다. 터미널 명령은 그런 위치 중 하나일 뿐이며, 개발 클라이언트와 CI, 저장소 처리 서비스도 각각 점검해야 합니다.
