Research Note / Development

세미콜론 하나에 뚫린 깃허브... AI가 찾아낸 역대급 RCE 취약점

May 7, 2026/Development/1 min read

깃허브(GitHub)의 내부 자산 관리 인프라에서 수백만 개의 비공개 저장소를 무자비하게 탈취할 수 있는 치명적 RCE 취약점(CVE-2026-3854)이 발견됐다.

m.boannews.com

[GitHub RCE Vulnerability: CVE-2026-3854 Breakdown | Wiz Blog

A CVSS 8.7 vulnerability in GitHub Enterprise Server allows remote code execution. Read the threat brief and find vulnerable GHES instances from Wiz.

[Researchers Discover Critical GitHub CVE-2026-3854 RCE Flaw Exploitable via Single Git Push

CVE-2026-3854 (CVSS 8.7) enabled GitHub RCE via git push, risking cross-tenant access to millions of repositories.

자 이제는 github이다..

Github에서 Gitgub 내부 프로토콜 필드를 구문하지 못해서 문자와 사용자 입력값의 경계가 무너졌다.

->이게 뭔소리냐

git push를 하면 Github 내부에서는 여러 서비스가 이 요청을 나눠 처리한다,.

이때 push와 관련한 정보가 내부 메타데이터 헤터돌 전달되는데 그 헤더가 ;를 기준으로 필드를 나누는 구조를 원래는 가졌다.

근데 그 안에 ; <-- 요 친구가 제대로 파싱이 안되니까 뒤에 option을 붙일 때 이상한 값을 넣는 것......

자 이제 또 나타나는 룰루룰룰랄랄라라 공격자

공격자는 일단 github에 계정을 만들고 자기가 push 권한을 가진 저장소를 하나 준비한다.

심지어 Github 공식 설명 기준으로는 공격자가 직접 만든 저장소여도 가능. 남의 repo에 먼저 침투 X. 그냥 push권한이 있는 repo하나만 있어도 Github 서버 쪽 취약한 코드 경로를 건드릴 수 있는 문제.

이제 공격자는 평범하게 git push를 하는 척~을 한다. 그 와중에 push option , option 안에 이상한 값을 넣는다.

이 때 Github 앞단 서비스는 이 값을 내부 메타데이터 헤더인 X-Stat 에 넣어서 다음 서비스로 넘긴다.

!! 서비수로 넘길 때 key=value;key=value 이런 식으로 세미콜론을 기준으로 나뉘는데 공격자가 넣은 push option 안에도

세미클론이 들어가면 Github 내부 서비스가 이걸 사용자가 넣은 문자열이 아니라 새로운 내부 설정 필드 처럼 읽는다!!

살짝

사용자 입력값
→ GitHub 내부 헤더에 들어감
→ 세미콜론 때문에 필드가 쪼개짐
→ 공격자가 만든 값이 내부 설정처럼 해석됨
→ GitHub 내부 실행 환경이 조작됨
→ sandbox 우회
→ 서버에서 명령 실행 가능

이런 느낌?

그래서 서버에서 어떤 명령을 시도했냐면..

→ sandbox 우회
→ custom_hooks_dir 조작
→ pre-receive hook 경로 조작
→ path traversal로 임의 바이너리 실행
→ git user 권한으로 서버 명령 실행

이런 느낌으로다가 실행을 해버린다. 이러면 Github 내부 메타데이터 필드를 주입 -> push 처리 환경과 hook 실행 경로 조작 -> Github 백엔드 서버 RCE!!..

그러면 이거 대응은 가능했냐?

그 와중에 빨랐음.

2026년 3/4일 wiz로부터 제보를 받고 40분 안에 내부 재현과 심각도 확인을 했고 2시간 이내에 github.com에 패치를 배포했다.

그리고 포렌식 조사도 진행하면서 Wiz 연구진의 테스트 외에 다른 계정이 해당 비정상 코드 경로를 실행한 적은 없다고 했다.

-> 패치 내용을 간략하게 요약하면 push option 값이 내부 메타데이터 필드에 영향을 주지 못하게 파싱을더 강화하는 것이다.

여기서 보안이 미흡했던 부분은

파싱에서 걸르지 못했더라도 내부 프로코콜에서 뭔가 보안 조치가 있어야하는데 그런 것 없이 무한 신뢰하면서 그냥 바로바로 실행이 되었던 것.

그리고 여러 서비스가 같은 데이터를 다르게 해석해서 생겼던 문제였던 것..