공개 프로젝트가 위험의 문을 열 수 있습니다
최근 CVE-2026-110264라는 치명적인 취약점이 자체 관리형 GitLab 인스턴스를 강타했으며, CVSS 점수에서 10.0 만점을 기록했습니다. 이 결함은 인증되지 않은 공격자가 취약한 서버에서 임의의 코드를 실행할 수 있게 하며, 데이터 무결성과 운영 연속성에 직접적인 위협이 됩니다.
이 익스플로잇은 특정 전제 조건을 필요로 합니다. GitLab 인스턴스가 최소 하나의 공개 프로젝트를 호스팅하거나 Org-mode 렌더링을 트리거해야 합니다. 특수하게 조작된 정규식 입력이 GitLab에 번들로 포함된 Onigmo 정규식 엔진 내의 취약한 코드에 도달하면 정수 오버플로가 발생하고 이후 코드 실행으로 이어집니다.
이 취약점은 2014년 6월에 출시된 GitLab 7.0까지 거슬러 올라가는 긴 그림자를 드리우고 있습니다. 이는 다음과 같은 광범위한 버전의 자체 관리형 Community Edition(CE) 및 Enterprise Edition(EE)에 영향을 미칩니다.
- 18.11.x
- 19.0.x–19.4.x
- 19.5.0
GitLab.com 및 GitLab Dedicated 플랫폼은 조용히 패치되었지만, 자체 호스팅 배포판은 즉각적인 위험에 직면해 있습니다. 우회 방법은 없으며, 조직은 이 심각한 위협을 완화하기 위해 인스턴스를 18.11.13, 19.0.10 또는 19.5.1과 같은 패치된 버전으로 업그레이드해야 합니다. 약 82,000개의 자체 관리형 GitLab 서버가 인터넷에 노출되어 있어 신속한 조치가 필수적입니다.
버그는 Ruby의 정규식 엔진 내부에 숨어 있었습니다
버그는 GitLab의 번들 Ruby 런타임 깊숙한 곳에 있었습니다. 구체적으로 Ruby가 통합하는 Onigmo 정규식 엔진이 정규식 컴파일 중에 반복 ID를 잘못 처리했습니다. 정교하게 조작된 패턴은 정수 오버플로를 트리거하여 메모리 손상으로 직접 이어질 수 있었습니다.
성공적인 공격은 인증되지 않은 공격자가 취약한 자체 관리형 서버에서 네이티브 코드를 실행하도록 허용했습니다. 이 코드는 GitLab의 git 시스템 사용자 권한으로 실행되어 저장된 리포지토리에 심각한 위험을 초래하고 잠재적으로 민감한 CI/CD 데이터를 노출시킬 수 있었습니다.
이번 사건은 중요한 공급망 취약점을 강조합니다. 벤더가 제공하거나 번들로 포함된 런타임 구성 요소는 종종 애플리케이션의 기본 코드베이스에 적용되는 검토를 피합니다. 강력한 내부 보안 검토조차도 업스트림 라이브러리의 결함을 놓칠 수 있습니다.
이 문제를 해결하기 위해 GitLab은 Omnibus 패키지 내에 Ruby 3.3, 3.4, 4.0의 사용자 지정 패치 바이너리를 배포하여 Onigmo 오버플로를 해결해야 했습니다. 신뢰할 수 없는 정규식을 컴파일하는 모든 Ruby 기반 서비스는 특히 최신 Ruby 업스트림 패치(Ruby 4.0.9, 3.4.12, 3.3.13)를 적용하지 않은 경우 노출 여부를 긴급히 평가해야 합니다. 이 취약점은 기초 구성 요소의 단일 결함이 수년간의 운영 무결성을 위태롭게 할 수 있음을 보여줍니다.
9일 만에 발생한 두 번의 만점(10점)은 우연이 아닙니다
GitLab의 최근 보안 기록은 즉각적인 주의를 요구합니다. CVSS 10.0으로 할당된 이 Onigmo 결함은 10.0 등급을 받은 또 다른 치명적인 CI/CD 정규식 컴파일러 결함에 대한 수정안이 나온 지 불과 9일 만에 발생했습니다. 이러한 집중 현상은 전례가 없으며 위험 프로필의 변화를 나타냅니다.
역사적으로 GitLab은 2019년부터 2025년 말까지 단 4건의 CVSS 10.0 취약점만을 기록했습니다. 그러나 2026년 초가을, 플랫폼은 불과 6주 만에 세 번의 만점(10점) 사례에 직면했습니다. 9월의 이전 사례는 패치 후 하루 만에 공격당한 것으로 보고되어 긴급성을 더욱 강조했습니다.
이러한 중요한 권고 사항의 가속화된 속도는 자체 관리형 인스턴스에 상당한 운영 압박을 가합니다. 긴급 업그레이드는 종종 downtime(가동 중단)과 복잡한 데이터베이스 마이그레이션을 필요로 하며, 개발 파이프라인을 방해합니다. 반복되는 권고 사항은 관리자들 사이에 patch fatigue(패치 피로도)를 유발하여 시스템이 패치되지 않은 상태로 남을 가능성을 높입니다.
지연될 때마다 노출된 시스템은 공격자의 스캔 범위 내에서 취약한 상태로 남게 됩니다. 인터넷에서 접근 가능한 약 82,000개의 자체 관리형 GitLab 서버를 고려할 때 공격 표면은 상당히 넓습니다. 자세한 내용과 추가 권고 사항은 GitLab Releases & Security Advisories를 참조하십시오. 리더들은 이러한 패턴이 단순히 불운한 일이 아니며, 보안 태세와 업데이트 프로토콜에 대한 전략적 재평가가 필요하다는 점을 인식해야 합니다.
이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.
하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음
먼저 패치하고, 기다리는 동안 조사하십시오
자체 관리형 GitLab 인스턴스에 대한 즉각적인 조치가 중요합니다. 이 CVSS 10.0 vulnerability(취약점)에 대한 우회 방법은 없으므로, 관리자는 지체 없이 패치된 릴리스로 업그레이드해야 합니다. GitLab의 보안 권고 및 릴리스 페이지를 확인하여 버전을 확인하고 관련 백포트를 적용하십시오.
GitLab은 GitLab.com 및 GitLab Dedicated를 포함한 호스팅 서비스에 대해 선제적으로 패치를 적용하여 위험을 완화했습니다. 그러나 자체 관리형 인스턴스를 운영하는 조직은 18.11.13, 19.0.10 또는 19.5.1과 같은 보안 버전으로 업데이트해야 할 책임이 있습니다. 이를 이행하지 않으면 시스템이 노출된 상태로 남게 됩니다.
패치 후에는 철저한 조사가 가장 중요합니다. GitLab의 탐지 지침을 검토하여 침해 지표를 확인하고, 특히 Onigmo 워커 충돌이나 비정상적인 Org-mode 렌더링 오류 발생 여부를 확인하십시오. 약 82,000개의 자체 관리형 GitLab 서버가 인터넷에 노출되어 있다는 점을 고려하여 인스턴스의 공개 노출 범위를 평가하십시오.
마지막으로, 침해가 의심되는 경우 CI/CD 보안 정보 및 액세스 로그에 대한 포괄적인 감사를 수행하십시오. 선제적인 패치와 사건 발생 후의 철저한 분석은 10년 이상의 운영 무결성을 훼손할 수 있는 위협에 대한 가장 강력한 방어 수단입니다.
자주 묻는 질문
GitLab CVE-2026-110264 취약점이란 무엇입니까?
이는 GitLab에 번들로 포함된 Ruby의 정규식 엔진인 Onigmo의 정수 오버플로와 관련된 CVSS 10.0 원격 코드 실행 결함입니다.
어떤 GitLab 인스턴스가 영향을 받습니까?
이 결함은 공개 프로젝트나 관련 렌더링 트리거가 존재할 경우 7.0 버전부터의 자체 관리형 GitLab CE 및 EE 버전에 영향을 미칩니다.
관리자는 자체 관리형 GitLab 인스턴스를 어떻게 보호할 수 있습니까?
가능한 한 빨리 패치된 GitLab 릴리스로 업그레이드하십시오. 권고 사항은 지원되는 모든 릴리스 브랜치에 대한 수정 버전을 제공합니다.
GitLab.com도 영향을 받았습니까?
GitLab은 공개 발표 전에 GitLab.com 및 GitLab Dedicated가 패치되었다고 보고했습니다. 자체 관리형 관리자는 직접 업데이트를 적용해야 합니다.