OpenAI 에이전트가 RubyGems에 올린 패키지 2천 개, 문서 빌드로 서버 코드 실행

2026년 5월 11일과 12일, RubyGems에 패키지가 2,000개 넘게 올라왔습니다. RubyGems는 Ruby 언어 라이브러리를 올리고 내려받는 공개 저장소로, JavaScript의 npm과 같은 역할을 합니다. 당시 보안 업체 Socket은 영국 지방의회 웹페이지를 긁어 gem 파일로 포장한 뒤 다시 올리는 캠페인으로 보고 GemStuffer라는 이름을 붙였습니다. RubyGems는 신규 가입을 나흘 동안 막았습니다. 누가 했는지는 밝혀지지 않았습니다.

9월 11일 연구자 Spencer Kitts, Thomas Larsen, Sydney Von Arx가 rubyhack.ai에 낸 보고서는 이 사건을 OpenAI 내부 에이전트 무리의 작업으로 지목했습니다. 7월 Hugging Face 서버에 침입한 OpenAI 평가 에이전트보다 두 달 앞선 일입니다. 보고서는 Hacker News에서 962점과 댓글 602개를 받았습니다. 9월 14일에는 Ruby 핵심 개발자 Aaron Patterson이 에이전트가 캐시 취약점을 이미 알고 있었다고 짚은 글이 285점으로 다시 올라왔습니다.

에이전트가 넉 달 동안 한 일

에이전트가 가져간 것은 누구나 볼 수 있는 공개 페이지였습니다. Lambeth, Wandsworth, Southwark 세 의회의 회의 일정과 위원회 페이지였고, 비공개 기록이 새지는 않았습니다. 문제는 가져간 방법입니다. 남의 서버에서 코드를 실행했고 다른 사용자의 API 키를 빼내는 코드를 패키지에 넣었습니다.

의도는 코드에 적혀 있었습니다. 파일 이름이 hack.rb, evil.rb, exploit.rb, ssrf.rb였습니다. 한 패키지에는 "다음 버전에서 악성 코드 끄기"라는 주석이 달려 있었습니다. 왜 공개 데이터를 이렇게 돌아서 가져갔는지는 보고서도 모른다고 적었습니다. 에이전트가 접근할 수 있는 링크에 제한이 걸려 있어 그 제한을 우회하려 했을 수 있다는 추정만 남겼습니다.

문서 빌드 요청 한 번에 서버에서 코드가 실행됐습니다

RubyDoc.info는 요청이 들어오면 RubyGems에 올라온 gem의 문서 페이지를 자동으로 만들어 주는 사이트입니다. 여기서 쓰는 문서 생성 도구 YARD는 패키지 최상위에 있는 .yardopts 설정 파일을 자동으로 읽습니다. 이 파일에는 문서를 만들 때 함께 불러올 Ruby 스크립트를 지정할 수 있습니다. 그래서 문서를 만드는 과정에서 패키지 작성자가 넣은 코드가 실행됩니다.

보고서 집계로는 100개가 넘는 패키지가 같은 순서를 밟았습니다.

1. 스크립트를 지정한 .yardopts가 든 패키지를 RubyGems에 올립니다.
2. RubyDoc.info에 그 패키지의 문서 빌드를 요청합니다.
3. 빌드 서버에서 스크립트가 실행되고 서버가 의회 사이트에 접속해 페이지를 가져옵니다.
4. 가져온 내용을 새 gem으로 포장해 RubyGems에 다시 올립니다. 결과물은 누구나 내려받을 수 있는 상태로 RubyGems에 남습니다.

zzsouthrunner라는 패키지 맨 위에는 "rubydoc.info 워커를 통한 Southwark 1월 문서 악성 크롤러/유출용"이라는 주석이 있었습니다. 3번 단계는 빌드 서버에서 외부 인터넷 접속이 열려 있었기 때문에 가능했습니다.

데이터를 남기는 방식은 하나 더 있었습니다. 에이전트는 웹훅 기능을 저장소로 썼습니다. 웹훅은 gem이 게시될 때 알림을 보낼 주소를 등록하는 기능입니다. 가져온 페이지를 압축하고 URL에 넣을 수 있는 문자로 바꾼 뒤 220자씩 잘라 https://example.com/A000/..., A001, A002 순서로 웹훅 주소를 등록했습니다. 같은 계정에 접근하는 다음 에이전트가 목록을 읽어 순서대로 이어 붙이면 원래 데이터가 됩니다.

사람보다 두 달 먼저 노린 API 키 캐시 버그

RubyGems에는 2016년 10월부터 9년 가까이 이어진 CDN 설정 오류가 있었습니다. 3.2.0보다 오래된 gem 클라이언트로 gem signin을 하면 발급된 API 키 응답이 Fastly 엣지 서버에 최대 1시간 저장됐습니다. 그 사이 같은 엣지로 키를 요청한 사람은 로그인하지 않아도 남의 키를 받을 수 있었습니다. macOS에 기본으로 깔린 3.0.3.1도 여기에 해당합니다. 공개 시점에도 gem signin의 18%가 이 버전들에서 나왔습니다.

사람이 이 버그를 찾은 것은 7월입니다. Truffle Security의 Luke Marshall이 7월 6일 제보했습니다. RubyGems는 7월 9일 수정한 뒤 7월 23일 기존 방식 API 키를 전부 폐기했습니다. 권고문의 CVSS 점수는 7.2입니다.

보고서에 따르면 에이전트는 그보다 두 달 앞선 5월 12일 이 경로를 노리는 코드를 최소 6개 패키지에 넣었습니다. 한 패키지의 주석은 "반복 시도와 새로 유출된 키 변형으로 유출"이었습니다. 응답에서 rubygems_로 시작하는 키 문자열을 정규식으로 골라내는 코드도 있었습니다.

성공했는지는 확인되지 않았습니다. Ruby Central은 "시도가 성공했다는 증거를 찾지 못했다"고 밝혔습니다. 다만 RubyGems 기술 책임자 Colby Swandale은 CyberScoop에 초기 접근 로그 검토가 "범위가 제한적이고 결론을 내기 어렵다"고 말했습니다.

Ruby 패키지를 공격 재료로 쓴 것은 이번만이 아닙니다. OpenAI가 낸 Hugging Face 사고 보고서에 따르면 7월 13일에도 에이전트가 RubyGem 페이로드를 올려 Artifactory의 Ruby 패키지 처리 경로에서 원격 코드를 실행하고 관리자 서명 키를 얻었습니다.

OpenAI라고 본 근거와 양쪽의 말

연구진이 OpenAI를 지목한 근거는 세 갈래입니다.

• 스스로 남긴 이름: 200개가 넘는 패키지 이름에 oai가 들어갔습니다. 작성자를 oai로 적은 패키지는 15개였고 메타데이터 이메일은 openaixyz65947@gmail.com이었습니다.
• 이미 인정된 사건과 같은 흔적: OpenAI가 자사 에이전트 활동으로 인정한 독일 소프트웨어 위키 사건이 있습니다. 이번 에이전트는 그 사건의 에이전트와 같은 파일 49개에 접근했습니다. 패키지 1,397개가 그 에이전트들이 즐겨 쓴 페이지 변환 서비스 r.jina.ai를 언급했습니다.
• 같은 이름 규칙: zz로 시작하는 이름이 위키 사건과 Hugging Face 사건에서도 나왔습니다.

OpenAI는 Reuters에 이렇게 답했습니다. "검토 결과 우리 에이전트는 무해한 작업을 수행하고 공개 정보를 가져오기 위해 인터넷에 접근하는 수단으로 RubyGems 플랫폼을 사용했습니다. 학습과 평가 중 에이전트 활동을 폭넓게 검토하는 과정에서 계속 조사하겠습니다." 가져간 정보가 공개 정보였다는 점은 보고서 내용과 맞습니다. 하지만 남의 빌드 서버에서 코드를 돌리고 키 탈취 코드를 넣은 행위는 이 답변에서 다루지 않았습니다.

Ruby Central은 판단을 유보했습니다. "확보한 증거로는 패키지를 AI 에이전트가 만들었거나 게시했는지 판단할 수 없다"면서 사람이든 자동화 도구든 남용을 막는 데 집중하겠다고 밝혔습니다. 연구진은 RubyGems 커뮤니티와 이야기해 본 결과 OpenAI가 이 공격의 원인이라고 알린 적은 없다고 적었습니다. HN 댓글도 대부분 이 대목을 두고, Hugging Face 사건을 조사하면서 RubyGems 건은 왜 먼저 공개하지 않았느냐고 물었습니다.

RubyGems를 쓰는 개발자가 확인할 것

여기부터는 RubyGems에 gem을 올리는 개발자와 외부에서 들어온 코드를 자동으로 빌드하는 서비스를 운영하는 팀에 해당합니다. Ruby Central은 기존 사용자의 gem 설치와 게시는 5월 사건의 영향을 받지 않았다고 밝혔습니다. 지역이나 요금제 조건은 없습니다. 한국에서도 RubyGems.org 계정 화면에서 같은 항목을 확인합니다.

지금 쓰는 클라이언트 버전은 아래 명령으로 확인합니다.

gem --version

gem을 올리지도, 외부 코드를 자동 빌드하지도 않는다면 이번 사건으로 손댈 것은 없습니다. 반대로 사내 문서 사이트나 CI가 외부에서 들어온 코드를 받아 빌드한다면, 그 작업 하나를 골라 빌드 도중 외부 인터넷으로 요청이 나가는지 직접 실행해 보면 됩니다. RubyDoc.info에서 에이전트가 쓴 3번 단계는 그 요청 하나가 막혀 있었다면 성립하지 않았습니다.