프론티어_최신 보안 사고 사례 분석

 

https://thehackernews.com/2026/03/openai-patches-chatgpt-data.html

OpenAI Patches ChatGPT Data Exfiltration Flaw and Codex GitHub Token Vulnerability

 

 

https://www.securityweek.com/critical-gemini-cli-flaw-enabled-host-code-execution-supply-chain-attacks/

Critical Gemini CLI Flaw Enabled Host Code Execution, Supply Chain Attacks

 

 

https://m.boannews.com/html/detail.html?tab_type=1&idx=143463

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

 

 

 

외국 기사 2개, 한국 기사 1개로 3개의 보안 사고 사례를 분석해보겠ㄷ

 

OpenAI Patches ChatGPT Data Exfiltration Flaw and Codex GitHub Token Vulnerability

https://research.checkpoint.com/2026/chatgpt-data-leakage-via-a-hidden-outbound-channel-in-the-code-execution-runtime/

https://www.beyondtrust.com/blog/entry/openai-codex-command-injection-vulnerability-github-token

 

비슷하게 올라온 2개의 기사를 같이 확인해보았다.

 

일단 본문 내용 해석부터.

 

OpenAI ChatGpt의 취약점으로 인해 사용자의 동의나 인지 없이 민감한대화 데이터가 유출될 수 있는 취약점이 발견됨.

 

문제 상황

1. 원래는 무단 데이터 공유를 방지하거나 직접적인 외부 네트워크 요청을 생성하지 않도록 다양한 안전장치를 갖추고 있다.

2. 하지만 Linux 런타임에서 발생하는 side channel을 악용하여 이러한 안전장치를 우회한다. 

 

side channel 이란?

프로그램이나 시스템의 직접 출력 X -> 비기능적 특성이나 간접적 흔적을 관찰 및 악용해 비밀 정보를 추론하는 통

 

기사에서 든 예시로는

숨겨진 DNS 기반 통신 경로를 covert transport mechanism으로 악용하여 DNS 요청에 정보를 인코딩할 수 있다. 

-> 사용자가 무료로 프리미엄 기능을이용 & 악성 프롬프트를 붙여넣도록 유도할 수 있음.

더 큰 공격으로 악성 로직을 GPT 자체에 포함시킬 수 있다.

 

위의 설명을 한 이유. 뒤에 있는 Github 토큰 유출 사건 사례 때문!

 

 

Codex에서 command injection이 발견되었다. 하여 해당 취약점 때문에 Github 데이터 탈취를 당한 사건.

 

command injection. 

애플리케이션이 외부 입력값을 포함해 OS 명령어를 만들 때, 특수 문자나 명령 구분자를 제대로 제거하지 않아 공격자가 의도하지 않은 운영체제 명령을 실행하게 만드는 취약점이다.

 

그래서 왜?? 왜 그렇게 당했는데.

 

보통 Codex, Claude를 사용하다 보면 github push도 알아서 해달라고 하는 경우가 많다. 진짜 귀찮으면 이제 Token에 대한 값도 전달하게 된다. 

 

사용자 → Codex에 GitHub 권한 부여 → Codex가 컨테이너 생성 → GitHub repo/branch clone → 작업 수행

 

보통 이런 형식으로 간다.

 

이제 여기서 공격이 들어가는 부분은 Github branch name parameter가 제대로 검증을 하지 않고! shell 명령어에 문자열로 삽입하는것 이다. 

 

=> 풀어서 쓰기.

 

git fetch origin {branch} 가 원래 명령어면 git fetch origin main 그 다음  {추가_명령어 실행} 이 되는 형식이다. 

그러면 이걸 어떻게 공격자가 활용하냐?

 

1. 공격자는 Github 저장소에 악성 브랜치를 만들거나 기존 브랜치를 조작하여 shell 문자, 악성 문자 등을 숨긴다.

2. 그 후 위에 ㅇ올린 것 처럼 main + ..... 으로 악성 스크립트를 넣게 되는 것 이다.

 

그러면 Codex가 해당 작업을 실행하면서  뒤에 있는 작업을 실행하게 되는 것이다 .. .

 

그래서 명령어 실행까지는 OK. 그러면 이걸로 어떻게 GitHub 토큰까지 훔칠 수 있는데?

 

1. Codex가 Github 저장소를 clone하려면 인증이 필요함.

2. setup 단계에서 OAuth token OR git remote URL을 clone 과정에서 사용.

3. Branch 파라미터가 environment setup cript와 remote configuration에 반영되는 것을 확인.

4. command injection payload를 통해 git remote URL 안의 OAuth token을 파일로 출력

5. Codex agent가 그것을 읽어 cleartext token을 얻음.

 

해당 공격을 시나리오화 해보면

 

룰루랄라 사람이 codex와 바이브 코딩을 하다가 Reference로 쓰일 좋은 레포가 보여서 해당 레포에 url을 주거나, 환경 설정을 하던 중 해당 github를 clone하고 사용하게 됨. 

그러다가 이상한 브랜치에 대한 것도 읽어버리면서 해당 브런치 뒤에 있는 명령어를 수행하면서 공격자의 서버로 자신의 repo 토큰들을 보내게 됨. 

그러면 공격자는 해당 Token을 사용하면서 해당 토큰에 있는 권한을 사용하여 read/write를 수행할 수 있게 된다..

 

GPT의 한 줄요약

사용자가 Codex로 신뢰되지 않은 GitHub 저장소나 브랜치를 작업 대상으로 삼았고, Codex의 setup shell이 악성 브랜치 이름을 안전하게 처리하지 못하면서 명령어가 실행되어 GitHub OAuth 토큰이 탈취된 공격이다.

 

Critical Gemini CLI Flaw Enabled Host Code Execution, Supply Chain Attacks

https://www.securityweek.com/critical-gemini-cli-flaw-enabled-host-code-execution-supply-chain-attacks/

Critical Gemini CLI Flaw Enabled Host Code Execution, Supply Chain Attacks

 

이번에는 codex가 아니라 Gemini CLI 버전.

 

Gemini CLI가 CI/CD같은 자동 실행 환경에서 작업 폴더를 무한 신뢰하면서 PR이나 repo안에 심우던 악성 .gemini 설정이 로드 --> 샌드박스 켜지기 -> host에서 명령어가 실행될 수 있었던 취약점이다. 심지어 이걸로 RCE도 가능함.

 

RCE

공격자가 네트워크를 통해 원격에서 대상 시스템(서버, PC 등)의 제어권을 탈취하여 악성 코드를 실행하는 치명적인 보안 취약점입니다. 입력값 검증 미흡, 안전하지 않은 역직렬화, 버퍼 오버플로우 등이 원인이며, 시스템 제어, 데이터 유출, 랜섬웨어 감염을 유발할 수 있습니다.

 

근데 뭐 설명이 거의 똑같아서 시나리오를 기반으로 설명을 해본다고 한다면..

 

다시금 나타난 룰루랄라 개발팀..

 

GitHub Actions를 활용 -> Github CLI를 계속 쓰면서 PR리뷰, 이슈 분석, 코드 설명, 자동 수정 같은 걸 딸-깍 중

 

공격자가 외부 contributor처럼 PR을 날리는데, 해당 PR에는 Gemini CLI가 읽을 수 있는 악성 .gemini/ 설정 파일이나 환경 설정이 같이 들어 있다..

 

이제 여기서 문제!

Gemini CLi가 CI/headless 환경에서 현재 workspace는 믿을 만하네~~ 라고 생각하는 것.

그래서 agent 설정으로 그걸 받아들이고 해당 host runner에서 명령 실행까지 한다는 것 이다.

 

그래서 host runner에서 명령 실행까지 이어질 수 있다. -> 

https://novee.security/blog/google-gemini-cli-rce-vulnerability-cvss-10-critical-security-advisory/

여기서 보면 prompt injection도 아니고 모델 판단도 아니라, AI가 추론하기 전에 발생하는 infrastructure-level execution 문제라라고 한다

 

전체적인 흐름->

공격자 PR 제출
→ PR 안에 악성 .gemini 설정 포함
→ GitHub Actions에서 Gemini CLI 자동 실행
→ Gemini CLI가 workspace를 자동 신뢰
→ 악성 설정 로드
→ sandbox 초기화 전 host에서 명령 실행
→ CI secret, token, source code 접근 가능
→ supply chain attack으로 확장 가능

 

그래서 패치는??

Google은 headless mode, 즉 모든 권한을 주는 모드에서 더 이상 workspace를 자동 신뢰하지 않도록 바꿨고 설정 파일을 읽기 전에 명시적인 trust 결정이 필요하도록 수정했다. 

 

공식 패치 버전은 -> advisory 기준 @google/gemini-cli 0.39.1, 0.40.0-preview.3, run-gemini-cli 0.1.22

 

흠. 까보니까 별거 없네

 

그냥 진짜 AI 딸-깍을 해놓으니까 공격자들이 이것 저것 하기 시작했다.. 

 

 

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

 

https://m.boannews.com/html/detail.html?tab_type=1&idx=143463

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

https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-3854

 

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

 

https://thehackernews.com/2026/04/researchers-discover-critical-github.html

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

 

자 이제는 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 값이 내부 메타데이터 필드에 영향을 주지 못하게 파싱을더 강화하는 것이다.

 

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

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

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