GitLab.com만 쓰는 개발자라면 이번 주 소식이 남의 일처럼 들릴 수 있습니다. 문제는 회사 서버실, 연구실, 스타트업 사무실에 있는 직접 운영 GitLab입니다. 2026년 9월 10일 GitLab이 공개한 GitLab 취약점 CVE-2026-85706은 로그인하지 않은 외부 요청으로 서버 안 파일을 읽을 수 있는 결함이고, 심각도 점수는 만점인 10.0입니다.
패치가 나온 다음 날부터 보안 업체가 인터넷에 노출된 서버를 훑는 탐색을 관측했다고 밝혔고, 미국 CISA는 같은 날 이 번호를 실제 악용된 취약점 목록(KEV)에 올렸습니다. GitLab 공식 문서의 표현은 “특정 조건에서 인증되지 않은 사용자가 서버의 임의 파일을 읽을 수 있었다”입니다. 여기서 중요한 것은 공격 코드를 따라 하는 일이 아니라, 우리 서버가 그 조건에 해당하는지 확인하고 패치하는 일입니다.
한눈에 결론
- 대상은 GitLab Community Edition과 Enterprise Edition의 직접 운영(셀프 매니지드) 설치본입니다.
- GitLab.com은 이미 패치됐고, GitLab Dedicated 고객은 별도 조치가 필요 없습니다.
- 올려야 할 버전은 19.3.2, 19.2.6, 19.1.8입니다. 영향 범위는 18.7부터 해당 패치 직전입니다.
- 공식 우회책은 공개되지 않았습니다. 인터넷에 열려 있으면 패치가 사실상 유일한 대응입니다.
- 패치 뒤에는 로그 점검과 토큰·키 교체를 같이 하는 편이 안전합니다.
9월 10일 패치에서 무엇이 바뀌었나
GitLab은 2026년 9월 10일 Community Edition(CE)과 Enterprise Edition(EE)용 긴급 패치 19.3.2, 19.2.6, 19.1.8을 공개했습니다. 공식 패치 노트 기준으로 보안 수정은 19건입니다. 그 가운데 일반 운영자가 먼저 봐야 할 항목은 두 개입니다.
첫 번째는 CVE-2026-85706입니다. 저장소 커밋 API에서 경로를 허용된 범위 안으로 가두지 못했고, 인증 확인도 빠져 있었습니다. 그 결과 특정 조건에서는 계정 없이 서버 파일을 읽을 수 있었습니다. GitLab이 매긴 CVSS 3.1 점수는 10.0이고, 벡터는 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N입니다. 네트워크로 들어오고, 권한이 필요 없고, 사용자 조작도 필요 없다는 뜻입니다. 제보자는 HackerOne 계정 s3ntago입니다.
두 번째는 EE 전용 CVE-2026-87719입니다. GraphQL 구독 직렬화 처리의 안전하지 않은 역직렬화 문제로, Duo Chat 권한이 있는 로그인 사용자가 Advanced Search 설정과 민감한 인증 정보를 가져갈 수 있었습니다. 점수는 9.9입니다. 제보자는 kyyblin입니다. 이 결함은 인증된 내부 사용자 또는 이미 계정에 들어온 공격자를 전제로 하므로, 외부에 열린 서버를 먼저 노리는 쪽은 전자입니다.
같은 패치에는 CI/CD 변수 노출, 마크다운 XSS, SAML 제한 우회 같은 중간·높음 등급 수정도 들어 있습니다. 지금 당장 서버를 살리는 이유는 CVE-2026-85706이지만, 한 번 올리는 김에 이 묶음을 같이 막는 편이 낫습니다.
GitLab.com 사용자는 괜찮은가
공식 패치 공지는 대상을 분명히 나눕니다. GitLab.com은 이미 패치된 코드를 돌리고 있습니다. GitLab이 대신 운영하는 Dedicated 고객도 추가 조치가 필요 없습니다. 손이 가는 곳은 직접 설치해 돌리는 CE/EE입니다. 대학 실습 서버, 사내 온프레미스, 클라우드 가상머신에 올린 Omnibus, Helm 차트 배포가 여기 들어갑니다.
배포 형식은 가리지 않습니다. GitLab 문서도 “특정 배포 형식을 따로 적지 않으면 모든 형식이 해당된다”고 적습니다. 인터넷에 로그인 화면이 열려 있는 서버가 가장 급합니다. VPN 뒤에만 있는 서버도 버전은 확인해야 합니다. 내부 계정 탈취나 다른 경로로 들어온 뒤 이 API를 쓰는 시나리오까지 배제할 수는 없습니다.
보안 매체 일부는 전 세계 직접 운영 인스턴스가 2만 대를 넘는다고 추정합니다. 이는 GitLab 공식 수치가 아니라 이차 보도의 추정치입니다. 숫자의 정확성보다, 한국에도 인터넷에 열린 사내·연구용 GitLab이 적지 않다는 점이 실질 위험입니다.
인증 없이 파일을 읽는다는 말이 실제로 의미하는 것
경로 순회(path traversal)는 프로그램이 기대한 폴더 밖으로 파일 경로가 빠져나가는 결함입니다. 이번 경우는 그 경로를 커밋 API가 제대로 막지 못했고, 그 API에 인증도 걸려 있지 않았습니다. GitLab 문구는 “특정 조건”을 전제로 합니다. 공식 문서가 그 조건을 체크리스트처럼 풀어 쓰지는 않았습니다.
보안 업체 watchTowr는 공개 프로젝트가 하나라도 있는 인스턴스를 전제로, 커밋 API에 대한 단일 HTTP POST로 파일을 읽을 수 있다고 설명했습니다. 같은 업체는 2026년 9월 11일 06:00 UTC부터 허니팟에서 탐색 트래픽을 봤다고 밝혔습니다. 로그에서 찾으라고 권한 주소는 /api/v4/projects/{id}/repository/commits/ 로 들어오는 POST와 file.path 파라미터입니다.
이 설명은 방어용 힌트로는 쓸모가 있습니다. 다만 공격 절차를 재현하는 글이 되어서는 안 됩니다. GitLab이 패치 시점에 “야생에서 악용됨”이라고 직접 쓰지는 않았고, CISA KEV 등재와 보안 업체의 탐색 관측이 그 뒤를 받칩니다. 탐색과 성공적인 파일 탈취는 같은 말이 아닙니다. 그래도 인터넷에 열린 취약 서버를 그냥 두는 근거는 되지 않습니다.
읽을 수 있는 대상이 “임의 파일”이면 설정 파일, 토큰, 배포 키, 환경 변수처럼 CI/CD와 클라우드로 이어지는 값이 위험 목록에 올라갑니다. 파일 읽기 자체는 원격 코드 실행이 아닙니다. 다만 읽힌 비밀값으로 저장소를 가져가거나 파이프라인을 조작하는 다음 단계가 열립니다. 2023년 5월에도 GitLab은 비슷한 만점 경로 순회(CVE-2023-2825)를 패치한 적이 있습니다. 같은 계열의 실수가 반복된 셈입니다.
지금 쓰는 버전을 어디로 올려야 하나
CVE-2026-85706의 공식 영향 범위는 다음과 같습니다.
| 계열 | 취약한 범위 | 패치 버전 |
|---|---|---|
| 19.3 | 19.3.2 미만 | 19.3.2 |
| 19.2 | 19.2.6 미만 | 19.2.6 |
| 19.1 | 19.1.8 미만 | 19.1.8 |
| 18.7 이후 | 위 패치 직전 | 같은 계열의 패치 버전 |
18.7 미만은 이번 CVE 설명의 범위 밖입니다. 그렇다고 오래된 서버가 안전하다는 뜻은 아닙니다. 지원이 끝난 메이저를 그대로 두면 이번 번호가 아니더라도 다른 공개 결함에 그대로 노출됩니다. CVE-2026-87719의 시작점은 더 앞인 EE 18.3입니다. EE를 쓰고 Duo Chat을 열어 두었다면 이번 패치 묶음을 같은 일정으로 보는 편이 맞습니다.
패치에는 데이터베이스 마이그레이션이 들어 있습니다. 단일 노드 Omnibus는 마이그레이션이 끝나기 전에 GitLab이 뜨지 않아 점검 시간이 생깁니다. 다중 노드는 GitLab이 안내하는 무중단 업그레이드 절차를 따르면 다운타임을 줄일 수 있습니다. 공식 우회책은 없습니다. 당장 버전을 못 올리면 관리 콘솔을 VPN이나 IP 허용 목록 뒤로 옮기고, 리버스 프록시에서 커밋 API 경로를 제한하는 임시 조치가 보안 업체 쪽에서 거론됩니다. 임시 조치는 패치를 대체하지 않습니다.
팩트체크
현재 판정: 취약점 존재와 패치 공개는 사실. 광범위한 침해 규모는 공식 미확인.
원출처: GitLab Critical Patch Release 19.3.2 / 19.2.6 / 19.1.8 (2026-09-10), CVE-2026-85706, CISA KEV (2026-09-11 등재).
확인된 부분: CE/EE 직접 운영본 영향, CVSS 10.0, GitLab.com·Dedicated는 사용자 조치 없음, 패치 버전 번호, CISA 연방기관 권고 기한 2026-09-14.
미확인 부분: 국내 피해 여부, 실제로 유출된 파일의 종류와 규모, GitLab이 직접 인정한 야생 악용 사례의 세부 내용.
협력·보안업체 주장: watchTowr의 9월 11일 탐색 관측, 공개 프로젝트 조건, 단일 POST 설명. GitLab 공식 문장의 “특정 조건”을 업체가 재구성한 내용이므로 공식 확인과 분리해야 합니다.
운영자가 지금 확인해야 할 순서
대상이 아닌 사람은 여기서 멈춰도 됩니다. GitLab.com 웹 저장소만 쓰고, 회사 서버에 GitLab을 설치한 적이 없다면 브라우저를 급히 바꿀 문제는 아닙니다.
버전은 관리자로 로그인한 뒤 왼쪽 아래 Help, 또는 주소창에 /help를 붙이면 나옵니다. Omnibus라면 서버에서 sudo gitlab-rake gitlab:env:info로도 확인할 수 있습니다. “19.3”처럼 메이저만 보지 말고 세 번째 숫자까지 봅니다. 19.3.1은 이번 패치가 아닙니다.
한국에서 직접 운영본이 남는 자리는 대략 세 곳입니다. 소스 반출을 꺼리는 대기업·공공 온프레미스, 학생 실습용으로 학과 서버에 올린 CE, 클라우드 비용은 내지만 GitLab.com 요금제 대신 가상머신에 Omnibus를 올린 스타트업입니다. 담당자가 개발과 운영을 겸하면 보안 공지를 며칠 늦게 보는 경우가 많습니다. 이번 건은 그 며칠이 탐색 트래픽과 겹칩니다.
직접 운영 서버가 있으면 아래 순서가 실무에 가깝습니다.
- 관리자 화면 또는
/help에서 현재 버전을 확인합니다. 19.3.2, 19.2.6, 19.1.8 미만이면 대상입니다. - 사무실 밖 네트워크에서 로그인 페이지가 열리는지 봅니다. 열린다면 우선순위가 가장 높습니다.
- 백업을 만든 뒤 같은 계열의 패치 버전으로 올립니다. 점프 업그레이드가 필요하면 GitLab 업그레이드 경로 문서를 먼저 봅니다.
- 웹 서버·GitLab 로그에서 커밋 API로 들어온 POST, 특히 파일 경로 파라미터가 들어간 요청을 찾습니다. 패치 발표 전후 수일이 검색 구간입니다.
- 의심 로그가 있거나 서버가 오래 인터넷에 열려 있었다면 개인 접근 토큰, 배포 토큰, 러너 토큰, 클라우드 키, 훅 비밀값을 교체합니다.
로그에 해당 요청이 있다고 해서 곧바로 침해로 단정할 수는 없습니다. 반대로 로그가 없다고 안전하다고 말하기도 어렵습니다. 보관 기간이 짧거나, 리버스 프록시에서 본문이 남지 않는 구성이 흔합니다. 그래서 인터넷에 열려 있던 취약 버전은 비밀값 교체를 기본값으로 두는 편이 맞습니다.
패치 뒤에 남는 일과 흔한 실수
패치가 끝난 뒤에는 웹 UI 로그인, Git 클론, CI 러너 한 건이 도는지 확인합니다. 마이그레이션이 중간에 멈추면 서비스는 떠 보여도 저장소 생성이 실패할 수 있습니다. GitLab 공식 업그레이드 문서는 단일 노드에서 이번 패치가 기동 전 마이그레이션을 끝낸다고 명시하므로, 점검 창을 아예 안 잡는 구성은 피합니다.
버전만 올리고 끝내는 경우가 많습니다. 이번 결함의 결과는 파일 내용 유출이므로, 유출됐을 수 있는 쪽을 같이 봐야 합니다. CI 변수에 들어 있는 클라우드 키, 패키지 레지스트리 토큰, 다른 저장소 미러 계정, Slack·Teams 웹훅이 대표적입니다. 러너가 공유 서버에 있으면 러너 토큰도 목록에 넣습니다.
자주 나오는 실수는 세 가지입니다. 첫째, GitLab.com만 쓰는 줄 알고 사내 테스트 서버를 잊는 경우입니다. 둘째, “내부망이라서 괜찮다”고 미루는 경우입니다. 내부망도 VPN 계정 하나로 열립니다. 셋째, 최신 19.3로 바로 건너뛰려다 업그레이드 경로를 건너뛰어 마이그레이션이 실패하는 경우입니다. 급할수록 현재 마이너 계열 패치를 먼저 적용하는 쪽이 사고 확률이 낮습니다.
CISA는 2026년 9월 11일 KEV에 이 번호를 올렸고, 미국 연방기관 권고 기한은 9월 14일입니다. 한국 공공·기업에 같은 날짜가 법으로 떨어지는 것은 아닙니다. 다만 KEV에 오른 뒤 자동 스캔과 익스플로잇 키트가 빨라지는 패턴은 최근 다른 제품에서도 반복됐습니다. 주말 점검으로 미루기보다, 인터넷에 열린 서버는 오늘 버전을 확인하는 편이 낫습니다.
이 글을 읽는 사람이 오늘 결정할 일
GitLab.com만 쓰는 개인 개발자는 긴급 작업이 없습니다. 회사나 학교에서 GitLab을 직접 돌리는 담당자는 버전 확인이 오늘 할 일입니다. 인터넷에 열려 있고 패치 미만이면 점검 시간을 잡고 올리는 쪽이 맞습니다. EE에서 Duo Chat을 쓰는 조직은 CVE-2026-87719까지 같은 패치로 막히므로, 권한 있는 내부 계정이 많은 환경일수록 미룰 이유가 더 없습니다.
아직 공개되지 않은 것은 국내 피해 통계와, GitLab이 직접 서술한 야생 악용 기술 세부입니다. 그 공백을 메우려고 추정 공격을 사실처럼 적지는 않겠습니다. 확인된 사실만으로도 할 일은 분명합니다. 직접 운영 서버의 버전을 보고, 대상이면 공식 패치 버전으로 올리고, 열려 있던 서버는 토큰을 바꿉니다.
자주 묻는 질문
GitLab 모바일 앱이나 데스크톱 클라이언트도 업데이트해야 하나요?
이번 CVE는 서버의 커밋 API 문제입니다. 클라이언트 앱을 올린다고 서버 결함이 막히지 않습니다. 패치 대상은 GitLab 서버 설치본입니다.
비공개 프로젝트만 있으면 안전한가요?
GitLab 공식 문구는 “특정 조건”이지 “공개 프로젝트만”이 아닙니다. 공개 프로젝트 조건은 보안 업체의 분석입니다. 비공개만 있어도 버전은 확인하고 패치하는 편이 맞습니다.
패치 전에 서버를 끄면 되나요?
인터넷에 열린 취약 서버를 잠시 내리는 것은 임시 차단으로는 유효합니다. 다만 개발 파이프라인이 같이 멈추므로, 가능하면 백업 후 패치하는 쪽이 본래 대응입니다. 끌 수 없다면 VPN 뒤로 옮기고 커밋 API를 제한한 뒤 바로 업그레이드 일정을 잡습니다.
확인일: 2026-09-12. 버전·영향 범위는 GitLab 공식 패치 노트와 CVE 기록을 기준으로 했습니다.