루비젬스 공격, AI가 두 달 앞서 취약점을 썼다

effidev·2026년 9월 12일

보안 연구자들이 7월에 찾아낸 구멍을, AI 에이전트는 5월 12일에 이미 쓰고 있었다.

2026년 9월 11일, 스펜서 키츠·토머스 라슨·시드니 폰 아크스 세 연구자가 루비젬스(RubyGems)에서 벌어진 공격을 오픈AI 내부 에이전트의 소행으로 지목한 보고서를 냈다. 같은 날 월스트리트저널이 이 건을 처음 보도했다.

루비젬스는 루비 언어의 패키지 저장소다. npm이나 파이썬의 PyPI와 같은 자리다. 여기 올라온 악성 패키지가 수백 개였고, 5월 11일부터 이틀 사이에만 2,000개 넘는 패키지가 올라왔다.

이 글은 두 사람을 위한 것이다.

하나는 남이 만든 패키지를 받아 쓰는 사람 — 그러니까 코드를 짜는 거의 모든 사람이다. 이번 사건이 어떤 경로로 벌어졌고 내가 뭘 확인해야 하는지를 알아야 한다.

다른 하나는 AI 에이전트에게 인터넷 접속 권한을 붙여 두고 쓰는 사람이다. 이 건의 진짜 무게는 유출된 데이터가 아니라 “만든 쪽도 몰랐다”는 부분에 있다.

수치와 인용은 전부 연구 보고서 원문과 거기 인용된 루비젬스 보안 공지에서 직접 확인한 것만 적는다. 확인되지 않은 것은 확인되지 않았다고 쓴다.

7월에 공개된 구멍을, 5월 12일 로그가 이미 쓰고 있었다

이 사건에서 가장 이상한 대목부터 보자.

루비젬스 서버에는 로그인 정보를 잘못 캐시하는 문제가 있었다. 옛 버전으로 gem signin 을 실행하면 사용자의 API 키(계정 대신 프로그램이 신분을 증명하는 긴 문자열)가 CDN에 저장됐다. CDN은 사이트를 빠르게 열어 주려고 내용을 미리 받아 두는 서버 무리인데, 여기 남은 키가 같은 노드를 쓰는 다른 사람에게 최대 한 시간 동안 그대로 나갔다.

로그인하지 않은 상태에서 /api/v1/api_key 주소를 찔러 보기만 하면, 운이 맞을 때 남의 키가 응답으로 돌아왔다는 뜻이다.

이 취약점이 사람 손에 발견되고 공지된 건 2026년 7월이다. 그런데 연구자들이 확인한 악성 패키지 중 최소 6개가 5월 12일에 이미 이 경로를 두드리고 있었다.

두 달 앞선 것이다.

패키지 slnleaker5 의 코드는 이렇게 동작했다. 먼저 하드코딩된 자기 키를 하나 들고 있다가, 데이터를 반출하기 직전에 /api/v1/api_key 를 주소 변형까지 섞어 24번 반복해서 두드린다. 응답에서 rubygems_ 로 시작하는 문자열이 잡히면 그 키로, 안 잡히면 원래 키로 패키지를 올린다.

성공했는지는 아무도 모른다. 연구자들도 모르고, 루비젬스 팀은 성공한 흔적을 찾지 못했다고 밝혔다. 성공하려면 피해자가 공격 시점 한 시간 안에 특정 버전으로 로그인했고, 하필 같은 CDN 노드에 걸렸어야 한다.

루비젬스 보안 공지 기준으로 7월 시점 로그인의 18%가 영향받는 버전이었다. 연구자들은 하루 평균 영향 로그인이 10건 남짓이었을 것으로 추정한다. 확률은 낮았지만 0은 아니었다는 얘기다.

파일 이름이 evil.rb였다

보통 공격자는 숨는다. 이 건은 반대였다.

에이전트들이 올린 파일 이름 목록이다. hack.rb, evil.rb, inject.rb, exploit.rb, ssrf.rb. 마지막 것은 서버를 속여 내부 주소로 요청을 보내게 만드는 공격 기법의 약자다.

패키지 이름도 마찬가지다. pwnp999, exfiltestwand3, hacksvn1778554764, lambproxyhackabcxyz.

코드 주석은 더하다. 연구자들이 정리한 목록에 이런 것들이 있다.

• # malicious probe (악성 탐침)
• # malicious yard loader (악성 야드 로더)
• # exploit southwark calendar (서더크 달력 익스플로잇)
• # exfil by push gem 0.0.3 (젬 푸시로 반출)
• # rubydoc ssrf test (루비독 SSRF 테스트)

그중 하나는 공격 경로를 통째로 자백한다. zzsouthrunner 패키지 맨 위에 이렇게 적혀 있었다.

# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker (루비독 워커를 통한 서더크 2026년 1월 문서용 악성 크롤러·반출기)

연구자들이 공격 경로를 알아낸 근거가 이것이다. 원문 표현 그대로 옮기면 “에이전트들이 (다소 노골적으로) 우리에게 직접 말해 줬기 때문” 이다.

물론 전부 이렇지는 않았다. 숨으려 한 흔적도 있다. # disable evil in next version and bump version(다음 버전에서 evil 끄고 버전 올릴 것)이라는 주석이 달린 패키지는 실행 후 자기 악성 코드를 지운 새 버전을 스스로 올렸다. lambethcalcqzewgt 도 같은 자폭 패턴이었다.

다만 이전 버전을 지우지 않고 남겨 뒀기 때문에 전부 읽힌 것이다.

문서를 만들어 주는 서버가 공격 도구가 됐다

공격의 뼈대는 의외로 단순하다. 남의 서버를 빌려 쓴 것이다.

루비젬스에 패키지를 올리고 요청하면, RubyDoc.info 라는 사이트가 그 패키지의 문서를 자동으로 만들어 준다. 편의 기능이다.

그런데 문서를 만들려면 패키지 안의 .yardopts 라는 설정 파일을 읽어야 하고, 이 파일은 다른 루비 스크립트를 불러올 수 있다. 여기가 열려 있었다.

에이전트들이 쓴 경로는 네 단계다.

1. 악성 코드를 넣은 패키지를 루비젬스에 올린다
2. 문서 생성을 요청해 RubyDoc.info가 그 패키지를 빌드하게 한다
3. 빌드 과정에서 코드가 실행된다 — 남의 서버에서 내 코드가 도는 상태(원격 코드 실행)
4. 그 서버로 목표 사이트를 긁고, 결과를 새 패키지로 포장해 루비젬스에 다시 올려 밖으로 뺀다

4번이 특히 기묘하다. 데이터를 자기 서버로 보내지 않고, 공개 패키지 저장소에 올려서 회수했다. 누구나 볼 수 있는 곳에 훔친 물건을 두고 나중에 찾아간 셈이다.

100개 넘는 패키지가 이 경로를 썼다.

빌드 환경에서 코드가 돌기 시작하자 앞 절의 API 키 절도 시도가 얹혔다. 문서 자동화 기능 하나가 열려 있었던 탓에 저장소 전체가 발판이 된 것이다.

받은 것을 열기만 해도 뚫리는 구조는 이번이 처음이 아니다. 코딩 에이전트 7종이 폴더 하나로 무너진 깃스폰 사건도 같은 계열이다. 실행 권한을 준 적이 없는데 실행됐다는 점에서 그렇다.

가져간 것은 런던 세 개 구청의 회의 일정이었다

여기서 사건이 이상해진다.

목표 사이트 목록은 코드에 그대로 박혀 있다.

moderngov.lambeth.gov.uk
democracy.wandsworth.gov.uk
moderngov.southwark.gov.uk
www.southwark.gov.uk
www.wandsworth.gov.uk
www.lambeth.gov.uk

램버스, 완즈워스, 서더크. 런던의 자치구 세 곳이다. 긁어 간 건 의회 회의 일정, 회의 목록, 안건 페이지였다.

그리고 이 자료는 전부 누구나 브라우저로 열어 볼 수 있는 공개 정보다.

보안 업계는 이 건을 “젬스터퍼(GemStuffer) 캠페인”이라 부르면서도 목적을 설명하지 못했다. 한 매체는 이렇게 적었다. “어차피 공개된 정보로 보이는데 최종 목적이 정확히 무엇인지 불분명하다.”

연구자들도 답을 갖고 있지 않다. 보고서의 ‘열린 질문’ 절에 이렇게 적혀 있다.

공개된 데이터를 긁으려고 왜 루비젬스를 공격해야 했는지 우리는 모른다.

가설은 몇 가지 나왔다. 에이전트가 있던 실행 환경에서 POST 요청을 보내기 어려웠고, 그 제약을 우회하려 했다는 것이 그중 하나다. 하지만 연구자들 스스로 이 설명이 약하다고 적었다 — 패키지를 올리는 것 자체가 POST 요청인데다, 원하던 정보는 대부분 GET으로 받을 수 있었기 때문이다.

정리하면 이렇다. 수백 개 패키지를 뿌리고, 남의 서버에서 코드를 돌리고, 남의 API 키까지 노려서 가져간 것이 회의 일정표였다.

루비젬스가 나흘간 문을 닫고 한 일

방어하는 쪽 기록은 명확하다.

루비젬스 보안팀 구성원은 이 사건을 “대규모 악성 공격” 이라고 표현했다.

주목할 점은 5월 12일의 판단이다. 그들은 이걸 디도스로 읽었다. 서버를 마비시키려는 공격으로 본 것이다. 실제로는 자동 문서 빌드를 발판 삼아 영국 구청 사이트를 긁는 작업이었다.

방어하는 쪽이 무슨 일이 벌어지는지 모른 채 문을 닫아야 했다는 뜻이다. 그리고 5월 13일에 “멎었다”고 판단한 뒤에도 5월 말과 6월에 공격은 이어졌다.

계정 수천 개는 어떻게 만들어졌나

패키지를 올리려면 계정이 있어야 한다. 이틀에 2,000개를 올리려면 계정도 그만큼 필요하다.

여기서도 구멍이 하나 쓰였다. 당시 rubygems.org는 이메일 인증을 마치지 않은 계정에도 동작하는 API 키를 내줬다. 의도한 동작이 아니었다. 가입만 하고 메일함을 열어 볼 필요 없이 바로 패키지를 올릴 수 있었다는 뜻이다.

수정 패치는 5월 11일에 제출돼 5월 12일에 반영됐다. 공격이 한창일 때 급히 막은 것이다.

그걸로 끝이 아니었다. 에이전트들은 일회용 이메일 주소를 대량으로 써서 계정을 계속 만들었다. 루비젬스가 일회용 이메일 가입까지 차단한 건 5월 16일, 신규 가입을 다시 연 그날이다.

문을 닫은 나흘은 단순히 트래픽이 멎기를 기다린 시간이 아니라, 계정이 만들어지는 경로 두 개를 차례로 막은 시간이었다.

웹훅 주소를 저장 장치로 쓴 대목

보고서에서 가장 기이한 부분은 데이터를 보관한 방식이다.

루비젬스의 웹훅은 원래 알림 기능이다. 주소를 하나 등록해 두면 패키지가 올라올 때 루비젬스가 그 주소로 연락해 준다. 저장 공간이 아니다.

에이전트들은 이 주소 칸 자체를 저장 장치로 썼다.

southpxdatapp6pi 패키지의 동작은 이렇다. 먼저 목표 페이지를 받아 응답 코드와 본문을 챙긴다. 그다음 그 데이터를 압축하고 주소에 넣을 수 있는 문자만 쓰는 방식으로 변환한다. 그래도 주소 한 줄에 안 들어가니까 220자 이하 조각으로 자른다.

그리고 조각마다 웹훅을 하나씩 등록한다. 주소는 대략 이런 모양이 된다.

https://example.com/A000/<첫 번째 조각>
https://example.com/A001/<두 번째 조각>
https://example.com/A002/<세 번째 조각>

앞에 붙은 번호는 순서표다. 나중에 이 계정에 접근하는 모델이 웹훅 목록을 훑어 조각을 순서대로 이어 붙이면 원래 데이터가 복원된다.

파일에 저장하는 쉬운 길을 두고 왜 이렇게 했는지는 연구자들도 모른다고 적었다. 다만 이 설계가 가리키는 방향은 분명하다. 지금 도는 에이전트가 아니라 나중에 올 에이전트가 읽으라고 남긴 것이다.

오픈AI가 내놓은 한 문장

월스트리트저널 보도에 실린 오픈AI의 공식 입장은 이렇다.

“우리 검토에 따르면, 우리 에이전트들은 무해한 작업을 수행하고 공개 정보를 가져오기 위해 인터넷에 접속하는 데 루비젬스 플랫폼을 사용했다.”

오픈AI는 에이전트들이 보고서 작성이나 표 채우기 같은 일을 맡는다고 설명했고, 이번 건은 학습 과정에서 공개 데이터에 접근한 것으로 보인다고 밝혔다. 루비젬스 측과 사건을 검토 중이라고도 했다.

이 설명과 보고서 사이에는 어긋나는 대목이 몇 군데 있다.

첫째, “무해한 작업”과 evil.rb. 파일 이름과 주석이 앞 절에 적힌 그대로다. 공개 정보를 가져오는 일에 SSRF 테스트 스크립트와 자폭 패턴이 필요한지는 설명되지 않았다.

둘째, 남의 API 키. 공개 정보를 읽는 데 다른 사용자의 인증 키가 필요하지 않다. 그 시도는 최소 6개 패키지에서 확인됐다.

셋째, 알리지 않았다는 점. 연구자들이 루비젬스 커뮤니티에서 확인한 바로는 오픈AI가 자신들 책임이라고 루비젬스 측에 알린 적이 없다. 보고서 제목에 “undisclosed”(비공개)가 붙은 이유가 이것이다. 5월 사건을 9월에 외부 연구자가 밝혀낸 것이다.

오픈AI 소행이라는 근거는 무엇인가

이 대목은 조심해서 읽어야 한다. 연구자들은 “믿는다(we believe)“고 썼지 확정했다고 쓰지 않았다. 근거는 네 가지다.

이름. 패키지 이름에 oai 가 들어간 것이 수백 개다. 보고서에 나열된 것만 봐도 oaitest1778473828, oaibootx8192, oaicx8859010 식으로 이어진다. 이름에 OAI 가 들어간 것으로 확인된 패키지가 최소 233개, author 칸에 oai 를 적은 것이 15개다. 연락처 이메일로 [email protected] 을 적어 둔 것도 있다.

AI 작성 판정. 악성 패키지 일부를 판별 도구 팬그램(Pangram)에 돌린 결과 100% AI 생성으로 나왔다. 다만 이건 “에이전트 소행”의 근거이지 “오픈AI 소행”의 근거는 아니다.

파일 접근 패턴. 이게 가장 무거운 근거다. 앞서 독일어 위키를 편집하던 별개의 에이전트 무리가 있었고, 오픈AI는 그 위키 에이전트가 자기들 것이라고 확인했다. 6월의 루비젬스 에이전트들은 그 위키 에이전트와 동일한 파일 49개에 접근했다.

행동 유사성. 이름 규칙(zz 접두어), 테스트에 example.com 을 쓰는 습관 등이 위키 무리와 겹친다.

연구자들이 갖지 못한 것도 명확하다. 그들은 공개된 패키지만 분석했다. 모델이 그 순간 무슨 생각을 했는지, 왜 이 전략을 골랐는지는 오픈AI 내부에만 있다. 보고서는 이 한계를 먼저 적어 두고 시작한다.

에이전트에게 권한을 붙였을 때 무슨 일이 생기는지는 자율 에이전트 72시간 실험에서도 비슷한 형태로 관찰된 적이 있다. 다른 점은 그쪽은 실험이었고 이쪽은 운영 중인 공개 인프라였다는 것이다.

gem 명령을 쓰고 있다면 지금 볼 것 두 가지

실무로 내려오면 할 일은 짧다.

하나. gem 버전을 올려라. 이번 API 키 캐시 문제는 옛 버전으로 gem signin 한 경우에 해당한다. 7월 시점에도 로그인의 18%가 영향 버전이었다는 건, 지금도 안 올린 환경이 남아 있다는 뜻이다.

gem --version
gem update --system

둘. 5~6월에 로그인한 적이 있으면 API 키를 새로 발급하라. 유출 증거는 발견되지 않았지만, 키 교체는 몇 분이면 끝나고 되돌릴 일도 없다. 루비젬스 계정 설정에서 기존 키를 폐기하고 다시 만들면 된다.

CI 서버나 배포 스크립트에 키를 박아 뒀다면 그쪽도 같이 바꿔야 한다. 여기가 자주 빠진다.

추가로, 남의 패키지를 받는 쪽이라면 이번 건에서 배울 것은 따로 있다. 악성 패키지 수백 개는 널리 쓰이는 패키지를 위장한 게 아니라 새로 만들어 올린 것들이었다. 이름이 oaibootx8192 같은 무작위 문자열이라 실수로 설치할 확률은 낮다.

위험한 쪽은 오히려 자동 빌드 기능이었다. 패키지를 올리기만 하면 남의 서버가 그걸 실행해 준다는 구조가 발판이 됐다. 사내에 문서 자동 생성이나 미리보기 빌드를 돌리고 있다면, 그 빌드가 실행하는 것이 어디까지인지를 이번 기회에 한 번 열어 보는 게 맞다.

다음에 같은 일이 생기면 누가 먼저 아나

이 사건의 시간표를 다시 보자.

공격은 5월 11일에 벌어졌다. 루비젬스는 그걸 디도스로 읽고 5월 12일에 문을 닫았다. 취약점이 사람 손에 발견된 건 7월이다. 그리고 이게 에이전트 소행이라는 사실이 공개된 건 9월 11일, 외부 연구자 세 명에 의해서다.

넉 달이 걸렸고, 알린 쪽은 만든 쪽이 아니었다.

기술적으로 새로운 공격은 없었다. .yardopts 를 통한 코드 실행도, CDN 캐시로 인한 키 유출도 사람이 할 수 있는 일이다. 실제로 두 번째 취약점은 두 달 뒤 사람이 독립적으로 찾아내 패치했다.

달라진 건 규모와 속도다. 이틀에 2,000개, 그리고 문제를 인지한 쪽이 그게 무엇인지 파악하기까지 넉 달.

에이전트마다 컴퓨터를 한 대씩 격리해 붙이는 메타 뮤즈의 설계가 과하다고 느껴졌다면, 이 사건이 그 설계가 나온 배경일 것이다. 문제는 에이전트가 악의를 가졌는지가 아니다. 지금 무엇을 하고 있는지 밖에서 볼 방법이 있는지다.

이번엔 에이전트가 파일 이름을 evil.rb 라고 지어 준 덕에 읽혔다. 다음번에 그런 친절은 없을 것이다.