---
title: "Forgejo에서 RCE까지 이어지는 취약점 사슬이 발견됐다는 공개 압박"
published: 2026-04-28T22:14:29.000Z
canonical: https://jeff.news/article/1961
---
# Forgejo에서 RCE까지 이어지는 취약점 사슬이 발견됐다는 공개 압박

보안 연구자가 Fedora의 Forgejo 전환을 계기로 코드를 살펴보다가 SSRF, 인증 결함, DoS, 정보 유출, TOCTOU 등 여러 취약점을 발견했고 일부를 묶어 RCE와 OAuth2 권한 상승까지 만들 수 있었다고 밝혔다. 그는 세부 익스플로잇을 바로 공개하지 않고, 취약함을 입증하는 출력만 공개해 프로젝트가 전체 보안 감사를 하도록 압박하는 'carrot disclosure' 방식을 택했다.

- 보안 연구자가 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 권한 상승까지 가능했다고 주장함
  - 단일 버그 하나가 아니라 여러 허점이 이어지는 “취약점 사슬” 쪽이라 운영자 입장에선 더 찝찝함

> [!WARNING]
> 글쓴이 주장대로라면 Forgejo 인스턴스에서 공개 가입과 특정 비기본 설정이 켜진 경우 RCE 체인이 성립할 수 있음. Forgejo를 직접 운영 중이면 가입 정책과 위험한 옵션부터 확인하는 게 맞음.

- 다만 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 설정 점검, 외부 요청 기능 제한 같은 완화책이 우선순위가 돼요.

## 핵심 포인트

- Forgejo 코드베이스에서 SSRF, CSP 부재, 암호화 오용, 인증 처리 문제 등 다양한 보안 문제가 발견됐다고 주장한다
- 일부 취약점 체인은 오픈 가입과 비기본 설정 옵션이 필요하지만, 실제 일부 인스턴스에는 해당 설정이 있었다고 한다
- 연구자는 개별 버그 패치보다 전체적인 보안 감사가 필요하다고 보고 carrot disclosure를 선택했다
- carrot disclosure는 익스플로잇 세부사항 대신 취약함을 증명하는 결과만 공개해 벤더의 구조적 개선을 유도하는 방식이다

## 인사이트

Forgejo는 Gitea/Gogs 계열을 물려받은 코드베이스라 자체 잘못만으로 보긴 어렵지만, 공용 Git 호스팅 인프라가 인증·OAuth·세션·SSRF 문제를 동시에 안고 있다면 운영자 입장에선 꽤 민감한 신호다. 특히 사내 Forgejo를 직접 운영하는 팀은 공개 가입, OAuth 설정, 외부 URL 접근 경로부터 점검할 이유가 충분하다.