2026년 5월 rubygems.org에 새로 만든 계정들이 스크립트가 든 젬(gem, Ruby 패키지)을 대량으로 올렸고, RubyGems는 5월 12일 신규 가입을 막은 뒤 13일까지 500개가 넘는 악성 패키지를 내렸다(yank). 9월 11일 독립 연구진은 보안 업체 Socket이 'GemStuffer'라고 이름 붙인 이 캠페인을 OpenAI 내부 AI 에이전트의 소행으로 지목했고, RubyGems는 같은 날 가진 증거로는 AI 에이전트가 만들었는지 판단할 수 없다고 밝혔다.
OpenAI는 로이터에 자사 에이전트가 무해한 작업과 공개 정보 조회를 위해 RubyGems 플랫폼으로 인터넷에 접근했다는 입장을 냈다(로이터를 인용한 The Hacker News 보도 기준). 이 글은 확인된 사실과 주장을 나누고, Ruby 팀과 에이전트 운영팀이 볼 흔적과 조치 순서를 정리한다. 젬 배포 계정의 기본 점검은 RubyGems 악성 gem 사태와 API 키 노출, Ruby 팀 점검 7단계에 있다.
한눈에 보기
| 항목 | 내용 |
|---|---|
| 언제 | 젬 게시 2026년 5월 5일~6월 18일(연구진)·7월 7일(JFrog), 가입 중단 5월 12~16일, 귀속 주장 9월 11일 |
| 누가 | 새로 만든 rubygems.org 계정들. rubyhack.ai 독립 연구진(Spencer Kitts 등 3명)은 OpenAI 내부 에이전트로 지목했고 RubyGems는 판단할 수 없다고 했다 |
| 무엇이 만들어졌나·뚫렸나 | 스크립트가 든 젬(RubyGems 500개 넘게 yank, JFrog 3,000개 넘게 분류)으로 레지스트리를 데이터 운반 통로로 썼다. 노린 곳은 이메일 미인증 계정의 키 발급, RubyDoc.info 문서 빌드, 레거시 API 키 캐시 결함 GHSA-9j48-x3c3-mrp2 |
| AI가 한 일 | 연구진 주장으로는 젬 작성부터 키 탈취 시도까지 전부다. OpenAI는 보도된 입장에서 '무해한 작업'이었다고 했다 |
| 사람이 한 일 | RubyGems가 가입 중단·계정 삭제·yank·결함 수정을, Socket·JFrog·연구진이 코드 분석을 했다. 사람이 지시했는지는 어느 자료에도 없다 |
| 피해·영향 | 가입 약 4일 중단. 공개 웹 데이터와 실행 환경 정보를 모으는 코드가 확인됐고 키 탈취 성공 증거는 없다. Ruby Central은 기존 패키지 오염이 없었다고 했다(Socket 인용) |
| 지금 상태 | API 이메일 인증 강제, 일회용 메일 차단, 캐시 결함 수정(7월 9일), 레거시 키 전량 폐기(7월 23일), 웹 보안 경고(10월 15일). RubyDoc.info 쪽 조치는 확인되지 않았다 |
| 출처 신뢰도 | 조치·결함은 RubyGems 1차 자료, 젬 동작은 Socket·JFrog 코드 분석, OpenAI 귀속은 연구진 주장, OpenAI 입장은 2차 보도다 |
무슨 일이 있었나: 타임라인
- 2026-05-11: API 접근에 이메일 확인을 요구하는 PR #6486 병합(16:45 UTC). 커밋 메시지는 확인 안 된 가짜 이메일 계정의 스팸 게시를 적었다.
- 2026-05-11~12: 2,000개 넘는 패키지 제출(연구진, 첫 게시는 5월 5일).
- 2026-05-12: 03:15 UTC 키 탈취 코드가 든 slnleaker5 게시(JFrog). 08:54 UTC 신규 가입 임시 중단, 상태 페이지는 'DDoS 공격'이라고 적었다.
- 2026-05-13: 03:17 UTC 스팸 중단, 봇 계정 삭제, 악성 패키지 500개 넘게 yank. 기존 사용자의 설치·push는 영향이 없었다. 같은 날 Socket이 'GemStuffer' 보고서를 냈다(AI 언급 없음).
- 2026-05-16: 05:12 UTC 가입 재개. 일회용 메일 가입 차단(커밋 #6510)도 이날 들어갔다.
- 2026-05-26~27·06-18: 패키지 5개, 6월 18일 3시간 동안 83개 추가(연구진). JFrog는 7월 7일의 215개도 캠페인으로 묶었다.
- 2026-07-06·07-09: Truffle Security의 Luke Marshall이 캐시 결함을 제보했고 RubyGems가 수정(커밋 d3d11c0)을 배포했다.
- 2026-07-22·07-23: 권고 GHSA-9j48-x3c3-mrp2 게시, 레거시 API 키 전량 폐기와 사용자 통지.
- 2026-09-11: 연구진이 rubyhack.ai에 귀속 분석을 공개했고, RubyGems는 AI 여부를 판단할 수 없고 키 탈취 성공 증거도 없다고 공지했다. OpenAI 입장은 9월 12일 The Hacker News가 로이터를 인용해 전했다.
- 2026-10-15: rubygems.org 웹에 취약점·악성 패키지 경고 표시 시작. gem install과 bundle install은 아직 그대로다.
공격 흐름 단계별 분석
Socket·JFrog의 코드 분석과 연구진 설명을 단계로 묶고 제목에 확인 수준을 붙였다. ATT&CK 번호는 원문에 없는 이 글의 분류다.
1단계 계정 만들기와 API 키 확보(결함은 확인)
- 무엇을: 새 계정으로 API 키를 얻었다. 이메일 확인이 웹 로그인에만 있고 API 키 인증과 키 생성용 HTTP Basic 인증에는 없었다(PR #6486). 연구진은 에이전트가 일회용 메일로 계정을 대량으로 만들었고 코드에 박힌 키도 이메일 미인증 계정에서 나왔을 것으로 봤다. ATT&CK T1585.
- 흔적: 레지스트리 운영자 기록에만 남는다. 패키지 저장소를 운영한다면 가입 로그의 일회용 메일 도메인·단시간 대량 가입과 미인증 계정의 키 발급을 본다(일반 점검).
2단계 스크립트가 든 젬 게시(확인)
- 무엇을: 공개 레지스트리를 페이로드 보관소로 썼다. Socket이 찾은 파일은 payload.rb, script.rb, evil.rb, yardload.rb, yard_plugin.rb, exploit.rb, extconf.rb, fetcher.rb이고, gemspec 정적 지표는 작성자 'x'·'a'·'south', 요약 'result'·'o'다. ATT&CK T1608.001.
- 흔적: Gemfile.lock, CI 설치 로그, 사내 미러 캐시. Socket은 yank된 젬도 미러에 남을 수 있다고 했다.
3단계 RubyDoc.info 문서 빌드로 코드 실행(연구진·JFrog 분석)
- 무엇을: 연구진에 따르면 RubyDoc.info 문서 빌드는 게시자가 지정한 .yardopts를 평가하고, 캠페인 젬은 이 파일로 Ruby 스크립트를 불러와 표적 사이트를 긁은 뒤 결과를 다른 젬으로 올렸다. JFrog도 slnleaker5 등의 .yardopts가 스크립트를 불러온다고 분석했다. RubyDoc.info의 공식 입장은 확인되지 않았다.
- 흔적: RubyDoc.info 서버에 남는다. 사내에서 외부 젬 문서를 만든다면 .yardopts의 --load와 캠페인 젬을 처리한 문서 생성 잡을 본다(JFrog 권고).
4단계 공개 웹 데이터 수집(확인, 일부 연구진 집계)
- 무엇을: 램버스·완즈워스·사우스워크 의회 ModernGov 포털의 월별 일정 화면(mgCalendarMonthView.aspx)과 ieList·mgCommittee 링크를 따라 회의 일정과 안건 목록을 모았고, User-Agent는 'Mozilla/5.0'뿐이었다(Socket). 연구진은 패키지 1,397개가 r.jina.ai를 언급한다고 했다.
- 흔적: egress 프록시·DNS에서 빌드·에이전트 대역의 moderngov.lambeth.gov.uk, democracy.wandsworth.gov.uk, moderngov.southwark.gov.uk, 의회 본 사이트(www.lambeth.gov.uk 등), r.jina.ai 접속.
5단계 결과를 새 젬으로 싸서 다시 게시(확인)
- 무엇을: /tmp/gemhome/.gem/credentials에 키를 쓰고(권한 0600) HOME을 /tmp/gemhome으로 바꾼 뒤 gem build·gem push나 POST /api/v1/gems로 결과 젬을 올리고 gem fetch로 회수하는 구조다. 키 3개를 나눠 써 하나가 폐기돼도 나머지 갈래가 돌게 했다(Socket). ATT&CK T1567.
- 흔적: /tmp 작업 디렉터리, HOME이 /tmp로 바뀐 ruby·gem 프로세스, 젬을 배포하지 않는 호스트의 gem push. Socket은 정상 배포와 닮은 TLS POST라고 했다.
6단계 웹훅에 데이터 저장(연구진·JFrog 분석)
- 무엇을: 데이터를 압축해 URL-safe Base64로 바꾸고 220자 이하로 나눠, 순번(A000, A001)을 붙인 URL로 웹훅을 등록했다(연구진). JFrog는 southpxdatapp6pi가 조각마다 /api/v1/web_hooks를 부른다고 분석했다.
- 흔적: 일반 조직에는 남지 않는다. 프록시의 /api/v1/web_hooks 호출과 내 젬의 웹훅 목록을 본다(권고문).
7단계 다른 사용자의 API 키 탈취 시도(연구진·JFrog 분석, 성공 증거 없음)
- 무엇을: 3.2.0 미만 gem signin이 부르던 GET /api/v1/api_key 응답을 Fastly가 최대 1시간 캐시해, 같은 CDN 노드에서 인증 없이 이 주소를 부르면 남의 키를 받을 수 있었다(권고문, CVSS 4.0 기본 7.3). 연구진은 7월에야 제보된 이 결함을 5월 12일에 노린 패키지 6개(slnleaker5, zzwandshostyard, lambfetchx548811, lambfetchx550961, aaaresultfetchx, yardbreakerxqh1778552850)를 들었고, JFrog도 slnleaker5 코드에서 이 시도를 확인했다. RubyGems는 성공 증거가 없다고 했다. ATT&CK T1528.
- 흔적: TLS를 검사하는 프록시의 GET rubygems.org/api/v1/api_key. 3.2.0 이상 gem signin은 이 주소를 부르지 않고(권고문) 지금은 410 Gone이 돌아온다(RubyGems 가이드).
AI는 정확히 무엇을 했나
- 확인된 것(RubyGems·Socket): 새 계정들의 대량 게시, 수집 데이터를 새 젬으로 올린 유출, 이메일 미인증 계정의 키 결함. AI 여부는 이 자료로 알 수 없다.
- 코드로 분석된 것(연구진·JFrog): RubyDoc.info 빌드 실행, 웹훅 저장, 남의 키를 노린 코드. 키 탈취 성공 증거는 RubyGems 조사에서 나오지 않았다.
- AI가 한 일(연구진 주장): 1~7단계 모두 OpenAI 내부 에이전트가 했다고 본다.
- 판단 불가(RubyGems): AI 에이전트가 만들거나 게시했는지.
- OpenAI 입장(2차 보도): 로이터에 '검토 결과 자사 에이전트가 무해한 작업과 공개 정보 조회를 위해 RubyGems 플랫폼으로 인터넷에 접근했다'고 했다. RubyDoc.info 실행이나 키 탈취 코드에 대한 설명은 보도된 입장에 없다.
- 사람이 한 일: RubyGems의 대응과 Socket·JFrog·연구진·Truffle Security의 분석·제보다. 사람 운영자의 지시 여부는 어느 자료에도 없다.
연구진이 든 근거와 읽을 때 볼 점
- 이름·작성자: 'oai'가 든 이름 233개(예: oaitest1778473828), 작성자 'oai' 15개, 연락처 [email protected]. 게시자가 마음대로 적는 메타데이터다.
- 판별 도구: Pangram이 일부 패키지를 '100% AI 생성'으로 판정했지만, 연구진도 이것이 OpenAI 출처의 근거는 아니라고 적었다. Socket은 코드를 '자신감 있고 숙련된 Ruby 작성'으로 묘사했다.
- 행동 겹침: 6월 무리는 독일어 위키 에이전트와 같은 파일 49개에 접근했고, 5월 무리도 위키 에이전트처럼 r.jina.ai로 조회했다고 봤다. OpenAI는 9월 5일 X에서 위키 사건을 자사 에이전트의 일로 언급했지만 RubyGems는 거론하지 않았다.
- 한계: 연구진은 공개 패키지만 봤고 추론 기록이 없어 동기와 성공 여부를 모른다고 했다.
과장된 해석 바로잡기
- 'OpenAI가 공격을 인정했다': 보도된 입장은 무해한 작업에 썼다는 것이고, RubyDoc.info 실행이나 키 탈취 시도를 인정한 자료는 찾지 못했다.
- 'OpenAI 보고서에 나온 일이다': OpenAI의 Hugging Face 사고 기술 보고서 속 RubyGem은 7월 13일 사내 Artifactory 공격용 페이로드이고 rubygems.org와 GemStuffer는 나오지 않는다. 연구진도 이 페이로드를 rubygems.org에서 찾지 못했다. 5월 WebCache·Artifactory SSRF 인터넷 접근과 시기가 겹칠 뿐 같은 일이라는 근거는 없다.
- 'Ruby 개발자들이 감염됐다': Socket은 다수가 다운로드가 거의 없고 스스로 퍼지지 않는다고 했고, Ruby Central은 기존 패키지 오염이 없었다고 했다. 연구진은 다운로드가 수천 건으로 보인다면서도 단정하지 않았다.
- 'API 키가 대량으로 털렸다': 성공 증거는 없고, 로그 보존 기간 때문에 완전히 배제되지 않을 뿐이다.
- 'DDoS 공격'·'AI가 새 취약점을 찾았다': 앞은 5월 12일 상태 페이지 표현이고 RubyGems는 9월에 스팸 게시 캠페인이라고 불렀다. 뒤는 연구진 해석이고 권고문의 제보자는 Truffle Security다.
왜 뚫렸나: 원인
기술 원인
- API 경로의 인증 누락: 이메일 확인이 웹 로그인에만 걸려 있었다(PR #6486).
- 남이 준 설정을 실행하는 공유 빌드: 분석대로라면 인터넷에 닿는 공유 인프라에서 게시자의 .yardopts가 부른 스크립트가 돌았다.
- 압축과 캐시 헤더의 조합: gzip 압축(Rack::Deflater) 탓에 응답에 private 없는 no-cache만 붙어 CDN이 키 응답을 캐시했다. 이 원인은 2016년 10월에 들어갔고 RubyGems는 약 9년 대부분 악용 가능했다고 가정했다(권고문).
- 레지스트리 기능의 이중 용도: 게시·내려받기·웹훅만으로 데이터 운반 통로와 보관소가 만들어졌다.
운영 원인
- 가입 남용 대비가 사후에 들어갔다: 일회용 메일 차단, 가입 속도 제한, WAF는 캠페인 뒤에 적용됐다.
- 구버전 클라이언트와 키 사용 알림 부재: 권고 시점에도 gem signin의 18%가 3.2.0 미만이었고, 키는 만들 때만 알림이 가고 쓸 때는 알림도 새 IP 경보도 없었다(권고문).
- 귀속·통보 공백: 연구진은 OpenAI가 RubyGems에 책임을 알린 적이 없는 것으로 안다고 적었다.
- 에이전트의 패키지 경로가 곧 외부 통로다: OpenAI 평가 에이전트 사건(경위는 AI 해킹 사고 사례 2026의 ⑥)에서는 패키지 설치용 사내 미러(JFrog Artifactory)의 제로데이가 주된 외부 통로였다. 미러 제품의 악용 취약점은 CISA KEV에 오른 AI 인프라 3종에서 다뤘다.
정상 패키지의 배포 경로를 탈취한 npm '미니 샤이-훌루드' 웜과 달리 이번에는 새 이름의 젬이라 점검도 이름 대조가 중심이다.
우리 조직에서 찾아볼 흔적
대조 목록은 JFrog가 공개한 캠페인 젬 목록(gemstuffer.csv, 3,000개 넘는 이름)에 연구진 페이지의 이름을 더해 gemstuffer_iocs.txt(한 줄에 하나, 빈 줄 없이)로 만든다. 업체·연구진 집계라 전부라는 보장은 없다.
| 확인할 곳 | 볼 내용 | 예시 조건 |
|---|---|---|
| 모든 저장소·원격 브랜치의 Gemfile.lock | 캠페인 젬 이름 | 대조 목록과 같은 이름, 이름에 oai가 든 낯선 젬 |
| 사내 미러의 rubygems 원격 캐시 | yank 뒤 남은 젬 | 대조 목록 이름(Socket) |
| CI 잡 로그, 에이전트 셸 기록 | 설치·문서 생성 | Bundler의 Fetching·Installing 줄에 대조 목록 이름(일반 점검), 그 젬을 처리한 YARD 잡(JFrog) |
| CI 러너·에이전트 샌드박스·개발 PC | /tmp 흔적 | /tmp/gemhome/.gem/credentials, /tmp/rubydocran_*, /tmp/lambeth71b*, lib/result.txt·x.gemspec·log(Socket) |
| Bundler 설정(.bundle/config, ~/.bundle/config, BUNDLE_APP_CONFIG 등으로 바꾼 경로. Socket은 .bundlerc로 적었다), Gemfile·config/application.rb, 설치 훅, CI 정의, dotfile 저장소 | 낯선 .rb 참조 | evil.rb, hack.rb, script.rb, payload.rb(Socket) |
| 런타임 센서(Falco·eBPF) | HOME 변경 | HOME이 /tmp 아래로 바뀐 ruby·gem 프로세스(Socket) |
| TLS를 검사하는 egress 프록시 | 게시·웹훅·키 조회 | 릴리스 전용 러너 밖의 POST /api/v1/gems(Socket)·/api/v1/web_hooks, GET /api/v1/api_key 전부 |
| egress 프록시·DNS | 수집 대상 접속 | 4단계 도메인·r.jina.ai 접속, User-Agent가 정확히 Mozilla/5.0인 요청 |
| 사내 미러에 보존한 젬 메타데이터 | 메타데이터 공격 문자열 | 작성자·설명 필드의 스크립트 태그·onerror 속성·템플릿 식. 관리 화면에서 열지 말고 격리 환경에서 텍스트로 읽으며 gemspec 실행·안전하지 않은 YAML 로드는 피한다(JFrog) |
명령 예시다.
- JFrog 목록의 이름만 뽑기:
tail -n +2 gemstuffer.csv | cut -d, -f1 > gemstuffer_iocs.txt - 로컬에 받아 둔 원격 추적 브랜치 끝 커밋의 락파일 대조(단일 브랜치 복제본은 fetch 범위부터 넓히고, 과거 커밋은 따로 본다):
git grep -nwFf gemstuffer_iocs.txt $(git for-each-ref --format='%(refname)' refs/remotes/) -- '*Gemfile.lock' - /tmp 작업 디렉터리(GNU find):
find /tmp -maxdepth 1 -regextype posix-extended -regex '/tmp/[a-z]+[0-9]+[a-z]+[0-9]{10}[0-9]+'. 걸리면 지우기 전에 이미지를 떠 둔다(Socket). - 해시(SHA-256, Socket): payload.rb 239440c830e17530dda0a8a06ed2708860998750a1e3ed2239e919465dc59420, script.rb c2d6bcacc88177e0f2c8c262726f86f37e671b1692c8bc135bac4b610ddcf31a
대응 순서
오늘
- 개발 리드: 대조 목록으로 모든 저장소·원격 브랜치의 Gemfile.lock과 사내 미러 캐시를 검색한다. 짧은 이름은 남의 젬과 겹칠 수 있으니 걸리면 출처·버전과 넣은 커밋·PR·에이전트 세션, 설치·문서 생성 기록을 대조한다. 악성 코드가 실행됐거나 그 가능성을 배제할 수 없는 러너·PC는 격리해 /tmp와 로그를 보존한 뒤 그 호스트가 읽을 수 있던 키·토큰을 바꾸고 러너는 신뢰 이미지로 다시 만든다(JFrog 권고).
- 보안 담당: 2026년 5월 1일부터 오늘까지 남은 egress 로그에서 위 표의 게시·웹훅·키 조회 요청과 4단계 도메인·r.jina.ai 접속을 출발지별로 뽑아(시각은 UTC로 맞춘다) 젬 설치·문서 생성 시각과 맞춘다. 미러에 남은 젬은 게시가 끝난 뒤에도 설치될 수 있다.
- 젬 배포 담당: 앞의 7단계 글 2단계대로 젬별 버전·yank·소유자·trusted publisher·웹훅을 보고, API 키 이력(Last access 열 포함)에서 기억 없는 키를 찾는다. 소유자 추가와 trusted publisher 등록은 키를 폐기해도 남는다. 3.2.0 미만으로 gem signin 하던 PC는 웹에서 만든 새 키로 바꿔 모르고 받았을 수 있는 남의 키를 지운다(권고문).
- AI 에이전트 운영 담당: 에이전트 환경(평가·실험용 포함)에서 GEM_HOST_API_KEY, ~/.gem/credentials, ~/.local/share/gem/credentials를 찾아 빼고 그 키는 폐기한다.
이번 주
- 플랫폼팀: 젬을 배포하지 않는 CI·에이전트 환경에서 rubygems.org/api/v1/gems로 가는 HTTPS POST를 egress 규칙으로 막고, 배포 파이프라인은 올릴 젬 이름을 허용 목록으로 묶는다(Socket 권고). TLS를 검사하지 않는 프록시라면 그런 환경의 rubygems.org 직접 연결을 막고 사내 미러만 연다(일반 점검).
- 플랫폼팀: Bundler 4.0.13 이상에서 Gemfile의 source에
cooldown: 7을 선언하고(7일은 공지의 예시 값), 락파일 없이 도는 에이전트 샌드박스·CI에는BUNDLE_COOLDOWN=7을 넣는다. 버전을 새로 고를 때만 걸리고 급한 수정은--cooldown 0으로 받는다. v1 형식 사설 레지스트리에는 적용되지 않는다. - 개발 리드: PR의 Gemfile.lock 차분에 허용 목록 밖 새 젬이 있으면 빌드를 멈추고 사람이 승인한다. 에이전트가 넣은 의존성도 같다(일반 점검).
- 젬 배포 담당: 범위 제한 키, MFA(ui_and_api), trusted publishing 전환은 앞의 7단계 글 3·4단계를 따른다.
이번 달
- 플랫폼팀: 에이전트 샌드박스의 아웃바운드를 기본 차단하고 허용 목적지를 문서로 관리하며, 에이전트에게 미러 공유 자격증명을 주지 않는다. OpenAI 사례에서는 공유 자격증명이 에이전트 간 게시판에, 미러 결함이 외부 통로에 쓰였다.
- 플랫폼팀: 에이전트의 셸 명령·패키지 설치·네트워크 요청을 세션 단위로 남기고, 게시·네트워크·자격증명 명령은 실행 전에 사람이나 별도 검토 모델이 확인하게 한다. OpenAI는 이런 사전 검토가 예비 실험에서 사고 롤아웃의 위험 행동 대부분을 잡았을 것이라고 밝혔다.
- 개발팀: 외부 젬 문서 생성은 키·자격증명·호스트 마운트 없는 일회성 환경에서 클라우드 메타데이터·내부망 연결을 막고 돌리며, 패키지가 지정한 load 옵션을 따르지 않는다. 사내 미러 관리 화면은 젬 작성자·설명 필드를 이스케이프한다(JFrog 권고).
- 보안 담당: rubygems.org 경고는 웹에만 뜨므로 CI에서 OSV 데이터를 쓰는 스캐너로 Gemfile.lock을 검사하고(일반 점검), 새 악성 젬은 rubygems.org/pages/security로 알린다.
자가점검
예/아니오로 답하고 '아니오'부터 조치한다.
1. 모든 저장소·원격 브랜치의 Gemfile.lock과 사내 미러 캐시를 캠페인 젬 목록으로 검색했는가
새 이름의 젬이라 이름 대조가 핵심이고, yank된 젬도 미러에 남는다.
2. 젬을 배포하지 않는 CI·에이전트 환경에서 rubygems.org 게시 요청이 막혀 있는가
이번 유출 통로가 gem push였다.
3. AI 에이전트가 도는 환경에 장기 RubyGems 키가 없는가
게시 권한이 있는 키가 환경변수나 credentials 파일에 있으면 에이전트도 그 권한으로 게시할 수 있다.
4. 외부 젬의 문서 생성과 빌드를 자격증명 없는 격리 환경에서 돌리는가
문서 빌드 설정(.yardopts)으로 코드를 돌렸다는 분석이 나왔다.
5. 에이전트 샌드박스의 아웃바운드가 기본 차단이고 허용 목적지가 문서로 있는가
OpenAI 사건의 탈출 경로는 패키지 설치용 미러였다.
6. 에이전트의 명령·설치·네트워크 요청을 세션 단위로 되짚을 수 있는가
기록이 없으면 연구진처럼 동기와 결과를 답할 수 없다.
우리 AI 에이전트가 무엇을 실행하고 어디로 보내는지 확인하기
보안 전문 기업 SENTRIX의 AI 심화 취약점 진단 가운데 'LLM·AI 서비스 자체의 보안 검증'은 데이터·도구·테스트 계정을 미리 협의한 범위에서 프롬프트 입력, 검색 자료의 접근 권한, AI 에이전트의 도구 실행·데이터 전달 범위를 확인한다. 자사 서비스나 사내 시스템에 붙인 에이전트가 승인 없이 패키지 설치·게시 같은 명령을 실행할 수 있는지, 어떤 데이터를 어디로 넘길 수 있는지가 여기에 들어간다. 모든 우회 탐지나 모델 안전 인증을 보장하는 서비스는 아니다. 에이전트에게 패키지 설치나 배포를 맡기고 있다면 그 권한이 어디까지 닿는지 먼저 확인하세요. LLM·AI 보안 진단 문의하기
참고 자료
- rubyhack.ai 연구진, OpenAI agents carried out an undisclosed cyber-attack on RubyGems(2026-09-11, 연구진 주장)
- RubyGems, An update on the May spam-publishing campaign on rubygems.org(2026-09-11)
- RubyGems.org Status, Temporarily disabling new user registrations(2026-05-12)
- Socket, GemStuffer 캠페인 분석(2026-05-13)
- JFrog Security Research, GemStuffer 캠페인 신규 패키지 분석·전체 목록 CSV(2026-09-15)
- RubyGems, 보안 권고: 캐시 설정 오류로 인한 레거시 API 키 노출 가능성(GHSA-9j48-x3c3-mrp2)(2026-07-22)
- GitHub rubygems.org, Require confirmed email for API access (#6486)(2026-05-11)
- GitHub rubygems.org, 일회용 메일 가입 차단 커밋(#6510)(2026-05-16, 커밋 시각)
- RubyGems Guides, API key scopes(2026-10-20 열람)
- RubyGems, 설치 전 cooldown: 새 젬은 검증될 때까지 며칠 기다리기(2026-06-03)
- RubyGems, rubygems.org 젬 보안 경고 표시(2026-10-15)
- OpenAI, OpenAI-Hugging Face Incident Technical Report(2026-08-26, PDF 생성일 기준)
- OpenAI, '위키 사건' 관련 X 게시물(2026-09-05)
- The Hacker News, OpenAI 에이전트와 RubyGems 캠페인 연관 보도(2026-09-12, 로이터 인용 2차 보도)