Git 11월 보안 업데이트: 재귀 clone 위험과 IDE·CI의 실제 버전 점검

개발 PC·CI 서버·앱에 포함된 Git을 함께 점검하는 개념도. AI 생성 이미지.

Git 보안 업데이트를 설치한 뒤 터미널에서 버전 한 번 확인하고 끝내기 쉽다. 하지만 IDE가 별도 Git을 사용하거나 CI 컨테이너에 이전 실행 파일이 남아 있으면, 실제 저장소를 처리하는 프로그램은 그대로일 수 있다.

Git 프로젝트는 November 10, 2026 여섯 가지 취약점을 수정한 보안 릴리스를 공개했다. 이번 점검의 핵심은 신뢰하지 않는 저장소·패치·가져오기 데이터를 처리하는 Git을 찾아 수정 여부를 확인하는 것이다. 아래는 November 14, 2026 기준 공식 자료를 대조한 운영 점검 가이드다. 공식 발표

1. 재귀 clone 외의 입력 경로도 확인한다

대표 이슈인 CVE-2026-111760은 공격자가 제어하는 저장소를 재귀적으로 복제할 때 코드 실행으로 이어질 수 있다. Git 공식 권고는 일반적인 호스팅 사이트가 아닌 공격자 측 저장소를 전제로 설명하며, --recurse-submodules 사용 시 발생할 수 있다고 명시한다. 따라서 “어떤 저장소든 clone만 하면 감염된다”로 확대해서 설명하면 안 된다. 그렇다고 하위 모듈을 쓰지 않는다는 이유로 이번 릴리스 전체를 건너뛰어서도 안 된다. Git 보안 권고

다른 수정 항목은 다음 입력 경로와 관련된다.

참조 처리, CVE-2026-113408: 서버가 제공한 unborn HEAD의 경로를 통해 의도하지 않은 파일에 쓰기가 일어날 수 있다.

태그 병합, CVE-2026-114467: 서명이 여러 개 포함된 입력을 처리하다 스택 메모리가 손상될 수 있다.

바이너리 패치, CVE-2026-114469: 압축된 패치가 크게 풀릴 때 경계 밖 읽기로 Git이 중단될 수 있다.

대규모 병합, CVE-2026-105437: 병합 결과 크기 계산의 오버플로가 힙 메모리 손상으로 이어질 수 있다.

fast-import 입력, CVE-2026-114466: 파일 접근을 허용하는 일부 기능이 기본 차단 대상에서 빠져 있었다.

이 목록은 각 기능을 모두 같은 공격으로 취급하기 위한 것이 아니다. 팀의 자동화가 어떤 입력을 처리하는지 빠짐없이 찾기 위한 분류다. 예를 들어 PR 병합 서비스와 저장소 가져오기 서비스는 단순 checkout 작업과 점검 대상이 다르다. Git 2.50.2 상세 릴리스 노트

2. 수정 버전과 배포판 백포트를 구분한다

Git 2.56.1 릴리스 노트가 명시하는 수정 버전은 2.56.1, 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3, 2.50.2다. 해당 유지보수 계열의 수정 릴리스와 비교해야 한다. 모든 환경에 “2.56.1 이상”이라는 단일 숫자 기준만 적용하면, 수정된 이전 계열까지 미조치로 판정할 수 있다. Git 2.56.1 릴리스 노트

자료 사이의 불일치도 있다. 확인 시점에 CVE-2026-111760의 GitHub Advisory에는 Patched versions: none이 남아 있었지만, 위 태그의 릴리스 노트는 해당 CVE 수정을 명시한다. 수정 릴리스 존재 여부는 실제 릴리스 노트와 공식 발표를 함께 확인하고, Advisory의 한 필드만 읽어 “패치가 없다”고 결론 내리지 않는다.

운영체제 패키지는 한 단계 더 확인해야 한다. 배포판이 기존 버전에 보안 수정을 백포트했다면 git --version의 upstream 숫자만으로 판정할 수 없다. Red Hat도 이 때문에 버전 번호만 보는 검사에서 오탐이 생길 수 있다고 설명한다. Red Hat의 보안 백포트 설명

실무 기록에는 다음 세 가지를 묶어 남기는 편이 좋다.

실제 실행 파일의 위치와 설치 출처

전체 패키지 버전·릴리스 식별자 또는 내장 앱 버전

해당 CVE가 수정되었음을 보여 주는 공급자 공지

이는 특정 배포판이 이미 여섯 건을 모두 수정했다는 뜻이 아니다. 사용하는 OS 버전과 패키지 저장소에 맞는 공지를 별도로 대조해야 한다.

3. 실제 작업을 수행하는 환경에서 버전을 수집한다

Linux·macOS의 일반적인 셸에서는 다음 읽기 전용 명령으로 시작할 수 있다.

git --version과 git version은 같은 버전 정보를 출력한다. --build-options는 빌드 관련 진단 정보를 추가한다. 출력이 나온다는 사실은 패치 검증을 뜻하지 않는다. 이 명령은 현재 셸이 고른 Git을 식별하는 시작점이다. git-version 문서

이 세 명령은 Linux 환경에서 실행해 정상 종료를 확인했다. 취약점 재현 코드, 악성 저장소 clone, 패키지 업데이트는 실행하지 않았다. Windows에서는 사용 중인 Git의 설치 위치와 앱 설정을 별도로 확인해야 한다.

권장하는 조사 단위는 “PC 한 대”보다 “Git을 호출하는 실행 경로”다.

개발 셸: 사용자별 PATH와 설치 관리자가 다른지 확인한다.

IDE·데스크톱 앱: 시스템 Git을 선택했는지, 자체 포함 Git을 사용하는지 설정과 공급자 릴리스 정보를 확인한다.

셀프 호스티드 CI: 관리자 로그인 셸이 아니라 실제 러너 계정·작업 컨테이너에서 수집한다.

저장소 처리 서비스: 외부 저장소 가져오기, 병합 검사, 패치 적용을 수행하는 워커를 따로 등록한다.

이는 공식 수정 범위를 운영 자산에 적용하기 위한 점검 제안이다. 새 이미지가 만들어졌더라도 기존 워커가 계속 이전 이미지를 쓰는지 확인해야 한다. 로그를 공유할 때는 사용자 이름이 포함된 로컬 경로 등 불필요한 정보는 가린다.

4. GitHub 서비스의 조치와 내 클라이언트의 조치를 분리한다

11월 10일 공식 발표는 github.com과 GitHub Enterprise Cloud 계열에 수정 사항을 배포했다고 설명한다. GitHub Enterprise Server의 수정 릴리스도 제시한다. 반면 Desktop·Copilot 앱, Actions·Codespaces의 포함 Git은 후속 배포 예정으로 표현되어 있다. 이 발표만으로 현재 모든 앱과 러너가 이미 수정되었다고 주장할 수는 없다. 실제 사용 중인 제품의 최신 릴리스와 실행 환경을 확인해야 한다. GitHub 사용자 보호 조치

즉시 업데이트할 수 없다면 신뢰하지 않는 서버·저장소의 재귀 clone을 피하고, 외부 입력의 병합·바이너리 패치·fast-import 처리를 제한하는 것이 공식 임시 권고다. 이 제한은 패치의 대체 수단이 아니다.

팀의 완료 기준은 다음처럼 정리할 수 있다.