▲

코드래빗 취약점 익스플로잇: 단순 PR에서 100만 레포 RCE 및 쓰기 권한 획득까지

 (research.kudelskisecurity.com)
1P by GN⁺ 6일전 | ★ favorite | 댓글 1개
  • 보안 연구팀이 CodeRabbit의 프로덕션 서버에서 원격 코드 실행(RCE) 및 API 토큰·비밀 정보 유출에 성공함
  • Rubocop을 활용한 PR로 환경 변수 탈취, PostgreSQL 접근과 100만개 레포지토리 읽기/쓰기가 가능했음
  • GitHub App의 프라이빗 키 유출로 퍼블릭/프라이빗 레포 포함 대규모 저장소에 악성코드 주입, 소스 코드 수정 등 실질적 피해가 가능했음
  • CodeRabbit 측은 취약점 신고 후 수시간 내로 즉각 대응하고 보안 조치를 강화했음
  • 외부 도구 실행 시 샌드박스 격리·최소 권한·네트워크 차단 등으로 보안 사고 방지 필요성 강조됨

소개

  • 2025년 1월, Kudelski Security 연구팀은 CodeRabbit의 심각한 보안 취약점을 공개함
  • PR 리뷰 자동화 도구로 널리 쓰이는 CodeRabbit에서 remote code execution(RCE), 환경 변수 및 민감 정보 유출, 100만개가 넘는 레포지토리 Read/Write 권한 확보라는 중대한 문제가 확인됨
  • 이 글은 Black Hat USA에서 발표된 공개 취약점 내용의 상세 분석을 담고 있으며, 코드형 리뷰 도구와 연동 시스템 취약점의 실사례로 참고 가치가 높음
  • 보고된 취약점은 신고 직후 빠르게 패치됨

CodeRabbit 개요

  • CodeRabbit은 GitHub/GitLab Marketplace에서 가장 많이 설치된 AI 기반 코드 리뷰 앱임
  • 양대 플랫폼에서 100만개 레포 및 500만 pull request를 리뷰함
  • 사용자가 PR을 생성 또는 갱신할 때마다, AI 엔진이 코드를 분석해 코멘트와 제안을 자동 생성함
  • 코드 요약, 보안 취약점 탐지, 개선점 제시, 다이어그램 생성 등 개발 생산성 향상 효과가 큼

CodeRabbit 사용 및 권한 구조

  • Pro 플랜은 linter·SAST(정적 분석) 도구 연동 기능을 제공함
  • GitHub 계정 인증 및 앱 설치 시 선택한 레포지토리에 읽기/쓰기 권한을 부여하게 됨
  • 이 권한 관리가 만약 악용된다면, 설치된 모든 레포의 코드에 직접적인 영향을 끼칠 수 있음

외부 도구 실행 및 익스플로잇 발견

  • CodeRabbit은 PR 내 코드 변경을 감지하면 다수의 외부 정적분석 도구(예: Rubocop) 를 자동 실행함
  • Rubocop은 .rubocop.yml 설정파일을 사용해 외부 Ruby 확장파일(ext.rb 등) 을 로드할 수 있게 설계됨
    • 공격자는 .rubocop.yml 및 ext.rb에 악성코드를 삽입 후 PR을 제출, CodeRabbit이 원격 서버에서 해당 코드를 실행하도록 유도
  • 이 기법으로 실행된 코드가 서버의 모든 환경변수를 공격자의 서버로 전송함

환경 변수 유출 내용 분석

  • 유출된 환경 변수에는 다음과 같은 다양한 서비스의 API Key, 토큰, 암호 등이 포함되어 있었음
    • Anthropic/OpenAI API 키, Encryption salt/password, GitHub App 프라이빗 키, PostgreSQL 접속정보 등
  • RCE를 통해 데이터베이스 접근, 코드 변경, 서비스 내부 정보 유출 등 2차 피해가 크고 파급력이 높음
  • 실서버에서 악의적 탐색을 더 진행할 수 있었으나, 서비스 운영을 고려해 최소한만 확인 후 중단

100만개 레포지토리 Read/Write 권한 획득

  • 환경 변수에 포함된 GITHUB_APP_PEM_FILE(프라이빗 키) 를 이용해 GitHub API에 인증 가능
  • CodeRabbit이 접근 가능한 모든 저장소(퍼블릭/프라이빗 포함)에 대해
    • 소스코드 읽기/쓰기, 릴리즈 파일 대체(공급망 공격), git 이력 변경 등 매우 강력한 권한 행사 가능
  • 재현 코드(PoC) 가 공개되어 실제로 악용 가능성이 입증됨

PoC 요약

  • PyGitHub 등의 라이브러리를 사용하여 유출된 프라이빗 키, App ID 등으로 임의의 레포지토리 액세스 토큰을 발급
  • 이 토큰을 통해 프라이빗 레포지토리 복제, 파일 변경, 신규 커밋, 릴리즈 파일 변조 등이 자동화 가능함

CodeRabbit 사내/비공개 레포지토리 침해 가능성

  • CodeRabbit 조직 역시 자사 서비스에 설치하여 사용 중이므로, CodeRabbit의 내부 소스코드 레포삭 접근 및 복제도 가능했음
  • 조직 이름만 알면 설치 ID 조회 후 곧바로 해당 레포 목록에 접근하는 것이 가능함

영향 요약

  • 프라이빗 레포지토리 무단 접근·개인정보 유출
  • 소스코드 조작, 악성코드/백도어 삽입 등 공급망 공격 위협
  • GitHub 액션 등의 추가 취약점 연계 가능성
  • 직접적 RCE로 인한 데이터 파괴, 서비스 마비, 타 서비스 연쇄 피해 초래

맥락과 AI 판단의 한계

  • 공격 중에도 PR 자체는 CodeRabbit에 의해 정상적으로 리뷰되고, 취약점 경고 코멘트를 남기긴 했으나 실제로는 위협 구문을 식별하지 못함
  • "AI 코드 리뷰 도구"가 실제 위험상황 맥락까지 파악하진 못한다는 점을 보여줌

대응 및 권고사항

  • CodeRabbit은 취약점 신고 수시간 내 Rubocop 비활성화, 비밀 정보 교체, 시스템 감사를 수행함
  • 샌드박스 미 적용 도구(Rubocop)에서 문제 발생, 조치 후 모든 외부 도구를 격리 환경에서 실행하도록 개선
  • 보안 강화를 위해, 외부 도구 실행환경에 환경 변수 최소화, 네트워크 접근 IP 제한, 인터넷 접근 차단 등 방어적 설계 필요성 강조

책임 있는 공개와 결론

  • 2025년 1월, 신고 후 신속한 대응과 조치가 이루어짐
  • PoC만으로 그쳤으나, 악의적 공격자라면 고가치 레포 선별, 대규모 랜섬웨어, 파괴적 공급망 공격 등에 쉽게 악용 가능성 확인
  • 외부 분석 도구·AI 기반 자동화 서비스와 연계 시, 샌드박스 및 최소 권한 원칙 구현의 중요성이 재확인됨
▲
GN⁺ 6일전  [-]
Hacker News 의견

  • 오 이런, 정말 심각한 취약점임. 이번에 수정됐다니 다행이지만, 처음에 이런 문제가 있었던 것 자체가 문제임. 클라우드 플랫폼에서 사용자 코드를 분석하는 시스템을 만들 때 가장 기본 규칙은 분석기는 반드시 격리된 환경에서 실행해야 한다는 것임. 플러그인을 통해 직접 코드 주입이 일어날 수 있고, linter/분석기/컴파일러는 복잡한 소프트웨어로서 취약점 표면적이 넓음. 임의의 저장소에 이런 도구를 공유 환경에서 실행하는 것이 위험하지 않다고 가정해서는 절대 안 된다고 생각함. 나도 코드 분석 플랫폼을 운영했는데, 고객 저장소에 우리가 직접 개발한 분석기를 돌릴 때도 샌드박스 환경에서 동작하도록 설계함. 환경 변수나 네트워크 요청 권한도 포함하지 않았지만, 분석은 샌드박스에서만 실행됨. 코드 분석을 안전하게 하는 유일한 방법임
    https://github.com/getgrit/gritql

  • Coderabbit 유료 구독을 해지함. 기업이 문제를 인정하기 위해 HN에서 바이럴하게 퍼질 정도가 돼야 하는 상황이 늘 걱정임. 공식 블로그 어디에도 이번 취약점에 대한 언급이 없고, 오늘 새로운 글도 없음. 실수는 누구나 할 수 있다고 생각하지만, 이런 일이 생겼을 때 투명하게 공개하지 않는 점이 기업 이미지를 훼손한다고 봄

    • https://coderabbit.ai/blog/…
    • 두 기사 모두 오늘 올라왔음. 보기에 연구팀과 coderabbit이 동시에 공개하기로 합의한 것 같음. 이런 동시 공개는 고객 데이터 유출이나 정황 증거가 없는 한 반드시 해야만 하는 게 아니라, 업체가 굳이 공개하겠다고 하는 경우에 종종 있는 관행임. 보안 연구원들이 대응을 칭찬하고 있다는 건 좋은 신호로 보임
    • 대다수 보안 버그는 별다른 공지 없이 조용히 해결됨. 만약 고객 정보 유출이 없다면(그리고 그건 보통 확인 가능함), 법적으로 공개가 강제되지 않음. 굳이 공개할 이점이 없는데, 왜 꼭 그래야 한다고 생각하는지 모르겠음

  • "익스플로잇이 실행되는 동안 CodeRabbit이 직접 PR에 위험 경고 댓글을 남기는 데, 실상은 그 PR을 실행하면서 해킹이 일어난 상황"이 정말 기이함. AI가 자신이 해킹당하고 있다고 이야기하는 세상에 살고 있는 현실이 이질적으로 느껴짐. 또한, CodeRabbit 팀이 재빠르게 대응하기는 했지만, '다른 업체들은 조사 연락에도 전혀 답변하지 않았고, 여전히 취약하다'는 점이 더 걱정스러움. CodeRabbit 팀에게는 박수를 보내지만, 모두 조심해서 움직여야 할 것임

    • CodeRabbit이 자기 시스템에서 실행된 익스플로잇을 자기 스스로 리뷰한 모습이 재밌음
    • 사실 실제로는 anthropic 모델이 익스플로잇을 말해준 거고, coderabbit 시스템은 무시한 셈임
    • 결국 AI가 똑똑한 게 아니라, 그냥 잘 맞추는 추론 시스템이라는 사실을 또 한번 보여줌

  • CEO 공식 입장문 일부에서 "Rubocop이 샌드박스 환경 밖에서 돌아서 문제가 됐다"고 하는데, 솔직히 좀 의심스러움. 왜 특정 하나만 완전히 다르게 동작했으며, 그게 하필 뚫린 작업임?

    • 왜 거짓말로 보이는지 모르겠음. 이런 실수는 흔하게 발생함
    • 애초에 Kudelski Security 쪽 연구자들이 여러 정적 분석 도구를 시도해봤을 확률이 높음. Rubocop만 독특하게 작동한 것. 기사에서도 다양한 접근 시도 흔적이 나타남
    • "왜 어떤 작업만 다르게 구성되어 있었는지" → 누군가 실수한 것. 이런 일은 있을 수 있음. "왜 뚫린 서비스가 하필 뚫렸냐"라는 질문에는, 취약한 서비스가 공격당하는 게 오히려 자연스러운 시나리오라고 생각함

  • 정말 흥미로운 글이었지만, 사실 놀라울 일도 아님. 사용자들이 아무 생각 없이 권한이 넓은 앱을 잔뜩 추가하고, github 권한 시스템도 문제라 이런 일은 필연적으로 일어날 수밖에 없었음. 많은 사람들이 github 앱의 저장소 쓰기 권한, 클라우드 권한까지 남용적으로 허용함. 브랜치 보호가 있어도, pull request를 통해 github actions에서 특권 접근이 가능함. 제대로 설정하려면 github oidc audience를 수정해야 하고, 문서화도 잘 안 되어있음. 앱 개발사에 권한을 줄이고 일부 기능을 비활성화한 별도 버전을 만들어달라고 요청해도 대부분 관심도 없고, 보안 문제를 이해하지 못함. github에서 앱 접근 권한을 더 세분화할 수 있게 해야 하며, 전반적으로 권한 자체가 더 세분화되어야 함

  • 정말 충격적임. 아직 글을 다 읽지도 못했는데, 너무 많아서 정신이 혼미해짐. 해커가 10만~100만 단위의 오픈소스툴/라이브러리/소프트웨어 배포 파일에 멀웨어를 심을 수 있었다는 대목에서는 세상이 멸망할 수도 있었단 생각까지 듦. 앞으로 얼마나 많은 유사한 문제가 남아있을지 상상조차 하기 어려움

    • 이제 'Github Apps' 자체가 위험하다는 생각이 듦. CodeRabbit이 안 뚫렸다고 해도, 이런 업체가 항상 성실하게 행동할 거라는 보장이 어디에 있음? 내부 직원이 악의적 행동을 하지 않는다고 누가 보장할 수 있음? 일반 SaaS에서 개인정보 관리는 한 가지 차원인데, 여기는 타깃형 공급망 공격의 키를 쥐고 있어서 대혼란을 초래할 수 있음
    • 소프트웨어 업계에도 최소한의 안전장치나 규제가 도입되어야 함. 지금처럼 아무나 아무 실수나 저질러도 아무 책임도 없는 상태는 정말 비정상적임

  • 이런 심각한 보안 실패는 "침해사고" 또는 "사건"으로 분류되어, 언론을 통해 의무적으로 공개하라고 해야 한다고 생각함. 7,000여 고객, 100만개 저장소에 접근할 수 있는 도구가, 기껏해야 11살짜리도 만들 수 있는 단순 익스플로잇에 뚫렸다는 사실임. 이렇게 쉬운 해킹이라면 bot, 블랙햇, APT 등이 이미 침투해서 은밀히 자리 잡았을 가능성이 크다고 볼 수 있음. 화이트헷이 공개하기 전 이미 들어와 있었다면, 취약점 패치는 새로운 공격자를 막을 뿐, 이미 잠입해 있는 존재는 퇴치되지 않을 수도 있음. 보안 어려운 건 알지만, 정말 정신 차려야 한다고 말하고 싶음

    • "의무 공개해야 한다"면 Cyber Resilience Act를 참고할 수 있음
    • Code Rabbit은 'vibe coder' 회사인데, 기대할 게 뭔지 모르겠음. 보안 사고를 숨기고, 구글 클라우드 블로그에도 마케팅 글만 올려서 해킹 사실도 언급 안 하고, 여전히 백도어 없는 증거도 못 주는 상황임
    • 나 같은 일반 사용자는, 이렇게 복잡하고 강력한 서비스가 실수로 모든 소중한 데이터를 외부로 유출시킬 수 있다는 사실에 앞으로 이런 걸 계속 써야 하는지 고민하게 됨. 조직이나 정부, 은행 외주 등 수많은 곳에서 이런 앱이 쓰이는데, T&C만 동의하면 제3자 접근권을 넘기는 구조임. >>“모든 회사에 이런 일이 생길 수 있다는 안심 문구”<<는 제공자는 위로하지만 사용자에겐 더 큰 걱정거리가 됨

  • 문제 중 하나는 각종 코드 분석기, 번들러, 컴파일러(예: Rust 컴파일러 등)는 아무 경고 없이 임의 코드를 실행할 수 있다는 점임. 예를 들어, 해커가 채용과제라면서 저장소를 하나 보내고, 내가 “npm install”이나 Rust 컴파일 명령을 실행하면 내 컴퓨터가 곧바로 해커 손에 넘어갈 수 있음. 혹은 회사 동료 한 명 PC가 해킹당해 악성코드가 저장소에 들어가면, 결국 글로벌 대기업 전체가 외국 해커에 점령당하는 상황도 가능함. 이런 구조를 만든 건 npm과 Rust 컴파일러임. 이런 툴들은 외부 명령 실행 때마다 명시적 확인을 요청하는게 필요함(명령 허용목록을 캐시해 묻지 않게 할 수는 있음). 리눅스도 개발자가 쉽게 쓸 수 있는 안전한 샌드박스를 제공해야 하는데, 지금은 일일이 직접 만들어야만 함. 게다가, JS 패키지 설치 등 경우에 따라 외부 코드 실행이 필요하지 않은 작업도 있음. 그리고 환경변수로 비밀과 설정을 넣는 건 정말 나쁜 방법임. "12-factor app"을 만든 사람은 커맨드라인 스위치나 설정 파일이 있다는 걸 모르는 것 같음

    • 코드 분석기/빌더/linter를 저장소에 돌리는 건, 원본 코드 자체를 그냥 실행하는 것보다 결코 더 안전하지 않음을 항상 인지해야 함
    • Rust 컴파일러(및 LLVM 기반 컴파일러)는 임의코드 실행 취약점이 있다고 가정하는 게 안전함. 하지만 공식적으로는 build system인 cargo에만 해당하는 기능이고, rustc(컴파일러 자체)는 아님
    • 환경변수 대신 커맨드라인/설정파일 쓰면 프로세스 테이블에서 값이 노출됨. "ps" 명령만 해도 모든 정보가 다 보이는 문제임
    • "절대 실행되지 않는 가치 있는 코드가 있을 거란 암시"가 재밌음
    • "모든 외부 커맨드 실행 때마다 명시적으로 확인"하는 방식은 소용없음. 문제는 외부 명령이 아니라 임의 코드 자체 실행이기 때문임. 이런 코드는 모든 시스템 API, syscall에 접근 가능하므로 확인할 방법이 없음. Python/pip도 동일한 문제를 갖고 있으니 이미 늦었다고 봄

  • "원하는 대로 github 앱이 될 수 있는" 권한 열쇠(프라이빗 키)가 환경 변수에 보관됐던 건 정말 최악의 관행임. 누구나 해킹당할 수는 있지만, 이건 비밀 관리의 가장 기본 중 기본임. github 공식 문서에도 환경 변수에 프라이빗 키를 넣지 말라고 분명히 나와있음. 정말 기초 중의 기초임
    https://docs.github.com/en/apps/…

    • 만약 비밀이 서명을 위한 게 아니라면, 결국은 vault에서 앱으로 가져와야 하기 때문에 프로덕션 시스템에 접근할 수 있다는 건 곧 그 비밀에도 접근할 수 있다는 뜻임. 물론 신뢰할 수 없는 코드 실행 상황에서는 환경을 격리하고, 이런 키를 전달하지 않아야 했지만, 보통은 흔하지 않은 케이스임
    • CodeRabbit의 Howon임. 우리는 앱 비밀 정보용으로 클라우드 제공업체의 key vault를 사용하고, GH private key도 포함되어 있음

  • Rubocop 설정 파일로 확장 Ruby 파일 경로를 지정할 수 있다는 문구를 읽는 순간 "설마 사용자 확장 도구를 프로덕션 환경에 직접 돌린 건가..." 했는데, 아니나 다를까 실제였음. 물론 이런 구멍 하나만 막았다고 제대로 안전한 건 아님. 대부분 linter가 공격적 입력에 대해 감사를 받거나 퍼징이 된 것도 드물텐데, 이건 그냥 문 열어두고 “해킹해 주세요!”라는 네온사인을 켜둔 격임

    • CEO의 공식 답변에 나온 “Rubocop이 샌드박스 밖에서 돌아갔다”는 부분을 보면, 그게 진짜 문제의 핵심은 아닌 거 같음
답변달기