GitLab 인증 사용자 RCE PoC 대응 가이드: Webservice ipynbdiff/Oj 파서 긴급 업데이트 포인트

핵심 요약

공개된 PoC는 CI Job이나 GitLab Runner를 실행해야 하는 문제가 아닙니다. 저장소에 push 권한을 가진 인증 사용자가 조작된 Jupyter Notebook 파일을 커밋한 뒤, 해당 커밋의 diff를 열람하도록 유도하면 GitLab Webservice(Puma)에서 ipynbdiff가 Oj JSON 파서를 처리하는 경로를 통해 원격 코드 실행(RCE)에 이를 수 있는 취약점입니다. 따라서 이번 대응의 1순위는 Runner 권한 점검이 아니라 GitLab 애플리케이션의 즉시 업그레이드입니다.

GitLab의 2026년 6월 10일 공식 패치 릴리스는 CE/EE 18.10.8, 18.11.5, 19.0.2를 배포하고 Oj를 3.17.3으로 업데이트했습니다. 자체 관리형 GitLab은 아래 영향 범위에 해당하면 검증 후 가능한 한 빨리 수정 버전 이상으로 올려야 합니다.

핵심 판단: 이 이슈의 직접 공격면은 GitLab Webservice(Puma) 의 notebook commit-diff 처리입니다. CI/CD Runner는 이 PoC의 필수 조건이나 핵심 방어 지점이 아닙니다. Runner 보안은 별도 상시 점검 과제로 유지하되, 패치 적용을 늦출 이유가 되어서는 안 됩니다.

공격 경로와 영향

공격자는 대상 프로젝트에 push할 수 있는 인증 계정을 이용해 악성 형식의 Jupyter Notebook을 커밋합니다. 이후 GitLab UI에서 해당 커밋의 notebook diff가 처리될 때 ipynbdiff/Oj 파서 경로가 실행되고, 취약한 GitLab Webservice(Puma) 프로세스에서 코드 실행이 가능해질 수 있습니다. 즉 다음 세 조건이 중요합니다.

1. 공격자에게 프로젝트에 대한 push 권한이 있습니다.
2. 조작된 notebook이 포함된 commit diff가 GitLab에서 열람·처리됩니다.
3. GitLab CE/EE가 위 표의 영향 버전에 해당합니다.

성공 시 영향은 CI Job 범위에 머물지 않습니다. Puma를 실행하는 GitLab 애플리케이션 프로세스 권한에서의 실행 가능성을 우선 가정해야 하며, 해당 서버가 접근하는 저장소·데이터베이스·토큰·내부 서비스의 노출 가능성을 함께 조사해야 합니다. 다만 실제 권한과 확산 범위는 배포 구조, 파일 권한, 네트워크 세분화, 비밀정보 관리에 따라 달라지므로 환경별 확인이 필요합니다.

즉시 조치: 업그레이드를 최우선으로

1) 자산과 버전을 확인한다

• [ ] Omnibus, Linux 패키지, Docker, Helm 등 배포 방식을 구분해 모든 GitLab CE/EE 인스턴스의 실제 버전을 수집한다.
• [ ] 관리자 노드에서 gitlab-rake gitlab:env:info 또는 배포 매니페스트로 버전을 확인하고, 인터넷 노출 여부·프로젝트 수·외부 협업 계정 유무와 함께 기록한다.
• [ ] 15.2.0~18.10.7, 18.11.0~18.11.4, 19.0.0~19.0.1이면 영향 대상으로 분류한다. 지원 종료 버전은 단순 패치가 아니라 지원되는 수정 버전 또는 최신 지원 릴리스로의 업그레이드 계획을 수립한다.

2) 18.10.8·18.11.5·19.0.2 이상으로 올린다

• [ ] GitLab 공식 2026-06-10 패치 릴리스의 수정 버전과 배포 방식별 업그레이드 문서를 기준으로 변경 작업을 준비한다.
• [ ] 변경 전 백업의 최신성 및 복구 절차를 검증하고, 데이터베이스 마이그레이션·롤백 조건·서비스 영향 시간을 승인 기록에 남긴다.
• [ ] 가능한 경우 검증 환경에 먼저 적용한 뒤 운영에 배포한다. 긴급 패치가 필요한 인터넷 노출 인스턴스는 위험도에 따라 유지보수 창을 앞당긴다.
• [ ] 업그레이드 후 로그인, 프로젝트 탐색, commit diff 열람, 저장소 접근, API, 백그라운드 작업 상태를 확인한다. 버전이 수정 버전 이상이며 Oj가 3.17.3으로 갱신됐는지 배포 산출물과 공식 릴리스 기준으로 확인한다.

패치 전 임시 완화책은 업그레이드를 대체하지 않습니다. 부득이하게 지연될 때만 변경 승인 하에 외부 협업자의 push 권한을 일시 축소하고, notebook 파일 변경 및 diff 열람을 제한·모니터링합니다. 서비스별 기능 영향이 있으므로 무차별적인 파일 차단이나 UI 비활성화 전에 운영 책임자와 협의해야 합니다.

권한 점검: Runner가 아니라 push 권한을 먼저 본다

이번 공격 경로의 시작점은 프로젝트 push 권한입니다. 다음 검토는 패치와 병렬로 하되, 패치를 대신하는 조치로 취급하지 않습니다.

• [ ] 외부 사용자, 게스트, 봇, 휴면 계정의 프로젝트 역할과 만료일을 점검한다. 불필요한 Developer 이상 권한은 제거하거나 만료일을 설정한다.
• [ ] 그룹 Owner·Maintainer와 프로젝트 멤버십을 검토해 notebook을 포함한 임의 파일을 push할 수 있는 대상을 최소화한다.
• [ ] 보호 브랜치에서의 push·merge 권한을 승인된 역할로 제한한다. 외부 기여가 필요한 경우 포크와 Merge Request 검토 흐름을 사용하고, 내부 브랜치 직접 push를 최소화한다.
• [ ] 자동화 계정과 액세스 토큰의 write_repository 범위·소유자·만료일·최근 사용 이력을 검토한다. 용도 불명 또는 장기 토큰은 폐기·교체한다.
• [ ] 프로젝트에서 Jupyter Notebook을 정당하게 사용하는지 식별하고, 민감 프로젝트의 .ipynb 변경은 코드 오너 검토 또는 추가 승인을 적용한다.

CI/CD 변수·Runner 최소권한은 여전히 일반적인 방어 수단입니다. 그러나 이 PoC는 CI 파이프라인 실행, privileged Runner, Docker 소켓, Runner 토큰을 전제로 하지 않습니다. 이 항목들을 이번 RCE의 핵심 완화책으로 보고하거나 패치 우선순위를 낮추면 안 됩니다.

탐지와 조사

업그레이드 전에 또는 침해가 의심될 때는 GitLab 애플리케이션과 Webservice를 중심으로 증적을 확보합니다. 단순히 CI Job 로그나 Runner 로그만 조사해서는 공격을 놓칠 수 있습니다.

우선 보존할 자료

• GitLab Webservice(Puma) 로그, Rails 애플리케이션 로그, Workhorse·NGINX/로드밸런서 로그
• 의심 프로젝트의 push·commit·merge request·파일 변경 이벤트와 감사 이벤트
• 조작 가능성이 있는 .ipynb 파일의 커밋 해시, 작성자, 최초·최종 push 시각, 해당 commit diff 열람 기록
• GitLab 호스트의 프로세스·인증·네트워크 로그 및 배포 환경의 보안 이벤트

조사 신호

• 평소와 다른 계정이 .ipynb 파일을 새로 추가하거나 대량 변경한 뒤 곧바로 diff를 열람한 패턴
• 외부 협업 계정·새로 생성된 계정·봇 계정의 push 권한 상승 또는 보호 브랜치 정책 변경
• Puma 프로세스 오류, 비정상 종료·재시작, 예기치 않은 자식 프로세스, 평소와 다른 외부 통신
• GitLab 서버에서의 비정상 명령 실행, 파일 변경, 자격증명 접근 또는 서비스 계정 활동

이상 징후가 있으면 관련 프로젝트·계정의 push 권한을 우선 중지하고, 의심 GitLab 호스트를 격리 범위에 포함합니다. 로그·커밋·파일 원본을 보존한 뒤 토큰·SSH 키·배포 자격증명 등 GitLab 서버가 접근할 수 있었던 비밀정보의 노출 여부를 조사하고 필요 시 교체합니다.

운영 대응 순서

1. 영향 판별: 모든 자체 관리형 GitLab의 CE/EE 버전과 인터넷 노출 여부, 외부 push 권한을 목록화한다.
2. 긴급 업그레이드: 영향 버전이면 18.10.8·18.11.5·19.0.2 이상으로 업데이트한다. 가능하면 최신 지원 버전을 선택한다.
3. 검증: 업데이트 후 서비스 핵심 기능과 버전·Oj 3.17.3 반영 여부를 확인한다.
4. 권한 축소: 불필요한 push 권한·write_repository 토큰·외부 협업 계정을 정리하고 보호 브랜치 정책을 확인한다.
5. 헌팅: Puma·Rails·프록시·감사 로그와 notebook 관련 commit/diff 이벤트를 같은 시간대 기준으로 연계 분석한다.
6. 사후 조치: 침해 가능성이 있으면 GitLab 서버 권한으로 접근 가능한 자격증명을 우선 교체하고, 재발 방지를 위한 권한 검토·로그 보존·업그레이드 기준을 갱신한다.

참고 자료

• GitLab, GitLab Patch Release: 19.0.2, 18.11.5, 18.10.8 (2026-06-10): https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-0-2-released/
• The Hacker News, Researcher Publishes GitLab RCE PoC: https://thehackernews.com/2026/07/researcher-publishes-gitlab-rce-poc.html
• GitLab Docs, Protected branches: https://docs.gitlab.com/user/project/repository/branches/protected/
• GitLab Docs, Upgrade GitLab: https://docs.gitlab.com/update/

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.