GitLab 비인증 원격 코드 실행(CVSS 10), 수정 버전과 패치 확인법

GitLab CVE-2026-97229는 CI/CD 설정에 들어 있는 정규식을 처리하다가 서버에서 공격자의 코드가 실행될 수 있는 결함이다. 정규식은 파일 경로나 문자열이 정해진 조건에 맞는지 검사하는 패턴이다. 공격자가 만든 패턴을 취약한 서버가 처리하는 과정에서 정수 오버플로가 발생하며, GitLab은 특정 조건에서 로그인하지 않은 공격자도 임의 코드를 실행할 수 있다고 밝혔다. CVSS 3.1 점수는 10.0이다.[1][2]

다만 비인증 공격이 가능하다는 평가와 모든 기본 설치가 같은 방식으로 외부에 노출된다는 주장은 다르다. 공식 공지는 기본 설정별 노출 조건을 세세하게 제시하지 않는다. 셀프호스팅 관리자는 실제 접속 경로와 설치 버전을 확인해야 한다. GitLab.com과 GitLab Dedicated는 GitLab이 이미 패치했다고 공지했으므로, 사용자가 직접 서버 패키지를 갱신하는 대상과 구분한다.[1]

먼저 확인할 것

• 셀프호스팅 CE/EE의 수정 버전은 19.2.8 · 19.3.5 · 19.4.2다. 19.3.4는 이번 결함의 수정본이 아니다.[1]
• 공식 패키지인지 자체 Ruby를 쓰는 이미지인지 확인한다. GitLab 버전만 바뀌고 기반 Ruby 수정이 빠질 수 있다.[5][6]
• KEV 조치 기한 2026년 11월 1일은 미국 연방 민간 행정부 기관(FCEB) 대상이다. 국내 민간 조직 전체에 같은 법적 기한이 생긴 것은 아니다.[3][4]
• 패치와 함께 공격 흔적을 점검한다. 로그에 이상이 없다는 사실만으로 침해를 배제하지 않는다.[1][6]

어느 버전이 영향을 받나?

GitLab CE와 EE의 영향 구간은 같다. 다음 표의 왼쪽 범위에 해당하면 수정이 필요하다. 오른쪽은 이번 CVE의 최초 수정 버전이며, 실제 목표 버전은 지원 상태와 업그레이드 경로를 확인해 해당 계열의 최신 패치를 선택한다.[1][2]

패치 릴리스 발표일은 2026년 10월 12일이다. NVD의 최초 게시 시각은 10월 13일 02:17 UTC로, 패치 발표일과 다른 항목이다. 점수 10.0은 NVD에 실린 GitLab 제공 평가이며, 이 점수만으로 특정 서버가 침해됐다고 판단할 수는 없다.[1][2]

19.2보다 오래된 버전은 이 공지가 명시한 영향 구간에 들어 있지 않다. 그렇다고 다른 보안 결함까지 없다는 뜻은 아니다. 오래된 설치본은 별도로 지원 여부와 누락된 보안 업데이트를 점검해야 한다.[1][7]

KEV 등재는 무엇을 뜻하나?

CISA는 실제 악용 증거를 근거로 2026년 10월 29일 이 취약점을 KEV에 추가했다. KEV 항목의 조치 기한은 11월 1일이다. 이 기한은 FCEB 기관의 의무 대응 맥락으로 이해해야 하며, 한국 시간 기준 자정까지 모든 기업이 완료해야 한다는 식으로 바꾸어 쓰면 안 된다.[3][4]

민간 조직에도 KEV는 패치 우선순위를 정할 중요한 근거다. CISA는 모든 조직에 위험 기반 취약점 관리와 KEV 우선 조치를 권장한다. 관리자에게 필요한 판단은 막연한 위기감이 아니라, 취약 설치본이 있는지와 외부에서 어디까지 접근할 수 있는지, 누가 언제 업데이트할지를 정하는 일이다.[4]

Alpine Linux는 10월 20~21일 자사 GitLab에 조작된 CI 설정을 보낸 공격 시도를 공개했다. 워커 프로세스가 8회 중단됐지만 코드 실행이 성공했다는 증거는 찾지 못했다고 밝혔다. 성공을 배제할 수도 없어 서버를 재구축했다는 설명이다. 이는 시도와 성공을 구분해야 하는 사례이며, 이번에 대조한 공식 자료에서는 Alpine 외 환경의 RCE 성공 사례도 확인되지 않았다.[6]

패치 전에 무엇을 기록해야 하나?

설치 방식, CE/EE 구분, 현재 버전, 공식 패키지·이미지 사용 여부를 먼저 적는다. Linux 패키지 설치본에서는 GitLab 공식 유지보수 문서의 다음 조회 명령으로 환경 정보를 확인할 수 있다. 다중 노드라면 GitLab Rails가 실행되는 노드에서 수행한다.[8]

sudo gitlab-rake gitlab:env:info

출력의 GitLab 버전과 Ruby 정보를 함께 확인하되, 공식 패키지는 수정 사항을 기존 Ruby에 반영했을 수도 있다. 따라서 Ruby 버전 숫자만으로 공식 패키지에 수정이 빠졌다고 판단하지 않는다. 반대로 자체 Ruby를 사용하는 빌드는 GitLab 버전만으로 패치 완료라고 판정하지 않는다.[5][6]

업그레이드 전에는 설치 방식에 맞는 백업 절차와 복구 방법을 확인하고 유지보수 시간을 잡는다. 이번 패치에는 데이터베이스 마이그레이션이 포함돼 단일 노드는 중단이 발생한다. 다중 노드도 공식 무중단 절차의 조건을 충족해야 하므로, 단순 재시작만으로 무중단을 보장할 수는 없다.[1][9][10][11]

오래된 버전에서 여러 계열을 건너간다면 Upgrade Path 도구와 버전별 주의사항을 먼저 확인한다. GitLab 19 문서는 필수 경유 버전으로 19.2, 19.5, 19.8, 19.11을 제시하지만, 이 목록에는 아직 출시되지 않은 버전도 포함될 수 있다. 현재 버전에서 목표 버전까지 필요한 구간만 적용하고, 백그라운드 마이그레이션 완료를 확인한 뒤 다음 단계로 진행한다.[7]

설치 방식에 따라 어떻게 갱신하나?

Linux 패키지: 공식 패키지 업그레이드 문서에서 운영체제와 CE/EE에 맞는 절차를 따른다. 중간 경유가 필요하면 버전을 지정해 순서대로 올린다. 패키지 관리자가 작업을 마쳤다는 메시지뿐 아니라 실제 실행 버전과 서비스 상태, 마이그레이션 완료 여부까지 확인해야 한다.[7][9]

공식 Docker 이미지: 데이터베이스와 GitLab secrets 파일을 포함한 백업을 먼저 확보한다. Docker Compose 사용자는 설정 파일의 이미지 태그를 선택한 수정 버전으로 바꾼 뒤 공식 문서의 다음 명령을 실행한다. 태그를 그대로 둔 채 이미지만 다시 받으면 원하는 수정본으로 바뀌지 않을 수 있다.[10]

docker compose pull
docker compose up -d

Helm: 차트 버전과 GitLab 앱 버전은 번호가 다르다. 공식 매핑 문서에서 확인한 최초 수정본의 조합은 차트 10.2.8 → GitLab 19.2.8, 차트 10.3.6 → GitLab 19.3.5, 차트 10.4.2 → GitLab 19.4.2다. 이 매핑은 2026년 11월 1일 22:48 KST에 확인했다. 적용 직전에는 최신 매핑과 차트 업그레이드 문서를 다시 열고, 기존 values와 마이그레이션 절차를 검토한다.[11][12]

소스 설치·커스텀 이미지: 기반 Ruby 수정까지 확인한다. Alpine은 GitLab을 19.3.6으로 올렸지만 자체 이미지의 표준 Ruby에 수정이 없어 취약점이 남았다고 설명했다. Ruby 프로젝트는 관련 정규식 결함의 수정을 모두 포함한 3.3.13, 3.4.12, 4.0.9 이상을 권장한다. GitLab과 호환되는 Ruby 계열 안에서 수정 포함 여부를 확인해야 하며, 무조건 다른 메이저로 바꾸라는 뜻은 아니다.[5][6]

업데이트할 수 없다면 임시 설정으로 막을 수 있나?

이번에 확인한 GitLab 공식 보안 공지에는 임시 완화책이 없다. CI 기능을 끄거나 특정 경로만 차단하면 해결된다는 설정도 공식 대체 조치로 제시되지 않았다. 따라서 임의의 설정 변경을 패치와 동등한 해결책으로 안내할 수 없다.[1]

Ruby 공지 역시 정규식 시간 제한과 패턴 길이 제한이 이 결함들을 신뢰성 있게 막지 못한다고 설명한다. 비신뢰 입력으로 정규식을 컴파일하지 말라는 일반 애플리케이션 권고를 GitLab의 검증된 설정 스위치로 바꾸어 해석하지 않는다. 즉시 업데이트하기 어렵다면 변경 담당자와 보안 대응 담당자가 노출 상태 및 서비스 운영 여부를 함께 판단해야 한다.[5]

패치 뒤에는 어떤 흔적을 살펴보나?

패치 완료 확인과 과거 침해 점검은 별개다. GitLab은 셀프호스팅 고객용 탐지 6종을 공개했다. 워커 중단, 적대적인 정규식 요청, 비정상적인 오류 증가 등을 살피는 규칙으로, 보안 공지에서 각 규칙 문서로 연결된다.[1][13]

• Onigmo native worker crash
• Graphql cilint hostile regexp
• ci regexp oversized non ascii path
• ci regexp guard rejection
• ci lint workhorse worker crash
• ci lint scripted client error burst

관리자는 해당 규칙의 대상 로그와 전제조건을 확인하고, 보존된 워커 오류·비정상 CI 요청·신규 계정 및 의심스러운 CI 설정을 함께 검토할 수 있다. 규칙이 일치했다고 바로 침해를 확정하거나, 일치하지 않았다고 안전하다고 판단해서는 안 된다.[1][6][13]

Alpine은 성공한 공격이라면 크래시나 웹 로그 흔적을 남기지 않을 수 있다고 설명했다. 로그가 유실됐거나 의심 정황이 있다면 우선 증거를 보존하고 사고 대응 절차로 넘긴다. 자격증명·토큰·시크릿 교체와 재구축은 침해 가능성 및 조사 결과에 따라 검토할 선택지다. 모든 GitLab 사용자에게 무조건 같은 재구축을 요구하는 것은 아니다.[6]

확인한 GitLab 보안 공지와 CISA KEV에는 공식 IoC IP·도메인·파일 해시 목록이 없다. 임의의 주소나 해시를 차단 목록으로 제시하지 않는다. 탐지 규칙이 있다는 사실과 공식 IoC 목록이 있다는 주장은 구분해야 한다.[1][3]

어디까지 확인하면 작업을 마칠 수 있나?

셀프호스팅 관리자는 실행 중인 GitLab 수정 버전, 배포물의 Ruby 수정 포함 여부, 마이그레이션과 서비스 상태, 과거 공격 흔적 검토 결과를 함께 기록한다. 패키지 설치 성공 화면 하나보다는 이 네 항목이 인수인계와 후속 조사에 유용하다.[1][5][6][7]

GitLab.com과 Dedicated 사용자는 이번 공지상 서버 패치가 완료된 범주다. 셀프호스팅용 명령을 실행할 필요는 없다. 별도로 관리하는 서버가 있는지 구분하고, 의심스러운 계정 활동이 있다면 조직의 보안 대응 창구로 연결한다. 취약점 대응의 핵심은 서비스를 구분하고, 올바른 수정본을 적용한 뒤 확인 가능한 증거를 남기는 데 있다.[1]

출처