사내 Git 서버 하나가 조직 전체의 실행 권한을 쥐고 있다면 — Gitea CVE-2026-60004

이미지 출처: CISA KEV

회사에서 GitHub 대신 Gitea를 쓰는 팀이 생각보다 많음. 가볍고, 바이너리 하나로 뜨고, 라이선스 부담도 없어서 스타트업이나 사내망 개발팀이 자체 호스팅으로 올려두는 경우가 흔함. 그런데 그 "가볍게 올려둔" 서버가 조직의 모든 소스코드와 CI 파이프라인의 출발점이라는 걸 잊기 쉬움. CVE-2026-60004는 그 지점을 정확히 찌르는 코드 인젝션 계열 취약점임.

핵심 요약

• Gitea에서 보고된 코드 인젝션 취약점으로, 신뢰되지 않은 입력이 서버 측에서 실행 가능한 문맥으로 흘러 들어가는 구조가 문제의 핵심임
• Git 서버는 소스코드·CI 러너·배포 자격증명이 한곳에 모이는 지점이라, 단일 취약점이 곧바로 공급망 침해로 번질 수 있음
• 대응은 최신 버전 업그레이드가 1순위이고, 그 전까지는 익명 가입 차단·러너 격리·프로세스 실행 로그 감시로 시간을 벌어야 함

1. 코드 인젝션이 Git 서버에서 유독 위험한 이유

코드 인젝션이라는 말 자체는 넓음. 사용자가 넣은 문자열이 어딘가에서 코드나 명령으로 해석되면 전부 여기에 들어감. 웹 애플리케이션이라면 대개 "그 웹 프로세스 권한까지" 로 피해가 끝나지만, Git 서버는 사정이 다름.

• Git 서버 프로세스는 저장소 파일 시스템에 대한 광범위한 접근 권한을 가짐
• 웹훅·CI 러너 등록 토큰·배포 키·패키지 레지스트리 자격증명이 같은 인스턴스 안에 저장돼 있음
• 서버가 실행하는 훅 스크립트, 미러링, 아카이브 생성 같은 기능은 원래부터 외부 프로세스를 호출하는 구조임

즉 인젝션 한 방으로 "코드 한 줄 실행"에서 끝나지 않고, 저장소 내용 변조 → CI 러너가 그 코드를 받아 빌드 → 산출물이 운영 환경으로 배포되는 흐름이 자연스럽게 이어짐. 공급망 공격 시나리오에서 Git 서버가 늘 1순위 표적으로 꼽히는 이유가 이것임.

2. 이 취약점을 개념적으로 어떻게 이해할 것인가

구체적인 페이로드는 다루지 않지만, 구조는 이해해 둘 필요가 있음. Gitea 같은 서버에서 인젝션이 생기는 자리는 대체로 정해져 있음.

• 템플릿 렌더링 경로 — 저장소 설명, 이슈 본문, 릴리스 노트처럼 사용자가 자유롭게 넣는 문자열이 템플릿 엔진을 거칠 때
• 외부 명령 조립 구간 — 브랜치명·태그명·파일 경로가 그대로 셸이나 git 하위 명령의 인자로 이어붙여질 때
• 웹훅·마이그레이션 설정 — 사용자가 지정한 URL이나 인증 정보가 서버 내부에서 요청 문자열로 재조립될 때

공통점은 하나임. "사용자가 통제하는 문자열"과 "서버가 해석하는 구문"이 같은 버퍼 안에서 섞이는 순간 취약점이 생김. 방어 코드는 언제나 이 둘을 분리하는 방향으로 짜여야 함 — 이스케이프가 아니라 애초에 인자 배열로 넘기고, 템플릿에는 데이터만 넣고, 화이트리스트로 형식을 강제하는 식임.

3. 우리 조직이 노출돼 있는지 먼저 확인

패치 이야기를 하기 전에, 자산 파악이 먼저임. 의외로 "우리가 Gitea를 쓰고 있었나?" 하는 조직이 많음. 옛날에 누군가 테스트용으로 띄워놓고 그대로 방치된 인스턴스가 사고의 진원지가 되는 경우를 여러 번 봤음.

• 내부망 대역에서 3000번 포트 및 HTTP 응답의 Gitea 문자열, /api/v1/version 엔드포인트로 인스턴스와 버전을 식별
• 리버스 프록시 뒤에 숨어 있는 경우가 많으므로 nginx·Traefik 설정 파일에서 업스트림 목록을 함께 훑기
• 컨테이너 환경이라면 이미지 태그 기준으로 조회 — 다만 latest 태그로 몇 년째 고정돼 있는 인스턴스가 진짜 위험한 쪽임
• 인터넷에 노출된 인스턴스가 있는지, 외부 스캔 관점에서도 한 번 확인

4. 완화 조치 — 패치 전후로 나눠서

가장 확실한 답은 벤더가 공지한 수정 버전으로 올리는 것임. Gitea는 릴리스 주기가 빠른 편이고 보안 수정이 마이너 버전에 함께 실려 나오는 경우가 많으니, 릴리스 노트의 보안 항목을 확인하고 계획을 잡는 게 좋음. 다만 사내 Git 서버는 "지금 당장 재시작하면 개발팀 전체가 멈춘다"는 이유로 미뤄지기 쉬움. 그 사이를 메울 조치들이 있음.

• 익명 가입 차단 — DISABLE_REGISTRATION을 켜서 임의 계정 생성을 막음. 인증 후 공격이 필요한 취약점이라면 이것만으로도 공격면이 크게 줄어듦
• 인터넷 직접 노출 제거 — VPN이나 SSO 프록시 뒤로 넣기. Git 서버가 공개 IP에 그대로 떠 있을 이유는 거의 없음
• CI 러너 분리 — 러너를 Git 서버와 같은 호스트에 두지 말 것. 러너 등록 토큰의 유효 범위도 저장소 단위로 좁히기
• 실행 권한 최소화 — Gitea 프로세스를 전용 계정으로 돌리고, 컨테이너라면 불필요한 셸·컴파일러를 뺀 이미지를 쓰기
• 웹훅 아웃바운드 제한 — 허용 호스트 목록을 설정해 내부망 임의 주소로의 요청을 막기(SSRF 연계 차단 효과도 있음)

5. 탐지 — 무엇을 로그로 볼 것인가

패치는 언젠가 되지만, "이미 당했는지"를 보는 건 별개 작업임. 코드 인젝션의 최종 목적은 결국 서버에서 뭔가를 실행하는 것이니, 탐지 포인트도 실행 흔적에 맞춰야 함.

• 프로세스 계보 감시 — Gitea 프로세스가 git 외의 자식 프로세스(sh, bash, curl, wget, 스크립트 인터프리터)를 띄우는 이벤트를 우선순위 높은 경보로 잡기. 정상 운영에서는 거의 발생하지 않는 패턴임
• 아웃바운드 연결 — Git 서버가 외부로 새로 여는 연결. 미러링·웹훅 대상 외의 목적지는 전부 조사 대상
• 저장소 훅 디렉터리 변경 — hooks/ 아래 파일의 생성·수정 시각을 파일 무결성 모니터링으로 감시. 지속성 확보에 자주 쓰이는 자리임
• 관리자 권한·토큰 발급 이벤트 — 새 액세스 토큰, 새 배포 키, 새 러너 등록. 특히 업무 시간 외 발생 건
• 비정상 요청 패턴 — 저장소 이름·브랜치명·설명 필드에 유난히 긴 문자열이나 구문 기호가 몰려 있는 요청. 리버스 프록시 액세스 로그에서 걸러내기 좋음

6. 사고가 의심될 때의 순서

실행 흔적이 잡혔다면 판단을 미루지 않는 게 좋음. Git 서버 침해는 시간이 지날수록 "어느 커밋부터 믿을 수 있는가"를 되짚기가 어려워짐.

• 서버를 즉시 폐기하지 말고 메모리와 디스크 이미지를 먼저 확보 — 인젝션 흔적은 로그보다 프로세스 메모리에 남는 경우가 많음
• 모든 액세스 토큰·배포 키·러너 등록 토큰·웹훅 시크릿을 일괄 폐기하고 재발급
• 의심 시점 이후의 커밋 서명과 해시를 별도 보관본과 대조. 서명 커밋 정책을 안 쓰고 있었다면 이번 기회에 도입 검토
• 해당 서버가 배포한 아티팩트 목록을 뽑아 재빌드 범위를 정하기

마무리

Git 서버 취약점 소식을 보면 "우리는 내부망이라 괜찮다"는 반응이 제일 먼저 나오는데, 개인적으로는 그 말이 가장 위험한 신호라고 생각함. 내부망에 있다는 건 곧 일단 뚫리면 아무도 안 보고 있다는 뜻이기도 하니 말임. 오히려 조용한 곳일수록 프로세스 계보 로그 하나 걸어두는 게 값어치가 큼.

오늘 할 일은 단순함. 우리 조직에 Gitea 인스턴스가 몇 개 떠 있는지 목록부터 뽑아보기. 그리고 그중 마지막으로 업데이트한 날짜를 확인해보기. 그 숫자가 예상보다 오래됐다면, 이 글의 4번과 5번을 순서대로 적용하면 됨. 각자 환경에서 걸어둔 탐지 룰이 있다면 댓글로 공유해 주세요. 같이 다듬어보아요!