GitLab 서버가 요청 한 번에 열렸다: CVSS 10.0 CVE-2026-85706, 셀프호스팅 즉시 패치

무슨 일이 있었나요?

GitLab의 셀프호스팅 서버에서 인증 없이 임의 파일을 읽을 수 있는 취약점이 드러났습니다. 취약점 번호는 CVE-2026-85706이고, 심각도는 최고 등급인 CVSS 10.0으로 평가됐습니다.

문제의 지점은 저장소 commits API입니다. 경로를 제대로 가두지 못하고 인증 강제도 빠져 있어서, 보안 연구 기관 분석에 따르면 /api/v4/projects/{id}/repository/commits/ 경로에 파일 경로 값을 담은 요청 한 번으로 서버 파일을 꺼낼 수 있었어요. GitLab은 공식 패치노트에서 이 결함을 두고 인증되지 않은 사용자가 임의 파일을 읽을 수 있었다고 설명했습니다. 악용 조건은 단순합니다. 공개 프로젝트가 하나 이상 존재하기만 하면 되죠.

대응 속도도 빨랐지만 공격 시도는 더 빨랐습니다. GitLab이 9월 10일 패치 버전을 배포하자, 바로 다음 날인 9월 11일 인터넷 전역에서 이 취약점을 노린 스캐닝과 프로빙이 관측됐습니다. 같은 날 미국 사이버보안·인프라보안청(CISA)은 이 취약점을 알려진 악용 취약점(KEV) 목록에 등재했어요.

왜 CVSS 10.0인가요?

세 가지 조건이 겹치면서 심각도가 최고 등급까지 올라갔습니다. 인증이 필요 없고, 원격에서 가능하며, 읽히는 파일이 곧바로 다음 침해로 이어진다는 점이죠.

먼저 인증 장벽이 없습니다. 로그인 계정이나 권한 없이도 외부에서 바로 요청을 보낼 수 있어요. 다음으로 읽히는 대상이 문제입니다. 단순한 문서가 아니라 로그 파일과 설정 파일이 열리는데, 여기에는 자격증명, SSH 키, 데이터베이스 비밀번호, 배포 토큰, CI/CD 변수 같은 열쇠들이 담겨 있죠. 공격자가 이 값을 손에 넣으면 GitLab 서버 한 대에서 끝나지 않습니다. 파이프라인이 연결된 배포 서버, 클라우드 계정, 다른 저장소로 침해가 번질 수 있어요. 파일 하나를 읽는 취약점이 사실상 인프라 전체로 통하는 열쇠 꾸러미가 되는 셈입니다.

우리 GitLab은 영향을 받나요?

셀프호스팅으로 GitLab을 운영한다면 버전부터 확인해야 합니다. 이번 취약점은 커뮤니티 에디션(CE)과 엔터프라이즈 에디션(EE)에 모두 걸쳐 있어요. GitLab.com 같은 SaaS형은 GitLab이 직접 패치하지만, 직접 설치해 쓰는 서버는 관리자가 올려야 합니다.

아래 표의 영향 범위에 든다면 지체 없이 패치 버전으로 올리는 것이 안전합니다.

GitLab은 이 세 버전을 2026년 9월 10일에 배포했습니다. 현재 버전은 관리 화면 하단이나 /help 경로에서 확인할 수 있어요. 버전이 애매하게 낮다면 최신 패치 라인으로 올리는 편이 판단이 빠릅니다.

지금 무엇을 해야 하나요?

순서는 분명합니다. 패치가 먼저, 그다음이 흔적 점검과 자격증명 교체입니다.

첫째, 영향 버전이라면 즉시 패치 버전으로 업그레이드합니다. 실제 스캐닝이 진행 중인 취약점이라 시간을 끌수록 위험이 커지죠. 둘째, 이미 노려졌을 가능성을 점검합니다. commits API 경로로 들어온 비정상 요청, 특히 파일 경로 값을 담은 요청이 로그에 있는지 살펴봐야 해요. 셋째, 노출됐을 수 있는 값을 갈아 끼웁니다. 설정과 로그에 담겨 있던 자격증명, 토큰, 키는 이미 읽혔다고 보고 교체하는 것이 안전합니다. 패치만 하고 자격증명을 그대로 두면, 이미 빠져나간 열쇠로 문이 다시 열릴 수 있으니까요.

이번 사례가 남기는 교훈은 속도입니다. 패치가 나온 지 하루 만에 인터넷 전역이 같은 취약점을 두드렸습니다. 인터넷에 열려 있는 서버라면, 패치 공개는 방어의 시작이 아니라 공격의 신호탄이 되기도 한다는 점을 기억할 필요가 있습니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)