무슨 일이 생긴 건가요
셀프호스팅 Git 서비스인 Forgejo가 16.0.4 버전을 릴리스하면서, 16.0.3 이하 버전 전체에 영향을 주는 '치명적(Critical)' 등급의 원격 코드 실행(RCE) 취약점을 고쳤다고 공지했어요. 취약점 등급 중 가장 높은 단계인 데다 영향 범위가 '이전 버전 전부'라서, Forgejo를 직접 운영하고 계신 분이라면 이 글을 다 읽기 전에 업데이트부터 하셔도 좋아요.
Forgejo가 뭐냐면, GitHub처럼 코드 저장소와 이슈, PR, CI(Actions)까지 제공하는 서비스인데 내 서버에 직접 설치해서 쓰는 오픈소스예요. 원래 Gitea라는 프로젝트에서 2022년 말에 갈라져 나왔고, 독일의 비영리 코드 호스팅 서비스 Codeberg가 실제로 이걸로 돌아가고 있거든요. Go로 만들어져서 바이너리 하나 혹은 도커 컨테이너 하나로 가볍게 띄울 수 있다 보니, 사내 코드를 외부 클라우드에 올리기 싫은 회사나 개인 홈서버에서 많이 쓰여요.
RCE가 뭐길래 이렇게 호들갑이냐면
원격 코드 실행, 그러니까 RCE는 공격자가 서버에 물리적으로든 SSH로든 접속하지 않고도, 네트워크 너머에서 서버가 자기 명령을 실행하게 만드는 취약점이에요. 비유하자면 문 앞에 서서 인터폰으로 말만 했는데 집 안의 사람이 그 말을 그대로 따라 하는 상황이랄까요. 웹 서비스에서 이게 터지면 서버 안에 있는 파일을 읽고, 쓰고, 다른 서버로 옮겨 다니는 것까지 전부 가능해져요.
그런데 Git 서버는 다른 웹 서비스보다 훨씬 위험한 대상이에요. 안에 있는 게 회사의 소스 코드 전체이고, 그 안에는 실수로 커밋된 API 키나 비밀번호가 섞여 있는 경우가 흔하거든요. 게다가 CI 러너가 붙어 있으면 배포용 자격 증명, 클라우드 토큰, 컨테이너 레지스트리 비밀번호까지 한곳에 모여 있어요. 소스 코드에 몰래 악성 커밋을 끼워 넣으면 그게 그대로 빌드되어 고객에게 배포되는 공급망 공격으로 번질 수도 있고요. 그래서 Git 서버의 RCE는 '서버 한 대 뚫림'이 아니라 '회사 전체가 뚫릴 수 있는 입구'로 봐야 해요.
기술적인 디테일은 아직 조심스럽게 공개 중
이번 릴리스 노트는 취약점의 등급과 영향 범위를 알리는 데 집중하고 있고, 정확한 공격 경로는 상세히 풀어놓지 않았어요. 보안 패치에서는 흔한 관행인데요, 관리자들이 업데이트할 시간을 벌어주기 위해 익스플로잇을 재현할 수 있는 정보는 일정 기간 뒤에 공개하는 거예요. 그래서 '정확히 어디가 뚫렸는지'는 CVE 상세 정보가 나오면 다시 확인하셔야 해요.
다만 Gitea와 Forgejo 계열에서 과거에 터졌던 RCE들의 패턴을 알아두면 이런 취약점이 어떤 식으로 생기는지 감을 잡을 수 있어요. 대표적인 게 Git 훅 기능이에요. 저장소에 push가 들어올 때 서버에서 스크립트를 실행하는 기능인데, 원래는 관리자만 쓸 수 있어야 하는 걸 권한 검증이 느슨해서 일반 사용자가 등록할 수 있게 되면 그게 바로 RCE가 돼요. 또 하나는 Git 명령어 인자 주입이에요. 서버가 내부적으로 git 명령을 실행하는데, 사용자가 입력한 브랜치 이름이나 URL이 검증 없이 인자로 들어가면 --upload-pack=악성명령 같은 옵션을 끼워 넣을 수 있거든요. 저장소 마이그레이션 기능에서 외부 URL을 가져오다가 내부 네트워크에 요청을 보내는 SSRF, 압축 파일을 풀다가 경로를 벗어나는 경로 탐색(path traversal)도 단골 메뉴예요. 이번 건이 이 중 하나일 수도, 전혀 새로운 유형일 수도 있지만, 공통점은 '사용자 입력이 서버의 실행 동작에 닿는 지점'이라는 거예요.
지금 당장 해야 할 일
첫째, 업데이트예요. 도커로 운영 중이면 이미지 태그를 16.0.4로 바꾸고 재시작하면 되고, 바이너리로 운영 중이면 새 바이너리로 교체하면 돼요. Forgejo는 장기 지원(LTS) 브랜치를 따로 운영하니까, LTS 계열을 쓰고 계시다면 해당 브랜치에 패치가 나왔는지도 릴리스 노트에서 꼭 확인하세요. 업데이트 전에 데이터베이스와 저장소 디렉터리 백업은 기본이고요.
둘째, 이미 뚫렸을 가능성을 점검하는 거예요. 서버를 공인 IP로 열어두고 계셨다면 특히요. 로그에서 낯선 IP의 이상한 요청, 모르는 사용자 계정, 갑자기 생긴 Git 훅이나 웹훅, 러너에 등록된 모르는 작업이 있는지 살펴보세요. 조금이라도 의심스러우면 저장소에 들어 있던 시크릿과 CI 변수는 전부 교체(rotate)하는 게 안전해요.
셋째, 이번 기회에 구조를 손보는 거예요. Forgejo 컨테이너를 root가 아닌 사용자로 돌리고, CI 러너는 별도 네트워크나 별도 머신에 격리하고, 외부 노출이 꼭 필요 없다면 VPN 뒤로 넣고, 회원가입 개방(open registration)은 꺼두는 것만으로도 피해 범위가 크게 줄어요. 그리고 Forgejo 보안 공지 RSS나 메일링 리스트를 구독해 두면 다음번엔 남보다 먼저 알 수 있어요.
셀프호스팅의 대가
이런 일이 Forgejo만의 문제는 아니에요. GitLab은 거의 매달 보안 패치를 내고 2024년 초에는 비밀번호 재설정 메일을 임의 주소로 보내 계정을 탈취하는 취약점이 있었고, GitHub Enterprise Server도 같은 해 SAML 인증 우회 취약점으로 만점에 가까운 위험도를 받았어요. Gitea 역시 Git 훅 관련 RCE를 여러 번 겪었고요. 셀프호스팅은 데이터를 내 손에 두는 대신 패치 책임도 내 손에 두는 선택이거든요. GitHub.com을 쓰면 GitHub이 새벽에 패치해 주지만, 내 서버는 내가 안 하면 아무도 안 해줘요.
국내에서는 보안 규정이나 비용 때문에 사내에 Gitea, GitLab, Forgejo를 직접 세워 쓰는 팀이 정말 많아요. 그런데 '설치한 사람이 퇴사하고 아무도 안 건드리는 서버'가 되어 버린 경우도 흔하죠. 이번 공지가 그런 서버를 한 번 점검해 보는 계기가 되었으면 해요. 버전 확인 한 줄이면 되니까요.
한 줄 정리: Forgejo 16.0.3 이하는 치명적 RCE에 노출되어 있으니 16.0.4로 지금 올리고, 외부에 노출됐던 서버라면 시크릿 교체까지 고려하세요.
여러분 팀의 셀프호스팅 Git 서버는 누가, 얼마나 자주 업데이트하고 있나요? 보안 패치를 자동화해서 굴리고 계신 분이 있다면 방법을 공유해 주세요.
🔗 출처: Hacker News