2026년 3월 4일, GitHub의 버그 바운티 프로그램을 통해 GitHub Enterprise Server 및 GitHub.com 전반에 영향을 미치는 치명적인 원격 코드 실행(RCE) 취약점 CVE-2026-3854가 보고되었다. 보고를 접수한 GitHub는 2시간 이내에 GitHub.com에 대한 수정을 배포했으며, 이후 Enterprise Server 전 지원 버전에 대한 패치를 릴리스했다. CVSS v3.1 기준 8.7(High)로 평가된 이 취약점은 git push 파이프라인 내부의 메타데이터 헤더 처리 과정에서 발생하는 커맨드 인젝션 문제로, 저장소에 push 권한만 있는 인증된 사용자라면 누구든, 심지어 직접 생성한 빈 저장소 하나만으로도 서버에서 임의 코드를 실행할 수 있는 구조적 결함이다.
특히 GitHub Enterprise Server 환경에서는 서버 전체 장악과 모든 저장소 및 내부 설정 정보 접근이 가능하며, GitHub.com의 공유 멀티테넌트 인프라에서는 동일한 스토리지 노드에 호스팅된 타 조직·사용자의 수백만 개 저장소가 크로스 노출되는 결과로 이어질 수 있었다. 공개 시점 기준으로 88%의 GitHub Enterprise Server 인스턴스가 여전히 취약한 버전을 운영 중인 것으로 확인되었다.
본 글에서는 CVE-2026-3854의 기술적 원인과 공격 흐름을 분석하고, GitHub Enterprise Server 환경에서 외부에 노출된 자산이 어떤 공격 표면으로 이어질 수 있는지 살펴본다.
CVE-2026-3854 RCE 취약점 개요
| 항목 | 내용 |
|---|---|
| 취약점 ID | CVE-2026-3854 |
| 영향 제품 | GitHub.com, GitHub Enterprise Cloud, GitHub Enterprise Server |
| 취약점 유형 | Command Injection |
| CVSS 점수 | 8.7 (High) |
| 영향 버전 | GitHub Enterprise Server 3.14.24 이전, 3.15.19 이전, 3.16.15 이전, 3.17.12 이전, 3.18.6 이전, 3.19.3 이전 |
| 패치 버전 | 3.14.24 이상, 3.15.19 이상, 3.16.15 이상, 3.17.12 이상, 3.18.6 이상, 3.19.3 이상 |
이 취약점은 git push 과정에서 전달되는 사용자 입력이 내부 서비스 간 메타데이터로 전달될 때 적절히 검증되지 않으면서 발생한다.
기술적 원인: 내부 서비스 신뢰 모델의 균열
CVE-2026-3854의 핵심은 git push 파이프라인을 구성하는 여러 내부 서비스 간의 신뢰 모델에 있다. 각 컴포넌트는 개별적으로는 올바르게 동작하지만, 서로 데이터를 전달하는 지점에서 입력값 검증이 누락되었다.
git push 파이프라인 구조
사용자가 git push 명령을 SSH로 전송하면, 요청은 babeld(git SSH 프록시 및 진입점) → gitauth(내부 인증 서비스) → gitrpcd(내부 RPC 서버) → pre-receive hook(보안 정책 집행) 순으로 처리된다. 이 과정에서 babeld는 push 작업에 관한 보안 관련 설정값을 X-Stat이라는 내부 헤더로 구성해 하위 서비스에 전달한다. X-Stat 헤더는 세미콜론(;)을 구분자로 사용하는 키-값 쌍 형식(key=value;key=value;...)으로 이루어진다.
취약점 발생 지점
문제는 babeld가 사용자가 입력한 git push 옵션(-o 또는 --push-option) 값을 적절히 검증하지 않은 채 X-Stat 헤더에 그대로 삽입했다는 데 있다. X-Stat의 필드 구분자인 세미콜론이 사용자 입력에도 그대로 사용될 수 있었으며, 헤더 파서는 마지막으로 등장한 값이 우선 적용되는(last-write-wins) 방식으로 동작했다. 공격자는 push 옵션 값 안에 세미콜론과 함께 조작된 키-값 쌍을 삽입하는 것만으로 X-Stat 헤더 내의 정상 필드를 덮어쓸 수 있었다. 하위 서비스들은 X-Stat 헤더의 모든 필드를 신뢰할 수 있는 내부 데이터로 처리했기 때문에, 주입된 값도 정상적인 내부 설정값으로 해석되었다.
3단계 주입 체이닝: 샌드박스에서 전체 장악까지
CVE-2026-3854의 연구팀은 세 가지 주입을 연속으로 체이닝해 완전한 RCE까지 도달하는 경로를 실증했다. 첫 번째 단계에서 rails_env 주입으로 샌드박스를 우회한다. rails_env=nonprod 값을 X-Stat에 주입하면, 서버는 프로덕션 환경의 보안 제약이 적용되지 않는 비프로덕션 모드로 전환된다. 이 환경에서는 pre-receive hook 실행 시 정상적으로 비활성화되어 있는 코드 경로가 활성화된다. 두 번째 단계에서 custom_hooks_dir 주입으로 훅 실행 디렉토리를 조작한다. 공격자가 제어하는 디렉토리를 훅 실행 경로로 설정한다. 이 단계에서 서버 파일시스템에 대한 경로 탐색이 가능해진다.
세 번째 단계에서 repo_pre_receive_hooks 주입으로 임의 명령을 실행한다. 조작된 훅 항목을 삽입해 경로 탐색과 결합, 최종적으로 git 서비스 사용자 권한으로 서버에서 임의 파일을 실행할 수 있다. 연구팀은 이 단계에서 파일시스템 읽기/쓰기 권한과 내부 서비스 설정에 대한 완전한 접근권을 확보했음을 확인했다.
GitHub.com에서의 추가 공격 경로
GitHub.com은 기본적으로 커스텀 훅이 비활성화되어 있어 앞의 체이닝이 직접 적용되지 않는다. 그러나 Enterprise Server 모드를 활성화하는 enterprise_mode 플래그 또한 X-Stat 헤더를 통해 전달되기 때문에, 동일한 주입 메커니즘으로 이 플래그를 true로 설정할 수 있었다. 이를 통해 GitHub.com에서도 커스텀 훅 경로가 활성화되어 동일한 RCE 체이닝이 가능해졌으며, GitHub의 공유 멀티테넌트 아키텍처 특성상 공격이 성공한 스토리지 노드에 호스팅된 타 조직·사용자의 공개 및 비공개 저장소 수백만 개에 대한 접근이 가능했다.
Criminal IP를 통해 관측된 외부 노출 GitHub Enterprise Server 자산
인터넷에 노출된 GitHub Enterprise Server 인스턴스 현황을 파악하기 위해 Criminal IP Asset Search를 활용해 외부 노출 자산을 관측했다.
Criminal IP 검색 쿼리: title: GitHub Enterprise
GitHub Enterprise Server 웹 인터페이스는 로그인 페이지 타이틀에 “GitHub Enterprise”를 포함하는 특성이 있어, Criminal IP Asset Search의 타이틀 기반 검색으로 관리 UI가 외부에 노출된 인스턴스를 직접 식별할 수 있다. push 권한이 있는 사용자라면 누구든 공격이 가능한 CVE-2026-3854의 특성상, 관리 인터페이스뿐 아니라 Git SSH/HTTP 접근이 가능한 모든 외부 노출 인스턴스가 공격 표면이 된다. 현재 GitHub는 패치를 배포하여 많은 자산들이 패치를 적용하였음에도 불구하고 Criminal IP를 통해 아직 패치 버전이 적용되지 않았을 가능성이 있으며 외부에서 공개적으로 접근 가능한 인스턴스를 식별할 수 있다. 탐지 결과 2026년 5월 초 기준 약 2,204개의 자산이 식별되었으며 해당 자산들은 위에서 언급한 바와 같이 push 권한이 있는 사용자 누구에게든 공격을 받을 수 있기 때문에 빠른 대응과 조치가 필요한 상황이다.
Criminal IP Asset Search를 통해 이번 CVE-2026-3854에 취약한 특정 자산을 분석하였다. 그 결과 위와 같이 높은 위험도를 가진 것으로 분류되었으며 22번 포트(SSH)와 80번 포트(HTTP)가 외부에 개방된 상태로 확인되었다. 또한 추가적인 취약점 8건과 정책 위반 1건이 함께 식별되었는데 이는 단순 자산 노출을 넘어 개발 인프라 또는 관련 운영 환경이 인터넷에서 공격자로 부터 직접 접근 가능한 상태일 가능성을 시사한다.
GitHub Enterprise Server는 조직의 소스코드, 내부 문서, CI/CD 구성, 배포 스크립트, 시크릿 정보가 집중되는 핵심 개발 인프라다. 이러한 특정 자산이 외부에 노출된 상태로 유지될 경우 공격자는 저장소 push 권한만으로 서버 내부 실행 환경을 조작하고 파일 시스템 접근, 내부 설정 정보 탈취, 저장소 및 파이프라인 변조로 공격을 확장할 수 있다. 따라서 이와 같은 특정 자산들은 조직의 개발 및 배포 체계 전체로 이어질 수 있는 고위험 공격 표면으로 우선 점검해야 한다.
패치 현황 및 대응 방안
CVE-2026-3854는 GitHub 내부 프로토콜 처리 과정에서 발생한 입력 검증 미흡으로 인해 발생한 취약점으로, GitHub는 해당 문제를 인지한 직후 입력값에 대한 필터링 및 메타데이터 처리 로직을 보완하여 패치를 적용했다.
GitHub Enterprise Server의 경우 다음 버전에서 수정이 반영되었다.
- 3.14.24 이상
- 3.15.19 이상
- 3.16.15 이상
- 3.17.12 이상
- 3.18.6 이상
- 3.19.3 이상
또한 클라우드 환경(GitHub.com 및 Enterprise Cloud)에서는 즉각적인 서버 측 패치를 통해 취약점이 해소된 것으로 확인된다.
그러나 이번 취약점은 단순한 코드 결함이 아니라, “사용자 입력이 내부 신뢰 데이터로 처리되는 구조 자체”에서 발생한 문제라는 점에서 주의가 필요하다. 특히 GitHub Enterprise Server와 같이 조직 내부에서 운영되는 환경에서는, 패치 적용 이전에 이미 공격이 수행되었을 가능성을 고려해야 한다. 공격자는 단순한 git push 요청만으로 내부 실행 환경을 변조할 수 있으며 이외에도 hook 실행 환경 변경을 통한 임의 코드 실행, 파일 시스템 접근 및 내부 설정 정보 탈취, 저장소 및 CI/CD 파이프라인 조작, 서버 구성 및 인증 정보 노출 등의 행위를 수행할 수 있다. 이는 개발 인프라 전체에 대한 권한 탈취로 이어질 수 있는 것이다.
따라서 조직은 단순 패치 적용을 넘어 이미 침해가 되었을 가능성을 염두에 두고 대응해야 하며 다음과 같은 조치가 요구된다.
- GitHub Enterprise Server를 최신 버전으로 즉시 업데이트
- 외부에서 접근 가능한 인스턴스에 대해 VPN 또는 IP 기반 접근 제한 적용
- 저장소 push 권한 최소화 및 불필요한 권한 제거
- hook 실행 환경 및 custom hook 설정 점검
- 비정상적인 push 이벤트 및 실행 로그 모니터링
결과적으로 이번 이슈에서의 핵심 대응은 패치 적용을 넘어 노출된 개발 인프라 통제 및 침해 전체 대응이다. 외부에 노출된 GitHub Enterprise Server 인스턴스를 식별하고 접근을 제한하는 것이 단일 취약점 대응을 넘어 조직 전체 개발 환경을 보호하는 핵심 요소가 된다.
FAQ
Q1. 인증이 필요한 취약점인데 왜 Critical 수준으로 취급해야 하나요?
push 권한은 획득 문턱이 매우 낮습니다. 공격자가 GitHub에 직접 계정을 생성하고 빈 저장소 하나를 만드는 것만으로 공격 조건이 충족됩니다. GitHub.com에서는 크로스 테넌트 노출로 인해 동일 스토리지 노드의 타 조직 비공개 저장소까지 접근 가능하며, GitHub Enterprise Server에서는 서버 전체 장악으로 이어집니다. 인증이라는 조건이 실질적인 장벽이 되지 않는다는 점에서 위험도가 높게 평가됩니다.
Q2. GitHub.com은 이미 패치됐는데 GitHub Enterprise Server는 왜 여전히 위험한가요?
GitHub.com은 클라우드 서비스이므로 GitHub이 직접 즉시 패치를 적용할 수 있습니다. 반면 GitHub Enterprise Server는 조직이 자체 인프라에서 운영하는 자체 호스팅 솔루션이므로 각 운영 조직이 직접 업그레이드를 수행해야 합니다. 공개 시점 기준 88%의 인스턴스가 패치되지 않은 상태였으며, 기술 공개와 PoC가 이미 알려진 상황에서 패치 지연은 즉각적인 공격 위험으로 이어집니다. 따라서 패치 적용을 필수적으로 진행하고 실제 운영 조직에서는 감사 로그 점검 및 침해 여부 조사까지 진행하며 더 나아가 필요 시 저장소 접근 이력과 내부 시크릿 전체를 교체해야 합니다.
결론
CVE-2026-3854는 세계 최대 코드 호스팅 플랫폼의 핵심 인프라가 git push 파이프라인에서, 단 하나의 세미콜론이 수백만 저장소를 위협할 수 있었음을 보여준다. 이번 사례가 특히 주목받는 이유는 취약점의 파괴력만큼이나, 2시간이라는 대응 속도와 포렌식 조사를 통한 악용 부재 확인까지 이어진 책임감 있는 공개 대응 절차에 있다. 그러나 이 속도 있는 대응에도 불구하고, 자체 호스팅 GitHub Enterprise Server 운영 조직들의 패치 이행률이 여전히 저조하다는 사실은 또 다른 문제를 드러낸다. 취약점이 수정되어도 외부에 노출된 패치 미적용 인스턴스가 남아 있는 한, 공격자의 관점에서는 유효한 공격 표면이 계속 존재한다. 조직이 운영하는 GitHub Enterprise Server 인스턴스가 어디에 있고 어떤 버전을 사용하는지 파악하는 것, 그리고 그 인스턴스가 인터넷에 얼마나 노출되어 있는지를 지속적으로 모니터링하는 것이 패치 적용만큼 중요하다.
관련하여 CVE-2021-39935: GitLab CI Lint API 서버 사이드 요청 위조 취약점 글을 참고할 수 있다.
Criminal IP (criminalip.io/ko/register) 에 가입하면 즉시 취약 자산 탐지를 시작할 수 있습니다. 또한 아래 버튼을 통해 데모를 요청하고, 엔터프라이즈 환경에서 외부에 노출된 자산을 대상으로 한 Criminal IP의 위협 인텔리전스(TI) 분석을 직접 확인해 보세요.
이 리포트는 AI기반 사이버 위협 인텔리전스 검색엔진 Criminal IP의 데이터를 바탕으로 작성되었습니다. 지금 바로 Criminal IP 무료 계정을 생성하면 리포트에 인용된 검색 결과를 직접 확인하거나, 더 방대한 위협 인텔리전스를 자유롭게 검색할 수 있습니다.
출처: Criminal IP(https://www.criminalip.io/ko), SECURITYWEEK (https://www.securityweek.com/critical-github-vulnerability-exposed-millions-of-repositories/), SecurityAffairs (https://securityaffairs.com/191434/security/cve-2026-3854-github-flaw-enables-remote-code-execution.html), TheHackerNews (https://thehackernews.com/2026/04/researchers-discover-critical-github.html)