GitHub이 git push 처리 경로에서 발견된 치명적 원격 코드 실행(RCE) 취약점 CVE-2026-3854를 공개했다. GitHub.com과 Enterprise Cloud는 이미 패치됐지만, GitHub Enterprise Server(GHES)를 직접 운영하는 조직은 지정된 패치 버전으로 올리고 push option 로그를 확인해야 한다.
핵심 요약
- 취약점: git push option에 포함된 사용자 입력이 내부 메타데이터 구분자와 충돌하면서, 다운스트림 서비스가 공격자가 주입한 값을 신뢰된 내부 필드처럼 해석할 수 있었다.
- 영향: 저장소에 push 권한이 있는 인증 사용자가 조작된
git push한 번으로 서버 측 명령 실행까지 이어질 수 있는 시나리오가 보고됐다. - 대응: GitHub는 2026년 3월 4일 17:45 UTC에 원인을 특정했고, 19:00 UTC에 github.com 수정 배포를 완료했다고 밝혔다.
- 조치 대상: GitHub.com, Enterprise Cloud, Enterprise Managed Users, Data Residency 사용자는 추가 조치가 필요 없다고 안내됐다. GHES 운영자는 패치 업그레이드와 로그 점검이 필요하다.
무엇이 문제가 됐나
Git의 push option은 클라이언트가 push 과정에서 서버로 key-value 형태의 문자열을 전달할 수 있게 하는 정상 기능이다. 문제는 이 값이 GitHub 내부 서비스 사이에서 push 메타데이터를 전달하는 과정에 충분히 정제되지 않은 채 들어갔다는 점이다. 내부 메타데이터 형식이 쓰는 구분자 문자가 사용자 입력에도 포함될 수 있었고, 이 때문에 공격자는 추가 필드를 삽입해 후속 서비스가 처리 환경이나 실행 제약을 잘못 인식하게 만들 수 있었다.
GitHub 설명에 따르면 연구진은 여러 주입 값을 연결해 push가 처리되는 환경을 덮어쓰고, hook 실행을 제한하는 샌드박스 보호를 우회한 뒤, 최종적으로 서버에서 임의 명령 실행이 가능함을 입증했다. 공격 조건은 “인증된 사용자”와 “대상 저장소에 대한 push 권한”이지만, 사용자가 직접 만든 저장소도 조건에 포함될 수 있어 단순한 관리자 전용 취약점으로 보기 어렵다.
GitHub의 대응 타임라인
| 시점 | 내용 |
|---|---|
| 2026년 3월 4일 | Wiz 연구진이 GitHub Bug Bounty 프로그램을 통해 취약점을 제보했다. |
| 제보 후 40분 이내 | GitHub 보안팀이 내부 재현에 성공하고 심각도를 확인했다. |
| 17:45 UTC | 근본 원인을 특정했다. |
| 19:00 UTC | github.com에 수정 사항을 배포했다. |
| 공개 시점 | GHES 지원 버전별 패치와 CVE-2026-3854가 공지됐다. |
GitHub는 수정 배포 후 포렌식 조사를 진행했고, 악용 여부를 확인하기 위해 정상 운영에서는 사용되지 않는 특이 코드 경로가 실행된 흔적을 텔레메트리에서 조회했다고 설명했다. 공개 글 기준으로 해당 경로 실행은 Wiz 연구진의 테스트 활동에만 매핑됐고, 다른 사용자나 계정의 악용 흔적 및 고객 데이터 접근·수정·유출은 확인되지 않았다고 밝혔다.
GHES 운영자가 바로 확인할 것
GitHub Enterprise Server를 자체 운영한다면 이 이슈는 “이미 클라우드에서 끝난 사건”이 아니다. GHES에서는 공격자가 해당 인스턴스에 인증된 계정을 갖고 있고 저장소 push 권한을 보유해야 하지만, 내부 개발자 계정 탈취나 과도한 저장소 권한이 결합되면 위험도가 커진다.
- 업그레이드: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4, 3.20.0 또는 그 이후 패치 릴리스로 올린다.
- 로그 점검:
/var/log/github-audit.log에서 push option에 세미콜론(;)이 포함된 push 작업을 확인한다. - 권한 점검: 외부 협력자, 자동화 계정, 오래된 개인 액세스 토큰이 불필요한 push 권한을 갖고 있지 않은지 확인한다.
- 증거 보존: 의심 이벤트가 있으면 audit log, 인증 로그, 관련 저장소 활동 기록을 먼저 보존한 뒤 토큰 회전과 계정 잠금을 진행한다.
이번 사례가 주는 운영 교훈
이번 취약점의 핵심은 단순히 “입력값을 sanitize하지 않았다”에 그치지 않는다. GitHub는 취약점 악용이 가능했던 이유 중 하나로, 특정 제품 구성에서만 필요했던 코드 경로가 서버 컨테이너 이미지 안에 남아 있었던 점을 언급했다. 과거 배포 방식에서는 제외되던 코드가 새 배포 모델로 바뀌는 과정에서 그대로 포함됐다는 설명이다.
이는 플랫폼 운영팀에 익숙한 문제다. 컨테이너 이미지와 내부 서비스가 커질수록 “지금 이 런타임에 실제로 필요한 코드와 권한만 남기는가”가 중요해진다. 입력 검증은 1차 방어선이고, 불필요한 실행 경로 제거, 샌드박스 경계 검증, 서비스 간 메타데이터 포맷의 명확한 escape 규칙, 취약 경로를 탐지할 수 있는 텔레메트리가 함께 있어야 사고 범위를 줄일 수 있다.
개발 조직이 적용할 점검 기준
- CI/CD와 Git 서버 입력: commit message, branch name, push option, webhook payload처럼 “개발자가 넣는 문자열”이 내부 제어 필드로 해석되는 지점을 점검한다.
- 구분자 기반 프로토콜: 내부 메타데이터가 문자열 구분자에 의존한다면 escape, length-prefix, 구조화 포맷 전환 가능성을 검토한다.
- 컨테이너 최소화: 실행 환경별로 필요 없는 바이너리, hook, 관리 스크립트가 이미지 안에 남아 있지 않은지 확인한다.
- 이상 경로 관측: 정상 트래픽에서 절대 호출되지 않아야 하는 코드 경로는 로그와 알림으로 드러나야 한다.
결론
CVE-2026-3854는 GitHub가 빠르게 패치했고 공개된 조사 결과상 악용 정황은 없었다. 그러나 GHES를 운영하는 조직에는 여전히 명확한 할 일이 남아 있다. 패치 버전을 확인하고, push option 로그를 점검하며, Git 서버·CI/CD·컨테이너 런타임 사이에서 사용자 입력이 내부 제어값으로 승격되는 지점을 다시 보는 것이 좋다. 특히 자체 호스팅 개발 플랫폼은 “인증 사용자만 가능”이라는 조건을 낮은 위험으로 착각하기 쉽다. 내부 계정과 자동화 토큰이 이미 공격자의 첫 목표라는 점을 전제로 방어해야 한다.