유출된 GitLab 이슈 이메일 주소, 타인 명의로 코드 커밋 및 CI 작업 실행 허용

Swati Khandelwal · 2026년 9월 23일 · DevOps 보안 / 공급망

GitLab이 이메일로 이슈를 등록할 수 있도록 각 사용자에게 제공하는 전용 이메일 주소는 하나의 자격증명(credential)이다. 이 주소를 손에 넣은 사람은 GitLab이 당신의 이름으로 커밋하는 패치를 이메일로 보낼 수 있으며, main을 포함해 당신이 푸시 권한을 가진 임의의 브랜치에 코드를 올리고 당신 명의로 CI/CD 작업을 시작할 수 있다.

GitLab은 각 사용자에게 "이 프로젝트에 이메일로 작업 항목 등록(Email work item to this project)"이라는 버튼 뒤에 이 주소를 표시한다. 해당 주소로 메일을 보내면 프로젝트에 이슈가 생성되며, 작성자는 당신으로 기록된다.

주소 중간에 위치한 문자열은 계정에 연결된 토큰이며, GitLab 공식 문서는 이 토큰이 만료되지 않는다고 명시하고 있다.

주소는 특정 프로젝트에만 속하는 것처럼 보이지만, 실제로는 그렇지 않다. 이 동작을 최초 보고한 Aikido Security는 사용자의 서로 다른 프로젝트에 대해 GitLab이 생성하는 주소들이 모두 동일한 토큰을 공유하며, 해당 토큰이 공개·비공개를 불문하고 계정이 이슈를 열 수 있는 모든 프로젝트에 적용된다는 사실을 확인했다.

GitLab은 이메일 발신자를 검증하지 않는다. 어떤 메일함에서 보내도 GitLab은 마치 당신이 보낸 것처럼 처리한다. 이 주소를 가진 사람은 당신의 메일함에 접근하지 않고도 당신으로 로그인한 것과 동일하게 당신의 권한으로 행동할 수 있다.

이 주소는 버그 등록 이상의 기능을 한다. Aikido는 GitLab의 이메일 기반 머지 리퀘스트(merge request) 기능을 이용해 이 주소를 코드 커밋 수단으로 전환하는 방법을 시연했다:

1. 주소 접미사를 -issue에서 -merge-request로 변경한다. GitLab은 그러면 이슈 대신 머지 리퀘스트를 생성한다.
2. 패치를 작성하고, 이메일 제목 줄에 대상 브랜치 이름을 기입한다.
3. 패치를 첨부해 전송한다. GitLab은 해당 브랜치에 패치를 적용하며, 브랜치가 존재하지 않으면 새로 생성한다.
4. 변경 사항은 해당 브랜치에 당신이 작성한 커밋으로 기록된다. 당신이 푸시 권한을 가진 브랜치라면 main도 포함된다.
5. 패치가 프로젝트의 .gitlab-ci.yml 파일을 수정하고 당신의 역할이 허용한다면, GitLab은 공격자의 작업을 당신 명의로 실행한다.

머지 리퀘스트 자체는 공격자가 제어하는 저장소 복사본을 대상으로 지정할 수 없기 때문에, 코드는 머지 리퀘스트가 아닌 첨부된 패치를 통해 전달된다.

이 공격의 피해 범위를 제한하는 요소가 두 가지 있다. 토큰은 해당 계정 자신의 권한만 가지므로, 공격자가 어디까지 침투할 수 있는지는 피해 계정의 역할에 달려 있다. Guest 계정의 유출된 주소는 거의 무용지물이지만, Maintainer의 주소라면 보호 브랜치와 CI/CD 시크릿에 접근할 수 있다.

특정 프로젝트를 타겟으로 하려면 주소 외에도 추가 정보가 필요하다. GitLab은 프로젝트 경로와 숫자 ID를 조합해 대상을 결정하므로, 공격자는 토큰 외에 해당 프로젝트의 경로와 ID도 알아야 한다. 공개 프로젝트는 이 두 가지를 모두 공개한다. 비공개 프로젝트는 프로젝트 이름을 노출하는 별도의 정보 유출이 필요하지만, GitLab의 프로젝트 ID는 추측하기 쉽다.

수신 이메일은 IP 제한 적용 대상이 아니기 때문에, 공격은 IP 허용목록 외부에서도 이루어질 수 있다. GitLab 공식 문서에도 수신 이메일은 IP 제한을 받지 않는다고 명시되어 있다.

Aikido는 비공개 프로젝트를 자신의 IP가 아닌 단일 IP 주소로 제한했다. GitLab은 브라우저 접속을 차단했고 git clone도 거부했지만, 머지 리퀘스트 이메일은 수락했으며 커밋은 main 브랜치에 그대로 반영됐다.

동일한 경로로 2단계 인증(2FA)도 우회된다. GitLab 문서는 2FA를 요구하는 인스턴스에서도 수신 이메일 기능은 2FA 없이 동작한다고 명시하고 있다.

GitLab.com의 모든 계정은 이 토큰을 하나씩 보유하고 있으며, 수신 이메일이 활성화된 자체 관리 GitLab 인스턴스(GitLab.com의 기본값)도 마찬가지다.

GitLab Dedicated는 GitLab이 이 기능을 자체 관리 인스턴스와 GitLab.com으로만 제한하고 있어 영향을 받지 않는 것으로 보이나, Aikido는 Dedicated 환경을 직접 테스트하지는 못했다고 밝혔다.

대응 방법

다른 사람들의 기능 사용 자체는 막을 수 없지만, 유출된 주소를 차단하는 것은 가능하다.

• 프로필의 개인 액세스 토큰 페이지에서 수신 이메일 토큰을 재설정한다. 재설정하면 모든 프로젝트 주소가 한 번에 교체되므로, 현재 사용 중인 주소는 새 주소를 배포하기 전까지 작동을 멈춘다.
• 자신의 README, 기여 가이드, 지원 페이지에서 게시된 주소가 있는지 확인한다. Aikido는 이 방법으로 약 12개의 유효한 주소를 발견했으며, 대부분은 버그 리포트 수신용으로 의도적으로 게시된 것이었고 일부는 널리 사용되는 오픈소스 프로젝트에 포함되어 있었다.
• 자체 관리 인스턴스의 관리자는 인스턴스 전체에서 수신 이메일을 비활성화할 수 있다. 개별 사용자가 이메일 기반 이슈 또는 머지 리퀘스트 생성을 직접 끄는 설정은 존재하지 않는다.

GitLab은 Aikido의 보고 이후 토큰 주변의 설명 문구를 변경했다. 이전에는 작업 항목(work items) 등록만 가능하다고 표시되어 있던 것이, 이제는 이슈와 머지 리퀘스트 모두 생성 가능하다는 내용으로 바뀌었으며, "이 토큰은 다른 데이터에 접근하는 데 사용될 수 없다"는 문구는 삭제됐다.

동작 자체는 변경되지 않았다. 토큰은 여전히 만료되지 않고, GitLab은 여전히 발신자를 검증하지 않으며, 개별 사용자가 이 기능을 끄는 스위치도 여전히 없다.

GitLab은 계정 소유자의 인증된 주소에서 온 이메일만 수락하는 방안을 검토하는 이슈를 열었지만, 아직 검토 단계에 머물러 있다.

Aikido에 따르면, 2026년 5월 HackerOne을 통해 처음 이 동작을 신고했으나 '의도된 동작'으로 종결 처리됐으며, 이후 6월에 GitLab에 기밀 이슈로 재신고했다. Aikido가 전한 GitLab의 입장은, 이는 다른 토큰과 마찬가지이며 유출된 자격증명은 어떤 것이든 나쁜 결과로 이어진다는 것이다.

The Hacker News는 GitLab과 Aikido 양측에 공식 입장을 요청한 상태다.