파일 이름에 점 두 개가 들어가는 순간 — GitLab CVE-2026-85706 경로 조작 취약점, 방어자가 먼저 볼 곳

이미지 출처: CISA KEV

회사에서 소스코드 저장소로 GitLab을 쓰는 곳이라면, 그 서버 한 대에 회사의 거의 모든 것이 들어 있다고 봐도 과언이 아님. 코드, CI/CD 파이프라인, 배포 키, 이슈에 적힌 내부 사정까지 전부 그 안에 있음. 그래서 GitLab에 경로 조작(Path Traversal) 취약점이 등록됐다는 소식은 단순히 "파일 하나 읽힐 수 있음" 정도로 넘길 문제가 아니라고 생각함. 이번에 NVD에 올라온 CVE-2026-85706은 GitLab Community Edition과 Enterprise Edition 양쪽에 모두 해당하는 건이라, 무료판 쓴다고 안심할 수도 없는 상황임.

핵심 요약

• GitLab CE/EE에서 파일 경로를 처리하는 과정에 경로 조작(Path Traversal) 취약점이 확인됨. 의도한 디렉터리 바깥의 파일에 접근할 가능성이 있음.
• 방어의 핵심은 패치 버전으로 빠르게 올리는 것이고, 당장 어렵다면 외부 노출 차단·WAF 규칙·로그 모니터링으로 시간을 버는 것임.
• 탐지는 요청 로그에서 ../ 계열 패턴과 인코딩 변형을 찾는 것부터 시작하면 됨.

1. 경로 조작 취약점이 뭔지, 왜 GitLab에서는 더 무서운지

경로 조작은 이름 그대로임. 프로그램이 "이 폴더 안의 파일만 열어줄게"라고 설계돼 있는데, 사용자가 파일 이름에 ../ 같은 상위 디렉터리 이동 문자를 섞어 넣으면 프로그램이 그걸 걸러내지 못하고 폴더 바깥으로 나가버리는 것임. 개념 자체는 웹 해킹 입문서 첫 장에 나올 정도로 오래됐지만, 지금도 계속 새 CVE가 나오는 이유는 파일 경로를 다루는 지점이 애플리케이션마다 너무 많기 때문임. 업로드, 아티팩트 다운로드, 저장소 내보내기/가져오기, 위키 첨부파일 등 GitLab만 해도 경로를 조립하는 코드가 셀 수 없이 많음.

GitLab에서 경로 조작이 특히 위험한 이유는 서버 안에 놓인 파일들의 성격 때문임. 예를 들어 다음과 같은 것들이 같은 호스트에 존재함.

• 애플리케이션 설정 파일(데이터베이스 접속 정보, 시크릿 키 등)
• CI/CD 러너 토큰과 파이프라인 변수
• 다른 프로젝트의 저장소 데이터와 아티팩트
• 백업 파일과 내보내기(export) 파일

즉, 경로 하나가 새는 순간 "파일 읽기"가 "권한 상승"과 "다른 프로젝트 정보 유출"로 곧바로 이어질 수 있는 구조임. 취약점의 세부 경로나 구체적인 트리거 조건은 벤더 권고문에 따라 확인해야 하지만, 방어자 입장에서는 "경로를 조립하는 기능이 외부 입력을 받는 곳"이 공격 표면이라고 이해하면 충분함.

2. 지금 당장 확인할 것: 우리 GitLab이 해당되는가

개인적으로는 CVE 소식을 들었을 때 가장 먼저 하는 일이 "우리 버전이 뭐지?"를 확인하는 것임. 생각보다 많은 조직이 GitLab을 한 번 설치해 두고 버전을 몇 년째 안 올리는 경우가 많음. 확인 방법은 간단함.

• 관리자 계정으로 로그인해서 Admin Area > Overview에서 버전 확인
• Omnibus 설치라면 서버에서 gitlab-rake gitlab:env:info 실행
• API로는 /api/v4/version 엔드포인트 호출(인증 필요)

GitLab은 보통 보안 릴리스를 여러 마이너 버전 라인에 동시에 내놓기 때문에, 자기 버전이 어느 라인에 있는지 파악한 뒤 공식 보안 릴리스 공지에서 해당 라인의 패치 버전을 찾아 올리는 것이 정석임. 정확한 영향 범위와 수정 버전 번호는 GitLab 보안 릴리스 블로그와 NVD 항목을 함께 보고 판단해야 하고, 이 부분은 여기서 단정하지 않겠음.

3. 탐지: 로그에서 무엇을 찾아야 하는가

패치를 적용했더라도 "이미 당했는가"를 확인하는 작업이 남음. 경로 조작 공격은 다행히 로그에 흔적이 비교적 잘 남는 편임. 요청 경로나 파라미터에 이상한 문자열이 들어가야만 성립하는 공격이기 때문임.

• Nginx/워크호스 접근 로그에서 ../, ..\ 패턴을 검색. URL 인코딩된 형태인 %2e%2e%2f, 이중 인코딩 %252e%252e도 같이 찾아야 함.
• production_json.log에서 파일 관련 컨트롤러(업로드, 아티팩트, 리포지토리 파일 조회)에 대한 요청 중 파라미터에 상위 경로 이동 문자가 포함된 것 필터링.
• 평소 접근하지 않던 계정이 짧은 시간에 파일 관련 엔드포인트를 반복 호출한 기록. 자동화 스캐너는 대개 수십~수백 개 변형을 한꺼번에 던지기 때문에 요청 빈도 자체가 신호가 됨.
• 응답 코드 분포. 정상적인 사용자는 200과 404가 섞이지만, 경로 탐색 시도는 403/404가 연속으로 쌓이다가 갑자기 200이 하나 튀는 패턴이 나타남. 그 200 하나가 성공한 요청일 가능성이 높음.

SIEM을 운용 중이라면 위 패턴을 룰로 만들어 두는 것을 추천함. 이번 건뿐 아니라 앞으로 나올 비슷한 유형의 취약점에도 그대로 재사용할 수 있어서, 한 번 만들어 두면 두고두고 도움이 됨.

4. 완화: 패치가 당장 어려울 때 시간 버는 법

현실적으로 GitLab 업그레이드는 "지금 바로"가 안 되는 경우가 많음. 대규모 저장소, 커스텀 러너 구성, 마이그레이션 시간 등 걸리는 게 많다보니 며칠 정도 여유가 필요할 때가 있음. 그 기간 동안 할 수 있는 것들을 정리해 봄.

• 외부 노출 최소화: GitLab이 인터넷에 직접 열려 있다면 VPN 뒤로 옮기거나 최소한 IP 허용 목록을 적용. 내부 개발자만 쓰는 서버가 공인 IP에 그대로 열려 있는 경우가 의외로 많음.
• WAF/리버스 프록시 규칙: 요청 경로와 쿼리스트링에 상위 디렉터리 이동 패턴(원본 및 인코딩 변형)이 포함되면 차단. 오탐 가능성이 있으니 처음에는 로깅 모드로 며칠 돌려보고 차단으로 전환하는 것이 안전함.
• 권한 최소화: GitLab 프로세스가 실행되는 OS 계정이 필요 이상의 파일에 읽기 권한을 갖고 있지 않은지 확인. 경로 조작이 성공하더라도 OS 레벨 권한이 막아주면 피해가 줄어듦.
• 시크릿 순환 준비: 침해 흔적이 발견되면 즉시 러너 토큰, 개인 액세스 토큰, 배포 키를 교체할 수 있도록 목록과 절차를 미리 만들어 두기.

이 완화책들은 어디까지나 임시방편이고, 근본 해결은 패치 버전으로 올리는 것이라는 점은 잊으면 안 됨. WAF 규칙은 우회 변형이 계속 나오기 때문에 영구적인 방어선이 될 수 없음.

5. 개발자 관점에서 배울 점

이 취약점을 "GitLab 문제"로만 보고 끝내면 아까움. 우리가 만드는 서비스에도 파일 경로를 조립하는 코드는 반드시 있고, 같은 실수를 하고 있을 가능성이 높음. 개인적으로 코드 리뷰할 때 꼭 보는 포인트는 이런 것들임.

• 사용자 입력이 경로에 들어간다면 정규화(normalize) 후 기준 디렉터리 안에 있는지 검증하는 코드가 있는가. 단순히 .. 문자열을 치환하는 방식은 인코딩 변형에 쉽게 뚫림.
• 파일 이름을 사용자 입력 그대로 쓰지 말고, 서버가 생성한 식별자(UUID 등)로 저장하고 원래 이름은 메타데이터로만 보관하는가.
• 아카이브(zip, tar) 해제 시 내부 항목 이름에 상위 경로가 포함된 경우를 거르는가. 이른바 zip slip 문제는 경로 조작의 사촌 격임.

결국 경로 조작은 "입력을 믿지 말라"는 오래된 원칙이 코드 한 줄에서 무너지면서 생기는 문제임. 오래된 원칙일수록 잊기 쉽다는 게 함정인 것 같음.

마무리

GitLab 서버는 회사의 두뇌 같은 존재라서, 여기서 파일 하나가 새는 것은 다른 서비스에서 파일 하나 새는 것과 무게가 다름. CVE-2026-85706 소식을 계기로 우리 GitLab 버전이 어디쯤 와 있는지, 인터넷에 직접 열려 있지는 않은지, 로그는 제대로 남고 있는지 한 번씩 점검해 보면 좋겠음. 패치 적용 과정에서 겪은 경험이나 탐지 룰 아이디어가 있다면 댓글로 공유해 주시면 저도 배우고 싶음. 같이 지켜 나가요!