Forgejo에서 RCE까지 이어지는 취약점 사슬이 발견됐다는 공개 압박

• 보안 연구자가 Forgejo를 들여다봤다가 꽤 험한 결과를 봤다고 함

  • 계기는 Fedora가 Pagure에서 Forgejo로 이동한 것임
  • 연구자는 퇴근 후 어느 저녁에 살펴봤을 뿐인데 취약점을 꽤 많이 찾았다고 말함
  • 표현이 세긴 한데, “상태가 예쁘진 않다” 정도가 아니라 시스템 전반의 보안 체질을 문제 삼는 글임

• 언급된 취약점 종류가 한두 개가 아님

  • 여러 위치의 SSRF(Server-Side Request Forgery)
  • CSP(Content Security Policy)와 Trusted Types 부재
  • 자바스크립트 쪽의 어설픈 템플레이팅
  • 암호화 구현상의 나쁜 관행
  • OAuth2, OTP, 세션·접근 처리, 침해 이후 복구 같은 인증 메커니즘의 허점
  • 낮은 난이도의 DoS, 정보 유출, 여러 TOCTOU(Time-of-check to time-of-use) 문제까지 언급됨

• 더 큰 문제는 일부를 엮으면 RCE까지 간다는 주장임

  • 연구자는 과거 Gitea를 봤을 때 얻은 취약점까지 더해 여러 문제를 체인으로 묶었다고 함
  • 그 결과 완전한 RCE(Remote Code Execution), secret 유출, 지속적인 계정 접근, OAuth2 권한 상승까지 가능했다고 주장함
  • 단일 버그 하나가 아니라 여러 허점이 이어지는 “취약점 사슬” 쪽이라 운영자 입장에선 더 찝찝함

• 다만 RCE 체인은 조건이 있음

  • 공개 가입이 열려 있어야 함
  • 그리고 기본값이 아닌 특정 설정 옵션이 켜져 있어야 함
  • 연구자는 이 설정이 자신이 본 일부 인스턴스에 실제로 켜져 있었고, 아주 이국적인 설정은 아니라고 설명함
  • 그래서 “팔아먹을 가치가 큰 0-day”는 아니지만, 현실적인 배포 환경에서 완전히 무시할 수 있는 조건도 아니라는 뉘앙스임

• 연구자는 일반적인 책임 공개 대신 carrot disclosure를 택함

  • Forgejo에는 보안 정책이 있고, 연구자가 무엇을 해야 하고 하지 말아야 하는지 MUST/MUST NOT으로 적혀 있다고 함
  • 하지만 글쓴이는 코드베이스 상태가 구조적 문제라서 버그 하나씩 제보하고 고치는 방식은 끝없는 두더지 잡기라고 봄
  • Forgejo가 Gitea/Gogs 코드베이스를 물려받은 점도 언급하면서, 이게 전적으로 Forgejo 팀만의 잘못은 아니라고 덧붙임

• carrot disclosure는 취약점의 전체 레시피를 공개하지 않는 압박 방식임

  • 핵심 아이디어는 치명적 취약점의 익스플로잇 결과만 일부 가려서 공개하는 것임
  • 벤더에게 “실제로 뚫린다”는 신호를 주되, 바로 따라 할 수 있는 세부 절차는 공개하지 않음
  • 그 다음 선택지는 벤더가 전체 보안 감사를 해서 해당 취약점까지 고치길 바라거나, 사용자가 알려진 취약 소프트웨어 운영을 꺼리며 이탈하는 걸 감수하는 것임

• 이 글의 메시지는 “이 버그 하나 고쳐라”가 아니라 “전체적으로 다시 봐라”에 가까움

  • 연구자는 자신이 또 하루 저녁 투자하면 다른 취약점 체인을 찾을 가능성이 높다고 말함
  • 그래서 직접 하나씩 PR을 보내는 것도 별 의미가 없다고 판단함
  • 취약점 목록의 범위가 인증, 세션, OAuth, 브라우저 보안, 서버 요청, 경쟁 조건까지 걸쳐 있어 구조적 감사를 요구하는 쪽으로 읽힘

• 한국 개발자에게도 남 일은 아님

  • Forgejo는 자체 Git 호스팅이나 사내 코드 저장소로 검토될 수 있는 오픈소스 프로젝트임
  • 특히 공개 가입을 켜둔 인스턴스, OAuth 로그인을 붙인 인스턴스, 외부 URL 미리보기나 가져오기 기능을 쓰는 인스턴스는 공격면이 커짐
  • 당장 세부 익스플로잇이 공개된 건 아니지만, 운영자는 업스트림 보안 공지와 설정 하드닝을 계속 봐야 할 상황임

---

기술 맥락

• 이 글에서 중요한 건 취약점 하나의 이름보다 여러 약점이 체인으로 묶였다는 점이에요. SSRF, 인증 처리, 세션 유지, OAuth 권한 상승, 정보 유출이 따로 있으면 각각 중간 위험처럼 보여도, 조합되면 RCE나 장기 계정 접근으로 커질 수 있거든요.

• Forgejo 같은 Git 호스팅 서비스는 공격면이 원래 넓어요. 저장소 가져오기, 웹훅, OAuth, 이슈·PR 렌더링, 파일 미리보기, 사용자 가입처럼 외부 입력과 내부 권한이 계속 만나는 지점이 많아서 작은 검증 누락이 다른 기능과 이어지기 쉬워요.

• 연구자가 carrot disclosure를 택한 이유도 여기서 나와요. 개별 취약점 제보로는 당장 보이는 구멍 하나만 막고 끝날 수 있으니, 익스플로잇 결과를 보여줘서 프로젝트가 전체 감사를 하도록 압박하겠다는 접근이에요.

• 운영자 입장에서는 공개 가입 여부와 비기본 설정부터 보는 게 현실적인 첫 단계예요. 글에서 RCE 체인이 그 조건에 의존한다고 했으니, 패치가 나오기 전까지는 가입 제한, OAuth 설정 점검, 외부 요청 기능 제한 같은 완화책이 우선순위가 돼요.