핵심 POINT
Git 프로젝트는 2026년 11월 10일 취약점 6건을 고친 보안 업데이트를 내놓았습니다. 가장 중요한 CVE-2026-111760은 악의적으로 만든 저장소를 서브모듈까지 재귀 복제할 때 공격자가 준비한 코드가 실행될 수 있는 취약점입니다.
모든 저장소 복제가 위험한 것은 아닙니다. 공식 발표가 설명한 코드 실행 조건은 악성 저장소를 재귀 복제하는 경우입니다. 나머지 5건은 경로 탐색, 메모리 손상, 파일 접근 문제로 각각 영향이 다릅니다.
수정 버전은 Git 2.56.1이고, 2.55.1부터 2.50.2까지 이전 계열에도 제공됩니다. 개발자 PC뿐 아니라 CI/CD 서버, 컨테이너 이미지, Git을 내장한 개발 프로그램까지 함께 확인해야 합니다.
Git 저장소 복제만 해도 해킹될까? 신규 취약점 6건과 보안 업데이트 확인법
외부 오픈소스를 내려받아 쓰거나, 빌드 서버가 소스코드를 자동으로 가져오는 일은 개발 조직에서 하루에도 수없이 반복됩니다. 이 평범한 작업 하나에 위험이 숨어 있다면 개발자 PC뿐 아니라 배포 파이프라인까지 영향을 받을 수 있습니다.
Git 프로젝트는 2026년 11월 10일 새 버전을 내놓고, 악성 저장소를 재귀 복제할 때의 코드 실행을 포함한 취약점 6건을 고쳤다고 밝혔습니다. GitHub 블로그가 같은 날 정리한 공식 발표에는 취약점별 발생 조건과 수정 버전, GitHub 서비스의 조치 현황이 담겨 있습니다. 이번 글에서는 이 발표를 바탕으로 코드 실행이 가능해지는 조건과 원리, 개발자 PC와 CI/CD 서버의 점검 대상, 수정 버전과 확인 방법, 업데이트 전에 지킬 수칙을 차례대로 정리합니다.
■ Git 보안 취약점 6건, 무엇이 공개됐나
출처: AI(ChatGPT) 생성 이미지
Git은 개발자가 소스코드의 변경 이력을 관리하고 여러 사람이 함께 작업할 때 쓰는 도구입니다. GitHub는 이런 Git 저장소를 올려 두고 협업하는 서비스 가운데 하나로, Git과 GitHub는 같은 제품이 아닙니다. 이번 문제는 GitHub 계정의 로그인이나 비밀번호가 뚫린 사건이 아니라, Git 프로그램이 특정한 저장소나 입력 데이터를 처리하는 과정의 결함입니다.
GitHub 블로그의 발표에 따르면 이번 업데이트는 재귀 복제, 참조 정보 처리, 병합, 바이너리 패치, 데이터 가져오기와 관련된 취약점 6건을 고칩니다. 악성 저장소를 재귀 복제할 때의 임의 코드 실행, 의도하지 않은 위치에 파일이 써지는 문제, 병합이나 바이너리 패치를 처리할 때의 메모리 손상이 여기에 포함됩니다.
6건의 위험이 모두 같은 것은 아닙니다. 코드 실행까지 이어질 수 있다고 공식 발표가 설명한 것은 재귀 복제 취약점 한 건이고, 나머지는 파일 기록, 서비스 중단, 메모리 손상, 파일 읽기처럼 각각의 설명 범위가 다릅니다. 공식 발표에는 실제 공격이나 피해 사례가 언급돼 있지 않습니다. 취약점이 공개됐다는 사실과 공격이 벌어지고 있다는 사실은 구분해서 봐야 합니다.
■ 악성 저장소를 재귀 복제하면 코드가 실행되는 이유
출처: AI(ChatGPT) 생성 이미지
이번 업데이트에서 가장 주의해야 할 취약점은 CVE-2026-111760입니다. 서브모듈은 저장소 안에 다른 저장소를 포함시키는 기능이고, 재귀 복제는 이 서브모듈까지 한 번에 내려받는 방식입니다. 이번 취약점은 바로 이 재귀 복제 과정에서 나옵니다.
Git은 작업 폴더에 파일을 쓰기 전에 경로를 검사해, 저장소의 관리 정보인 .git을 덮어쓰는 경로를 막습니다. 그런데 Git의 인덱스 처리 과정에 정수 값이 잘리는 결함이 있어서, 아주 긴 경로가 한 이름으로 검사를 통과한 뒤 더 짧은 이름으로 기록될 수 있습니다. 공격자는 이 차이를 이용해 서브모듈의 .git 파일을 악성 설정이나 훅(hook, 특정 동작 시 자동 실행되는 스크립트)이 들어 있는 폴더를 가리키는 심볼릭 링크로 바꿀 수 있습니다. Git이 이후 그 폴더를 사용하면 재귀 복제 중에 공격자가 준비한 코드가 실행될 수 있습니다.
공격 흐름을 정리하면 아래와 같습니다.
• 1단계. 공격자가 특수한 경로 구조와 서브모듈을 넣어 조작한 저장소를 준비합니다.
• 2단계. 개발자나 자동화 서버가 이 저장소를 재귀 복제합니다.
• 3단계. 경로 검사 오류로 서브모듈의 관리 파일이 심볼릭 링크로 바뀝니다.
• 4단계. Git이 악성 설정이나 훅이 들어 있는 폴더를 사용하면서 코드가 실행됩니다.
여기서 조건을 정확히 봐야 합니다. 이 취약점은 취약한 버전의 Git이 공격자가 만든 저장소를 재귀 복제하는 경우에 성립합니다. 평범한 저장소를 복제할 때마다 코드가 실행된다는 뜻이 아닙니다. 다만 외부 저장소를 내려받는 일이 잦은 개발 조직에서는, 믿을 수 없는 출처의 저장소가 한 번만 섞여 들어와도 문제가 될 수 있다는 점이 위험 요인입니다. 수정판은 아주 긴 인덱스 경로를 길이가 잘리기 전에 거부하도록 바뀌었습니다.
■ 개발자 PC와 CI/CD 서버도 영향받을까?
출처: AI(ChatGPT) 생성 이미지
Git은 개발자 PC에만 있지 않습니다. 빌드 서버가 소스코드를 가져올 때, 개발 도구가 저장소를 열 때, 소스코드 호스팅 서비스가 병합을 처리할 때도 Git이 쓰입니다. GitHub 블로그는 운영체제나 Git 배포처가 내놓은 수정 버전과 함께, Git을 내장한 애플리케이션, 자동화와 저장소 처리 서비스에서 쓰는 Git도 업데이트하라고 권고했습니다.
아래 표는 기업에서 Git이 설치돼 있을 가능성이 있는 환경과 확인할 내용을 정리한 것입니다. 표의 확인 내용은 공식 발표를 바탕으로 한 일반적인 점검 항목입니다.
| 점검 대상 | 확인할 내용 |
|---|---|
| 개발자 PC | 사용 중인 Git 버전과 설치 경로 |
| CI/CD 서버 | 자동 복제와 서브모듈 처리 여부, Git 버전 |
| 자체 운영 빌드 서버 | 외부 저장소를 가져오는 스크립트와 Git 버전 |
| 컨테이너·개발 이미지 | 이미지 안에 설치된 Git 패키지 버전 |
| IDE·개발 도구 | 내장 Git 실행 파일과 배포사의 업데이트 |
| 사내 Git 호스팅 | 병합과 저장소 가져오기 기능, 서버 업데이트 |
직원 PC의 Git만 올리면 끝나는 작업이 아닙니다. 특히 CI/CD 서버는 사람이 지켜보지 않는 상태로 외부 저장소를 자동으로 복제하는 경우가 많아, 재귀 복제 옵션이 쓰이는지 먼저 확인해야 합니다. 사내 Git 호스팅 서비스처럼 사용자를 대신해 병합을 수행하는 서버는 병합 관련 취약점의 영향 범위에도 들어갑니다.
■ 취약점 6건 한눈에 비교
아래 표는 GitHub 블로그가 정리한 6건을 비교한 것입니다. 위험이 서로 다르므로 6건 모두를 원격 코드 실행으로 이해하지 않도록 주의해야 합니다.
| CVE 번호 | 발생 조건 | 공식 발표가 설명한 영향 |
|---|---|---|
| CVE-2026-111760 | 악성 저장소를 재귀 복제할 때 인덱스 경로 길이가 잘려 경로 검사 우회 | 재귀 복제 중 임의 코드 실행 |
| CVE-2026-113408 | 빈 저장소를 프로토콜 v2로 복제할 때 서버가 알린 HEAD 대상 경로를 검증하지 않음(파일 참조 방식을 쓰는 경우, 이후 브랜치를 갱신하는 작업에서 기록) | 참조 폴더 밖의 의도하지 않은 위치에 파일 기록 |
| CVE-2026-114467 | 서명이 3개 이상 들어 있는 메시지나 태그를 병합하며 서명을 제거할 때 | 스택 메모리 손상과 서비스 중단 가능성 |
| CVE-2026-114469 | 압축을 풀면 크기 제한을 넘는 조작된 바이너리 패치 적용 | 메모리 범위 밖 읽기와 Git 충돌 |
| CVE-2026-105437 | 충돌이 많고 충돌 표시 크기 속성이 큰 병합에서 필요한 메모리 크기 계산 오버플로 | 힙 메모리 손상 |
| CVE-2026-114466 | 신뢰할 수 없는 fast-import 입력에서 일부 기능의 접근 제한 부족 | 임의 파일 읽기, 파일 생성과 추가 기록 |
GitHub 블로그, Git security vulnerabilities announced (2026년 11월 10일) 기준입니다.
이 가운데 병합 관련 두 건(CVE-2026-114467, CVE-2026-105437)은 신뢰할 수 없는 내용을 병합하는 애플리케이션과 호스팅 서비스, 그리고 로컬 병합에도 해당할 수 있다고 발표는 설명했습니다. fast-import 취약점은 Git이 기본으로 막는 위험한 기능 세 가지가 입력 스트림에서는 막혀 있지 않던 문제로, 수정판은 이 기능들을 --allow-unsafe-features 옵션을 직접 켜지 않으면 거부합니다. 입력을 만들어 내는 프로그램을 신뢰할 수 있을 때만 이 옵션을 켜야 합니다.
■ Git 수정 버전과 업데이트 확인 방법
Git 프로젝트는 Git 2.56.1에 수정 사항을 담고, 이전 계열에도 같은 수정을 적용한 버전을 내놓았습니다. 사용 중인 계열에 맞는 수정 버전을 쓰면 됩니다. 공식 발표는 영향 버전의 범위를 따로 표로 정리하지 않고 수정 버전만 제시했으므로, 아래 수정 버전보다 낮다면 수정이 반영되지 않은 버전으로 볼 수 있습니다.
| Git 계열 | 수정 버전 |
|---|---|
| 2.56 | 2.56.1 |
| 2.55 | 2.55.1 |
| 2.54 | 2.54.1 |
| 2.53 | 2.53.1 |
| 2.52 | 2.52.1 |
| 2.51 | 2.51.3 |
| 2.50 | 2.50.2 |
GitHub 블로그(2026년 11월 10일) 기준입니다. 공식 발표는 2.56.1 또는 사용 중인 유지보수 계열의 수정 버전으로 업데이트하라고 권고했습니다.
1. 설치된 Git 버전과 경로 확인
터미널(Windows는 명령 프롬프트나 PowerShell)에서 아래 명령으로 현재 버전을 확인합니다.
git --versionGit이 여러 곳에 설치돼 있으면 실제로 쓰이는 실행 파일이 다를 수 있으므로 설치 경로도 함께 확인합니다.
• Linux, macOS
command -v git• Windows 명령 프롬프트
where git2. 재귀 복제를 쓰는 작업 확인
개발 문서와 자동화 스크립트에서 아래 명령이나 옵션이 쓰이는지 찾아봅니다.
git clone --recurse-submodules
git submodule update --init --recursive이 명령은 정상적인 Git 기능이고, 사용했다는 것만으로 침해를 의미하지 않습니다. 믿을 수 없는 저장소에 대해 실행할 때 추가 위험이 있다는 뜻입니다.
3. 배포판과 내장 프로그램의 패치 상태 확인
공식 발표는 운영체제나 Git 배포처에서 수정 버전을 설치하고, 자체 Git을 포함한 애플리케이션도 업데이트하라고 권고했습니다. 리눅스 배포판은 수정 사항을 기존 버전 번호에 반영해 제공하는 경우가 있으므로, 버전 숫자만 보고 패치 여부를 단정하지 말고 배포판의 보안 공지를 함께 확인하는 것이 좋습니다.
GitHub는 github.com과 GitHub Enterprise Cloud에 수정을 반영했다고 밝혔습니다. GitHub Enterprise Server는 3.19.15, 3.20.11, 3.21.9, 3.22.4 버전이 나왔으며 관리자는 가능한 한 빨리 올리라고 권고했습니다. GitHub Desktop과 GitHub Copilot 앱은 패치된 Git을 포함한 버전을 조율 중이고, Codespaces와 Actions도 패치된 Git을 받을 예정이라고 했습니다. 이 서비스들을 쓰는 조직은 각 제품의 업데이트 공지를 따로 확인해야 합니다.
■ 업데이트 전에 지켜야 할 임시 보안 수칙
수정 버전 설치가 가장 확실한 방법이라고 공식 발표는 밝혔습니다. 업데이트를 바로 하기 어려운 환경이라면 같은 발표가 제시한 아래 조치로 위험 노출을 줄일 수 있습니다.
• 믿을 수 있는 서버에서만 복제하고, 신뢰할 수 없는 저장소는 재귀 복제하지 않습니다.
• 출처가 불분명한 내용이나 태그는 병합하지 않습니다.
• 신뢰할 수 없는 곳에서 온 바이너리 패치는 적용하지 않습니다.
• 검증되지 않은 fast-import 입력은 사용하지 않습니다.
이 조치는 패치를 대신하지 못합니다. 또 아래 사항은 공식 발표가 아니라 일반적인 운영 점검에 해당하는 내용입니다. 외부 저장소를 가져오는 CI/CD 작업은 비밀 값이나 배포 권한이 없는 격리된 환경에서 실행하고, 복제 대상 저장소의 출처를 허용 목록으로 관리하면 만일의 경우 피해 범위를 줄일 수 있습니다.
■ 기업이 함께 점검할 개발환경 보안
이번 취약점은 Git 하나의 문제지만, 개발 조직이 외부 코드를 가져오는 방식 전체를 돌아보게 합니다. 아래 항목은 공식 발표 내용이 아니라 소프트웨어 공급망 보안 관점에서 일반적으로 점검하는 사항입니다.
• Git과 개발 도구의 자산 목록. 개발자 PC, 빌드 서버, 컨테이너 이미지, 개발 도구가 각각 어떤 Git 버전을 쓰는지 한 목록으로 관리합니다.
• 외부 저장소 유입 경로. 서브모듈과 외부 의존성을 어디서 가져오는지 파악하고, 새로 추가할 때 출처를 검토하는 절차를 둡니다.
• 자동화 계정의 권한. CI/CD가 쓰는 계정과 토큰이 필요한 만큼의 권한만 갖는지 확인하고, 복제와 빌드 단계에서 쓰는 비밀 값을 분리합니다.
• 빌드 환경의 격리. 외부 코드를 실행하는 빌드 작업은 내부망과 분리된 일회성 환경에서 돌아가도록 구성합니다.
• 보안 공지 확인 체계. Git 프로젝트와 사용 중인 개발 플랫폼의 보안 공지를 누가 언제 확인하고, 업데이트 일정을 어떻게 정할지 정해 둡니다.
SK쉴더스는 애플리케이션 취약점 진단과 모의해킹으로 개발과 배포 환경의 보안 수준을 점검하고, 소프트웨어 공급망 보안 관점의 진단과 보안관제, 침해사고 대응 서비스로 이상 징후 탐지와 사고 분석을 지원하고 있습니다.
■ 자주 묻는 질문
Q. GitHub도 위험한가요?
A. 이번 문제는 Git 프로그램의 취약점이고 GitHub 계정이나 서비스 전체가 침해된 사건이 아닙니다. GitHub는 github.com과 GitHub Enterprise Cloud에 수정을 반영했다고 밝혔고, GitHub Enterprise Server는 수정 버전으로 업그레이드해야 합니다.
Q. 저장소를 복제하기만 하면 코드가 실행되나요?
A. 그렇지 않습니다. 공식 발표가 설명한 코드 실행 조건은 취약한 Git이 공격자가 만든 저장소를 재귀 복제하는 경우입니다. 평범한 저장소를 복제하는 모든 작업에서 코드가 실행되는 것은 아닙니다.
Q. 6건 모두 원격 코드 실행이 가능한가요?
A. 아닙니다. 공식 발표 기준으로 임의 코드 실행이 언급된 것은 CVE-2026-111760 한 건이고, 나머지는 파일 기록과 읽기, 메모리 손상, 서비스 중단처럼 각각 설명된 범위가 다릅니다.
Q. 실제 공격이 있었나요?
A. 공식 발표에는 실제 공격이나 피해 사례가 언급돼 있지 않습니다. 취약점이 공개됐다는 사실만으로 공격이 진행 중이라고 단정할 수 없지만, 수정 버전이 나온 만큼 빠른 업데이트가 권고됩니다.
Q. Git 버전은 어떻게 확인하나요?
A. 터미널에서 git --version 명령으로 확인합니다. 리눅스 배포판은 수정 사항을 기존 버전에 반영하는 경우가 있어, 버전 숫자와 함께 배포판의 보안 공지를 확인하는 것이 좋습니다.
Q. 직원 PC의 Git만 업데이트하면 충분한가요?
A. 부족합니다. 공식 발표는 자동화와 서비스에서 쓰는 Git, 자체 Git을 포함한 애플리케이션도 업데이트하라고 권고했습니다. CI/CD 서버와 컨테이너 이미지, 개발 도구도 함께 확인해야 합니다.
[콘텐츠 출처]
GitHub Blog, Git security vulnerabilities announced (2026.11.10)
