
RubyGems.org 공식 보안 공지에 따르면 패키지 저장소의 CDN 캐시 설정 결함으로 한 계정의 레거시 API 키가 다른 이용자에게 전달될 수 있었던 문제가 확인됐다. 운영진은 영향을 받을 수 있는 모든 레거시 키를 폐기하고 해당 로그인 경로를 종료했다.
문제는 구형 RubyGems 클라이언트가 로그인할 때 호출하던 GET /api/v1/api_key 응답에서 발생했다. 이 요청은 인증이 성공하면 전체 권한을 가진 새 레거시 키를 응답 본문으로 반환한다. gzip 압축이 적용된 경우 응답에 공유 캐시를 차단하는 헤더와 인증 정보에 따른 구분이 빠지면서, Fastly 엣지 노드가 키가 담긴 응답을 최대 1시간 저장할 수 있었다.
같은 엣지 노드로 연결된 다음 호출자는 인증하지 않은 상태에서도 앞선 이용자의 키를 받을 수 있었다. 취약점을 신고한 Truffle Security는 서로 다른 자체 테스트 계정으로 이 동작을 재현했다고 밝혔다. 의도적인 공격이 아니더라도 두 이용자가 같은 캐시 유효 시간 안에 로그인하면 키가 뒤바뀔 수 있는 구조였다.
영향 대상은 RubyGems 3.2.0 미만 클라이언트로 gem signin을 실행한 이용자다. RubyGems.org는 현재 gem signin 요청의 18%가 영향을 받는 버전에서 들어온다고 설명했다. 현행 macOS Tahoe에 기본 포함된 gem 3.0.3.1도 이 범위에 들어간다.
레거시 키는 특정 패키지로 권한이 제한되지 않고 만료 기한도 없다. 키를 확보한 사람은 계정이 소유한 gem의 새 버전을 배포하거나 버전을 내리고, 소유자를 추가·삭제하고, 웹훅과 신뢰할 수 있는 게시자를 설정할 수 있었다. 소유자나 신뢰할 수 있는 게시자를 추가한 경우에는 원래 키를 폐기한 뒤에도 접근 권한이 남을 수 있다.
이미 배포된 gem 파일은 같은 이름·버전·플랫폼 조합으로 덮어쓸 수 없어 변경 위험에 노출되지 않았다. gem install과 bundle install 역시 이번 캐시 결함의 영향을 받지 않았다. API 요청에 다중인증을 적용한 계정은 노출된 키만으로 배포나 소유권 변경을 수행할 수 없었다.
RubyGems.org는 보관 중인 최근 접근 로그에서 레거시 키가 악의적으로 사용된 흔적을 찾지 못했다고 밝혔다. 다만 문제의 응용 프로그램 측 조건은 2016년 10월 도입됐고, 전체 기간을 아우르는 로그가 남아 있지 않아 과거 악용 가능성을 배제할 수는 없다고 설명했다. 공식 자문은 위험도를 높음으로 분류했으며, 자체 평가 점수는 CVSS 4.0 기준 7.2점이다.
운영진은 지난 6일 신고를 받은 뒤 9일 캐시 차단 헤더를 추가하고 Fastly에 저장된 관련 객체를 제거했다. 이어 23일 전체 레거시 키를 폐기하고 영향 가능성이 있는 계정에 알림을 보냈다. 웹 화면이나 최신 CLI에서 만든 범위 제한 키와 OIDC 기반 단기 키는 영향을 받지 않았으며 폐기 대상에도 포함되지 않았다.
레거시 키를 사용하던 자동화와 CI는 다음 배포 시 HTTP 401 오류가 발생할 수 있다. 계정 소유자는 API 키 이력과 자신이 관리하는 gem에서 알 수 없는 새 버전, 예상하지 못한 버전 삭제, 낯선 소유자·게시자·웹훅이 추가됐는지 확인해야 한다. RubyGems.org는 새 키를 만들 때 권한 범위를 제한하고, API 다중인증과 신뢰할 수 있는 게시 방식을 사용할 것을 권고했다.
출처: RubyGems.org 공식 보안 공지 https://blog.rubygems.org/2026/07/22/security-advisory-legacy-api-key-leak.html
출처: RubyGems.org GitHub 보안 자문 https://github.com/rubygems/rubygems.org/security/advisories/GHSA-9j48-x3c3-mrp2
출처: Truffle Security 연구자 원문 https://trufflesecurity.com/blog/rubygems-cache-vulnerability









