CVE-2021-39935: GitLab CI Lint API 서버 사이드 요청 위조 취약점

2026년 2월 초, 미국 사이버보안 및 인프라 보안국(CISA)은 GitLab Community 및 Enterprise Edition에 영향을 미치는 서버 사이드 요청 위조(Server-Side Request Forgery, SSRF) 취약점 CVE-2021-39935를 Known Exploited Vulnerabilities(KEV) 카탈로그에 추가했다. 해당 취약점은 이미 2021년에 패치되었지만, 인터넷에 노출된 미패치 GitLab 인스턴스를 대상으로 한 실제 악용이 다시 확인되며 긴급 대응 대상으로 분류되었다.

CISA는 연방 기관에 대해 2026년 2월 24일까지 조치를 완료할 것을 요구했으며(BOD 22-01), 민간 조직 역시 동일한 수준의 대응을 우선시할 것을 강력히 권고하고 있다. 이번 글에서는 CVE-2021-39935를 중심으로, 외부에 노출된 GitLab 인스턴스가 어떻게 실제 공격으로 이어질 수 있는지와 이를 식별·관리하기 위한 공격 표면 관점의 대응 전략을 살펴본다.

CVE-2021-39935 취약점 개요

• 취약점 ID: CVE-2021-39935
• 영향 제품: GitLab Community Edition(CE), Enterprise Edition(EE)
• 유형: 서버 사이드 요청 위조(SSRF), CWE-918
• 공격 조건: 인증 없이 원격 악용 가능(Unauthenticated)
• 핵심 영향: GitLab 서버가 공격자가 지정한 임의 URL로 서버 측 요청을 수행 → 내부 자원 접근/스캔/메타데이터 탈취/2차 취약점 연쇄

CVE-2021-39935는 GitLab의 CI Lint API(CI/CD 구성 검증 및 파이프라인 시뮬레이션에 사용)에서 사용자 입력 URL 검증이 부적절하게 처리되는 문제로 알려져 있다. 공격자는 악성 API 요청을 통해 GitLab 서버가 내부망(예: RFC1918) 또는 외부 자원으로 요청을 보내도록 유도할 수 있다. 특히 CI/CD 및 DevOps 플랫폼은 코드, 토큰, 배포 키, 레지스트리 자격증명 등 고가치 비밀정보가 집중되는 지점이기 때문에, SSRF 하나가 “단일 서비스 침해”가 아니라 조직 전체로 확산되는 초기 침투 벡터로 전환되기 쉽다.

CISA는 이 취약점이 실제 악용 중임을 근거로 KEV에 추가했다. 즉, 공격자는 이미 자동화된 스캐닝/익스플로잇 체인을 활용해 미패치 GitLab 인스턴스를 적극적으로 찾고 있으며, 외부 노출된 CI/CD 플랫폼을 통해 내부 환경으로 피벗하려는 시도가 재점화된 것으로 해석된다.

공격 메커니즘 및 시나리오

공격 메커니즘

SSRF는 사용자 입력 → 서버가 대신 요청 → 서버가 볼 수 있는 곳을 공격자가 간접 접근 이라는 단순한 공격 매커니즘을 가지고 있다. 핵심은 CI Lint API가 CI 구성 검증 과정에서 사용자 입력 URL을 충분히 검증하지 못하고, GitLab 서버가 해당 URL로 요청을 수행할 수 있는 여지를 만든다는 점이다. 인증이 없는 외부 공격자라도 요청을 구성해 CI Lint API를 호출할 수 있는 조건이 만들어지면, 서버는 공격자의 지시에 따라 내부/외부 자원으로 연결을 시도할 수 있다.

예상 공격 시나리오

1. 외부 노출 GitLab 식별
   공격자는 GitLab 리소스 패턴을 기반으로 인터넷 스캐닝을 수행하여 외부 노출 인스턴스를 찾는다.
2. CI Lint API를 통한 SSRF 수행
   조작된 API 요청으로 GitLab 서버가 공격자 지정 URL로 요청을 수행하도록 유도한다.
3. 내부 자원 접근 및 스캔
   내부 IP 주소/포트로의 연결 성공 여부를 통해 내부 네트워크 맵핑이 가능해진다.
4. 민감정보 유출
   클라우드 메타데이터 또는 내부 서비스 응답에서 토큰/키/설정이 노출될 수 있다.
5. 2차 취약점/자격증명으로 확산
   유출된 정보를 바탕으로 레지스트리, 내부 API 등으로의 측면 이동(lateral movement)을 시도한다.

Criminal IP를 통해 관측한 외부 노출 GitLab 인스턴스 현황

취약점 대응은 GitLab을 패치했다고 믿지만 실제로는 테스트/PoC/부서별 인스턴스가 남아 있는 순간에 가장 어려워진다. 인스턴스 남아 있는 경우 그중 일부가 외부에 그대로 노출되어 공격자에게 가장 쉬운 표적이 되기 때문이다. 따라서 이번 이슈의 핵심은 CVE 존재 여부가 아니라, 외부에서 접근 가능한 GitLab 인스턴스가 어디에 얼마나 남아 있는지를 선제적으로 확인하는 것이다.

Criminal IP 검색 쿼리: title: GitLab

이를 확인하기 위해 Criminal IP Asset Search에서 위와 같은 검색 쿼리를 적용했으며, 2026년 2월 6일 기준으로 71,069건의 자산이 검색되는 것을 확인했다. 이러한 외부 노출 GitLab 인스턴스는 CVE-2021-39935와 같은 인증 이전 단계에서 악용 가능한 SSRF 취약점이 존재할 경우, 즉시 공격 표면으로 전환될 수 있다. 공격자는 GitLab 로그인 페이지, 정적 리소스, CI 관련 엔드포인트 응답을 통해 GitLab 버전 및 구성 정보를 간접적으로 추정한 뒤, 미패치 환경을 우선적으로 표적으로 삼을 가능성이 높다.

Criminal IP 검색 쿼리: title:”GitLab” AND port:443 OR port:80

위에서 발견된 GitLab 자산 중, GitLab 웹 인터페이스가 기본 웹 포트(HTTP/HTTPS)를 통해 외부에서 직접 접근 가능한 상태로 노출된 자산을 추가로 식별했다. 해당 조건을 적용한 결과, 총 311건의 노출 자산이 확인되었으며, 이는 인증 여부와 관계없이 서비스 존재가 즉시 식별 가능한 GitLab 인스턴스가 상당수 존재함을 의미한다.

또한 특정 GitLab 인스턴스를 분석한 결과 4개의 포트가 동시에 열려 있었으며, 20개가 넘는 취약점이 함께 식별되었다. 이는 해당 자산이 단일 서비스 노출에 그치지 않고, 웹 인터페이스·원격 접근·관리 기능이 복합적으로 외부에 노출된 상태임을 의미한다. 이와 같이 다수의 포트와 취약점이 함께 노출된 환경에서는, CVE-2021-39935와 같은 인증 이전 SSRF 취약점이 단독 공격 벡터가 아닌 초기 침투 지점으로 작용할 가능성이 높다. 공격자는 SSRF를 통해 내부 요청을 유도한 이후, 동일 자산에 노출된 SSH(22), 웹 서비스(80/443), 기타 취약한 구성 요소를 연쇄적으로 탐색하며 공격 범위를 확장할 수 있다.

Criminal IP 관측 관점에서 중요한 점은, 조직 내부 자산 목록에 포함되지 않은 GitLab 인스턴스라도 외부에서 응답이 확인되는 순간 공격자에게는 동일한 ‘외부 자산’으로 인식된다는 점이다. 테스트용, 임시 프로젝트용, 과거에 사용되다 방치된 GitLab 인스턴스는 이러한 이유로 공격에 특히 취약한 상태가 된다.

대응 및 권고 사항

CVE-2021-39935는 이미 패치가 제공된 취약점이지만, CISA KEV 등재가 의미하듯 외부에 노출된 미패치 GitLab 인스턴스가 실제 공격에 활용되고 있는 상황이다. 이에 따라 대응은 단순한 버전 업데이트를 넘어, 외부 노출 여부를 중심으로 한 점검이 병행되어야 한다.

• 즉각적인 패치 및 버전 점검
  • 패치 버전(14.3.6 / 14.4.4 / 14.5.2 이상)으로 즉시 업그레이드
  • 테스트·백업·임시 인스턴스까지 포함해 모든 GitLab 배포 환경 점검
• CI Lint API 및 관련 API 접근 통제
  • 외부 사용자에게 CI Lint API 접근이 필요한지 재검토
  • 불필요한 API 엔드포인트는 네트워크 또는 설정 차원에서 차단
• 로그 기반 이상 행위 점검
  • 내부 IP·비정상 URL 대상으로 한 연결 시도 여부 점검
  •  실패한 연결(타임아웃, 거부) 로그 급증 여부 확인
• 외부 노출 자산 지속 점검
  • Criminal IP Asset Search와 같은 자산 검색 도구를 활용해 외부에서 식별 가능한 GitLab 인스턴스 상시 점검
  • 신규 배포·환경 변경 시 외부 노출 여부 자동 점검 프로세스 수립

FAQ

Q1. 이미 2021년에 패치된 취약점인데, 왜 지금 KEV로 올라왔나요?

CVE-2021-39935는 2021년에 패치가 제공되었으나, 이후에도 해당 취약점이 적용되지 않은 GitLab 인스턴스가 인터넷에 노출된 상태로 다수 존재해 왔습니다. CISA가 KEV에 추가한 배경은 취약점의 신규성 때문이 아니라, 현재 시점에도 실제 공격에 악용되고 있음이 확인되었기 때문입니다. 특히 GitLab은 테스트 환경, 임시 프로젝트, 부서별 운영 인스턴스 등으로 분산 배포되는 경우가 많아, 일부 인스턴스가 패치 및 관리 대상에서 누락되기 쉽습니다. 이러한 미패치·외부 노출 환경은 공격자에게 손쉬운 표적이 되며, CISA는 이를 근거로 긴급 대응이 필요한 취약점으로 분류했습니다.

Q2. 패치만 적용하면 충분한가요?

패치 적용은 필수적인 대응이지만, 그것만으로 충분하다고 보기는 어렵습니다. CVE-2021-39935는 인증 이전 단계에서 악용 가능한 SSRF 취약점으로, 외부에 노출된 상태 자체가 공격 가능성을 결정하는 핵심 요소입니다.

패치 이전에 외부 노출된 GitLab 인스턴스가 존재했을 경우, 공격자는 이미 내부 네트워크 구조를 탐색하거나 민감 정보에 접근했을 가능성이 있습니다. 또한 조직이 모든 GitLab 인스턴스를 정확히 파악하지 못하고 있다면, 일부 자산은 패치 이후에도 외부에 노출된 상태로 남아 있을 수 있습니다. 따라서 패치와 함께 외부 노출 자산을 지속적으로 식별·검증하는 공격 표면 관리(ASM) 관점의 대응이 병행되어야 합니다.

결론

CVE-2021-39935는 오래된 GitLab 취약점이 다시 부각된 사례를 넘어 외부에 노출된 CI/CD 인프라가 얼마나 쉽게 실제 공격으로 전환될 수 있는지를 보여주는 대표적인 사례이다. CISA의 KEV 등재는 해당 취약점이 이론적 위험에 그치지 않고, 현재도 인터넷에 남아 있는 미패치 GitLab 인스턴스가 실질적인 공격 대상이 되고 있음을 명확히 보여준다.

조직은 단순히 취약한 버전을 사용하고 있는지 여부만을 확인해서는 안 된다. 외부에서 접근 가능한 GitLab 인스턴스가 어디에 존재하는지를 지속적으로 식별해야 하며, 패치 및 설정 변경 이후에도 노출 상태가 실제로 해소되었는지를 반복적으로 검증해야 한다. 취약점 정보와 외부 공격 표면 가시성을 결합한 대응만이, CVE-2021-39935와 같은 인증 이전 SSRF 취약점으로부터 CI/CD 환경을 보호할 수 있는 현실적인 방어 전략이다.

관련하여 CVE-2026-24061: GNU Inetutils telnetd 인증 우회 취약점 분석 글을 참고할 수 있다.

Criminal IP (criminalip.io/ko/register) 에 가입하면 즉시 취약 자산 탐지를 시작할 수 있습니다. 또한 아래 버튼을 통해 데모를 요청하고, 엔터프라이즈 환경에서 외부에 노출된 자산을 대상으로 한 Criminal IP의 위협 인텔리전스(TI) 분석을 직접 확인해 보세요.

---

이 리포트는 AI기반 사이버 위협 인텔리전스 검색엔진 Criminal IP의 데이터를 바탕으로 작성되었습니다. 지금 바로 Criminal IP 무료 계정을 생성하면 리포트에 인용된 검색 결과를 직접 확인하거나, 더 방대한 위협 인텔리전스를 자유롭게 검색할 수 있습니다. 

데이터 출처 : Criminal IP (https://www.criminalip.io/ko), BleepingComputer(https://www.bleepingcomputer.com/news/security/cisa-warns-of-five-year-old-gitlab-flaw-exploited-in-attacks/), CyberSecurityNews (https://cybersecuritynews.com/cisa-warns-gitlab-ssrf-vulnerability-exploit/)

관련 글 : https://www.criminalip.io/ko/knowledge-hub/blog/32538