TECH 으로 돌아가기
TECH HACKER NEWS 7분 읽기 22 READS

알파인 리눅스 GitLab 침해 시도: CVE-2026-97229가 남긴 공급망 교훈

오픈소스 배포판 알파인 리눅스(Alpine Linux)가 자사 GitLab 인스턴스를 겨냥한 공격 시도를 공개했다. 공격은 지난 10월 20일과 21일 이틀에 걸쳐 이뤄졌으며, 대상이 된 취약점은 CVSS 점수 10.0의 심각도 '치명적(critical)'으로 분류된 CVE-2026-97229였다. 알파인 측은 공격이 성공했다는 증거는 찾지 못했지만 성공 가능성을 완전히 배제할 수 없다고 판단해, 해당 인스턴스를 침해된 것으로 간주하고 처음부터 다시 구축했다. 흥미로운 점은 이 공격이 취약점 수정본이 공개된 지 일주일이나 지난 시점에 발생했고, 그럼에도 불구하고 '거의' 통할 뻔했다는 사실이다.

패치를 적용했는데도 뚫릴 뻔한 이유

이번 사건에서 가장 실무적으로 곱씹어볼 대목은 '업그레이드를 했는데도 취약점이 남아 있었다'는 점이다. CVE-2026-97229의 근본 원인은 GitLab 자체 코드가 아니라, 루비(Ruby)에 내장된 정규표현식 엔진 Onigmo에 있다. GitLab은 CI 설정에서 정규표현식을 평가하는 과정에서 이 버그에 노출됐다. GitLab은 10월 12일에 수정 릴리스를 내놓았지만, 그 수정은 GitLab이 자사 패키지와 컨테이너 이미지에 번들로 포함하는 루비에 가한 패치였다. 알파인은 10월 22일 GitLab을 19.3.6으로 올렸으나, 자신들의 이미지는 GitLab 공식 패키지가 아닌 표준 루비를 사용하고 있었기 때문에 그 패치를 받지 못했고 결국 취약한 상태가 유지됐다.

여기에서 분명한 교훈이 나온다. GitLab을 소스에서 직접 빌드하거나 자체 컨테이너 이미지로 운영하는 조직이라면, GitLab 버전만 올리는 것으로는 충분하지 않다. 루비 자체를 3.3.13, 3.4.12, 4.0.9 이상으로 올려야 한다. 업스트림 루비가 해당 수정을 반영한 것은 10월 23일로, GitLab 수정본보다 열흘이나 늦었다. 즉 애플리케이션 패치와 그 기반 런타임의 패치 타이밍이 어긋나는 구간이 존재했고, 그 틈이 실제 공격 창으로 작동한 셈이다.

공격은 어떻게 진행됐나

공격자는 새로 등록한 계정으로 조작된 CI 설정을 당시 19.3.4 버전으로 실행 중이던 인스턴스에 전송했다. 이 설정은 GitLab 워커 프로세스를 여덟 차례 크래시시켰고, 그중 네 번은 익스플로잇이 중간 단계까지 진행되다 다음 단계에서 실패했다. 특히 공격자는 알파인의 GitLab 컨테이너 이미지를 직접 내려받았는데, 알파인은 이를 공격자가 익스플로잇을 자신들의 정확한 빌드에 맞춰 조정하려 한 정황으로 해석했다. 서버에서 코드가 실제로 실행됐다는 증거는 없지만, 확인에 필요한 증거 자체가 더는 남아 있지 않은 탓에 알파인은 더 어려운 길인 전면 재구축을 택했다.

사용자 입장에서 당장 해야 할 일도 있다. 모든 비밀번호가 초기화됐기 때문에 GitLab이 다시 열리면 로그인 화면의 '비밀번호 찾기' 기능으로 새 비밀번호를 설정해야 한다. 또 gitlab.alpinelinux.org 계정과 같은 비밀번호를 다른 사이트에서 쓰고 있었다면 그쪽도 바꾸는 것이 안전하다. 알파인은 실제로 다른 사이트에서 유출된 비밀번호를 이용한 자동 로그인 시도를 관측했다고 밝혔다.

공급망 무결성 검증과 남은 한계

배포판 인프라에서 가장 민감한 부분은 결국 패키지 공급망의 무결성이다. 알파인은 aports 저장소와 패키지, 그리고 10월 21일 릴리스(3.21.9, 3.22.7, 3.23.7, 3.24.3)가 변조되지 않았음을 확인했다고 밝혔다. 검증 방식이 주목할 만하다. 10월 20일부터 22일 사이 추가된 모든 aports 커밋이 알려진 개발자의 기록된 푸시를 통해 들어왔음을, 공격자가 접근할 수 없는 기록들, 즉 한 개발자의 로컬 클론과 45개 빌더 전체와 대조해 확인했다. 10월 20~24일 사이 모든 아키텍처에서 빌드된 패키지가 git.alpinelinux.org에 공개된 커밋에서 비롯됐음도 검증했다. 공격자가 손댈 수 없는 복수의 독립적 기록을 기준점으로 삼았다는 점에서, 단일 저장소의 자기참조적 확인보다 신뢰도가 높은 접근이다.

다만 검증에는 아직 경계가 있다. 이 확인 작업은 10월 24일에 수행돼 10월 22일까지의 커밋과 24일까지의 패키지를 다뤘다. 그러나 GitLab은 10월 27일 폐쇄될 때까지 취약한 상태로 남아 있었기 때문에, 알파인은 같은 검증을 27일까지로 확장하고 있다고 밝혔다. 전면 재구축을 마친 GitLab은 공개 재개 전 테스트 단계에 있으며, 그동안 패키지 미러와 cgit, 메일링 리스트·IRC는 정상 운영된다.

마지막으로 이 사건을 GitLab만의 문제로 좁혀 보면 안 된다. 버그가 루비의 정규표현식 엔진에 있는 만큼, 신뢰할 수 없는 입력으로부터 정규표현식을 컴파일하는 프로그램이라면 무엇이든 노출된다. 사용자 입력을 정규식으로 받아 처리하는 서비스를 운영 중이라면 런타임 점검이 필요하다는 뜻이다. 알파인 3.22·3.23·3.24와 edge는 루비 3.4.12를, 3.21은 3.3.13을 제공하며 두 버전 모두 수정을 포함하므로, apk upgrade로 반영하면 된다. 문의는 infra@alpinelinux.org로 받는다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://alpinelinux.org/posts/GitLab-security-incident-CVE-2...
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기 →
처리 중...