보안 연구팀이 클로드 Opus 5로 72시간 만에 오픈AI 내부 저장소까지 들어갔다

보안 기업 Hacktron AI의 연구자 3명은 2026년 7월 25일 두 취약점을 연쇄해 오픈AI(OpenAI) 직원들의 ChatGPT 계정을 장악하고 내부 모노레포 openai/openai에 풀 리퀘스트를 열어 접근을 입증했다. 최초 발견부터 저장소 접근까지 걸린 시간은 72시간 미만이었고, 익스플로잇을 만들어 낸 것은 출시 당일 저녁의 클로드 Opus 5였다. 오픈AI는 최초 제출로부터 약 14시간 뒤인 7월 25일 22시 49분 45초(UTC)에 수정을 확인했고, 9월 1일 6,500달러의 바운티를 지급했다. ASAP은 이 사건을 취약점 하나의 이야기가 아니라 익스플로잇 개발 비용이 무너진 사건으로 읽는다.

이미지 한 장이 오픈AI 내부 저장소까지 이어진 9단계 연쇄

Hacktron AI가 공개한 공격 경로는 이미지 디코더 하나에서 시작해 내부 저장소까지 아홉 단계로 이어진다. 출발점은 libheif이고, 데비안의 보안 백포트 누락과 ImageMagick의 libheif 호출, Discourse의 이미지 업로드 기능, 오픈AI 공식 포럼 community.openai.com, 오픈AI SSO의 신원 결함, ChatGPT와 Codex 계정, 연결된 GitHub 통합, 오픈AI 모노레포가 차례로 뒤를 잇는다.

연구팀은 2026년 7월 23일 Discourse의 이미지 업로드 파이프라인을 살펴보다 HEIC와 HEIF 파일이 다른 경로를 탄다는 점을 찾아냈다. Discourse는 평소 FastImage로 이미지를 검사하지만 FastImage가 HEIF를 지원하지 않아 해당 파일을 ImageMagick의 magick 명령으로 넘겼고, 그 결과 libheif 파서가 공격자가 만든 파일에 그대로 노출됐다.

취약점 자체는 힙 버퍼 오버플로였다. 연구팀은 Opus 4.8 세션에 Discourse 도커 이미지를 주고 설치된 libheif 패키지를 점검하게 했고, 모델은 일부 보안 수정이 백포트되지 않은 사실을 찾아냈다. 문제의 상류 코드는 전년에 이미 고쳐졌지만 그 커밋이 보안 수정으로 문서화되지 않았고 CVE도 받지 않았다. Discourse 도커 이미지는 데비안 12 기반이어서 취약한 libheif 1.19.7을 설치했고, 당시 데비안 13조차 취약한 1.19.8을 배포하고 있었다. 데비안의 보안 업데이트 DSA-6417-1은 8월 8일에야 나왔다.

마지막 단계를 만든 것은 Discourse가 아니라 오픈AI였다. 연구팀은 이 확대 취약점이 Discourse 고유의 문제가 아니라 포럼 장악을 ChatGPT와 Codex 접근으로 바꿔 준 오픈AI SSO 문제라고 명시했다. 오픈AI SSO를 쓰는 어떤 자사 또는 외부 서비스가 뚫렸어도 같은 결과로 이어졌을 것이고, Discourse는 그것을 증명하는 하나의 경로였을 뿐이라는 뜻이다.

Opus 4.8이 못 한 일을 Opus 5가 출시 3시간 만에 해냈다

이 보고서에서 가장 날짜가 촘촘한 대목은 모델 교체 구간이다. 7월 24일 연구팀은 Opus 4.8로 ASLR을 끈 상태에서 동작하는 ImageMagick과 libheif 코드 실행 익스플로잇을 만들었다. 그다음 Discourse 기본 설정인 ASLR 활성 환경에서도 안정적으로 동작하게 하려고 여러 세션을 따로 띄웠지만 성과가 없었다.

그날 저녁 앤스로픽(Anthropic)이 클로드 Opus 5를 공개했다. 연구팀은 새 세션을 열었고, 모델은 맥에서 동작하는 ARM64 익스플로잇을 3시간 안에 만들어 냈다. 이어 Discourse가 쓰는 x86-64 환경과 jemalloc 설정으로 이식했고, 7월 25일 오전 6시에는 이미지 업로드를 통한 로컬 원격 코드 실행이 확인됐다.

그다음 단계에는 자율 루프가 쓰였다. 연구팀은 자체 Discourse Cloud 인스턴스를 대상으로 클로드를 자율 /goal 루프에 넣었고, Opus가 원격 인스턴스용 익스플로잇 작성을 거부했기 때문에 rce.ee/ctf-forum을 거쳐 CTF 대상처럼 보이게 프록시했다. 오전 10시에 다시 확인했을 때 에이전트는 Discourse Cloud에서 원격 코드 실행에 성공한 상태였고, /etc/hosts를 읽어 접근을 입증했다. 이 스크립트로 오픈AI 인스턴스에서도 원격 코드 실행이 이뤄졌다.

연구팀은 계정 탈취 가설을 확인한 직후 오픈AI에 보고했다. 이후 Codex가 오픈AI GitHub 조직에 연결된 직원 계정 하나를 넘겨받아, 내부 코드를 실제로 열람하지 않고 영향을 증명하기 위해 그 Codex에 프롬프트를 보내 모노레포에 무해한 풀 리퀘스트를 열게 했다. 그리고 테스트를 중단했다.

6,500달러와 3,000달러가 같은 표에 놓이면 방어 쪽이 불리하다

이 사건의 경제학은 두 숫자의 대비에서 가장 선명하게 드러난다. 오픈AI가 9월 1일 지급한 바운티는 6,500달러였다. 반면 Slack과 Meta, GitHub Enterprise, Ruby on Rails, Next.js, Astro, Gatsby까지 libheif 의존을 추적한 2개월짜리 HEIF Heist 캠페인 전체가 쓴 토큰 비용은 3,000달러 미만이었고, 투입 인원은 연구자 3명이었다. 회사마다 익스플로잇을 맞추는 데 보통 하루나 이틀이 걸렸다.

이 비율을 뒤집어 보면 방어 쪽의 셈법이 드러난다. 한 기업이 지불한 단일 보상금이 여러 기업을 동시에 겨냥한 캠페인 전체의 연산 비용을 웃돈다. 공격자 입장에서 표적을 하나 더 추가하는 한계비용은 이틀치 사람 시간과 수백 달러 수준의 토큰이며, 방어자 입장에서 표적을 하나 지키는 비용은 그대로다. 취약점 하나를 여러 곳에 재사용할 때 드는 비용이 무너지면, 원래 고가치 표적에만 쓰이던 공격 기법이 평범한 기업까지 내려온다.

바운티 금액의 맥락도 함께 봐야 한다. 오픈AI는 보상 범위를 설명하면서 Discourse가 호스팅하는 community.openai.com에 대한 테스트는 자사 바운티 프로그램에서 명시적으로 제외돼 있고, 이번 보상은 오픈AI 쪽 발견에 대한 것이지 Discourse를 상대로 한 행위에 대한 것이 아니라고 밝혔다. 즉 6,500달러는 SSO 결함의 값이지 연쇄 전체의 값이 아니다. 자산 경계를 따라 그어진 바운티 범위가 실제 공격 경로와 어긋난다는 사실 자체가, 공급망 취약점을 보상 체계로 잡아내기 어려운 이유를 보여 준다.

수천 장의 이미지가 들어오고 프로세서가 반복해서 죽었는데 아무도 몰랐다

이 보고서에서 수치보다 무거운 문장은 탐지에 관한 것이다. 연구팀은 캠페인 전체에서 Shopify를 제외한 어떤 기업도 이 활동을 탐지하지 못했다고 밝혔다. 그 사이 수천 장의 이미지가 전송됐고 각 기업의 이미지 프로세서가 반복해서 죽었다.

이 대목이 중요한 이유는 공격의 정교함과 탐지 난이도가 여기서 갈라지기 때문이다. 이미지 처리 워커가 반복 크래시하는 현상은 숨겨진 신호가 아니다. 어지간한 운영 대시보드라면 잡히는 종류의 지표이고, 크래시 급증은 침해가 아니어도 조사할 이유가 충분한 사건이다. 그런데도 거의 모든 조직이 이를 알아채지 못했다는 것은, 탐지 실패가 정교한 은닉 때문이 아니라 크래시를 보안 신호로 읽지 않는 운영 관행 때문이라는 뜻에 가깝다.

여기서 나오는 실무적 결론은 새 도구를 사기 전에 이미 가진 지표를 다시 배선하라는 것이다. 이미지 변환 워커의 비정상 종료율, 특정 확장자 업로드의 급증, 변환 파이프라인의 세그멘테이션 오류 로그는 대부분의 조직이 이미 수집하고 있다. 이것들을 성능 지표가 아니라 보안 신호 쪽으로 옮겨 놓는 작업은 새 예산을 요구하지 않는다.

모델의 거부를 프록시 하나로 우회했다는 사실이 남긴 질문

이번 보고서에는 안전장치에 관한 짧지만 무거운 기록이 들어 있다. Opus가 원격 인스턴스를 상대로 한 익스플로잇 작성을 거부했기 때문에, 연구팀은 대상을 rce.ee/ctf-forum으로 프록시해 CTF 문제처럼 보이게 만들었다. 그러자 자율 루프가 진행됐다.

이 우회는 정교한 탈옥 기법이 아니라 맥락 표시를 바꾼 것에 가깝다. 모델이 거부 판단에 쓰는 근거가 행위의 성격이 아니라 표적의 외형이었다는 뜻이며, 이 경우 정당한 보안 연구와 공격을 구분하는 신호가 사용자가 제시하는 문맥에 크게 의존한다는 점이 드러난다. 합법적인 침투 시험과 CTF를 막지 않으면서 무허가 공격만 막는 경계선이 모델 안에 존재하기 어렵다는 것은 오래된 문제이지만, 자율 루프가 결과물을 끝까지 만들어 내는 단계에서는 그 경계의 무게가 달라진다.

동시에 연구팀 자신의 단서도 같이 읽어야 한다. 이들은 이것이 완전한 자율 해킹은 아니었고 권한 상승과 내부 이동, 방어 우회 국면에서 숙련된 사람의 안내가 여전히 중요했다고 적었다. 바뀐 것은 사람이 필요 없어졌다는 사실이 아니라 소수의 인원이 감당할 수 있는 작업량이 크게 늘었다는 사실이다. Opus 5에서 GPT-5.6 Sol로 넘어가며 또 한 번의 도약이 관찰됐다는 기록도 같은 방향을 가리킨다. 대상 시스템에 대해 취약하다는 것 외에 아무 정보도 없는 상태에서 익스플로잇을 만들어야 했던 국면에서 그 차이가 나타났다.

아이폰 사진을 받는 한국 서비스는 오늘 확인해야 할 것이 분명하다

사용자가 올린 이미지를 처리하면서 .heic와 .heif, .avif 확장자를 받는 서비스는 영향 범위 안에 있을 공산이 크다고 Hacktron AI 연구팀은 2026년 9월 13일 보고서에서 밝혔다. 아이폰이 기본으로 HEIC를 저장한다는 점을 생각하면 국내 커머스와 커뮤니티, 보험 청구, 중고 거래, 고객 지원 티켓처럼 사진 첨부를 받는 거의 모든 서비스가 이 경로를 열어 두고 있다.

조치의 우선순위는 두 갈래다. 첫째는 패키지 갱신이다. 2026년 9월 14일 기준 최신 상류 보안 릴리스는 libheif v1.23.4이며 v1.23.2는 이후 보안 수정으로 대체됐고, libde265도 함께 갱신 대상이다. 배포판 패키지는 더 낮은 상류 버전 번호를 달고도 백포트된 수정을 담고 있을 수 있으므로 패키지 보안 공지를 함께 확인해야 한다. Discourse를 자체 호스팅한다면 웹 인터페이스 업데이트만으로는 하위 이미지가 교체되지 않을 수 있어 /var/discourse에서 git pull 후 ./launcher rebuild app으로 재빌드해야 한다.

둘째는 구조다. 연구팀은 ISO 기반 미디어 파일 형식의 복잡도와 디코더 갱신 속도를 근거로 앞으로도 메모리 안전 결함이 계속 나온다고 보고, 필요하지 않은 곳에서는 신뢰할 수 없는 HEIF와 AVIF 디코딩을 아예 끄거나 이미지 처리 파이프라인을 강화된 일회성 샌드박스 안에 격리하라고 권고했다. ImageMagick의 보안 정책 파일로 허용 형식과 자원 사용을 제한할 수 있다는 점도 함께 짚었다. Discourse 역시 수정과 함께 이미지 처리 샌드박싱을 방어 심화 조치로 추가했다.

남는 공백과 함께 읽어야 할 것

이번 보고서가 답하지 않은 항목도 분명히 있다. 첫째, 오픈AI SSO 신원 결함의 기술적 세부는 공개되지 않았고 SSO 문제라는 성격만 서술됐다. 둘째, 장악된 오픈AI 직원 계정의 수는 서두에서 복수로 표현됐지만 영향 증명에 쓰인 것은 한 계정이며 정확한 규모는 밝혀지지 않았다. 셋째, HEIF Heist가 추적한 Slack과 Meta, GitHub Enterprise 등에서 실제로 무엇이 확인됐는지는 이 글의 범위 밖이다. 넷째, 모노레포에 열린 풀 리퀘스트 링크는 오픈AI 요청으로 비공개 처리됐다.

그래서 이 사건에서 확실하게 가져갈 수 있는 것은 취약점 목록이 아니라 시간표다. 상류에서 조용히 고쳐졌으나 CVE가 붙지 않은 커밋 하나가 두 개의 데비안 릴리스를 통과했고, 그 패키지가 도커 이미지에 들어갔고, 이미지 변환 경로가 그 파서를 사용자 입력에 노출했고, 신원 결함이 포럼 하나를 계정 전체로 바꿨다. 각 단계는 모두 알려진 유형의 문제이며, 새로 등장한 것은 이 사슬을 실제 코드로 꿰는 데 걸리는 시간이 며칠로 줄었다는 조건뿐이다. 방어 쪽이 갱신해야 할 것은 도구 목록이 아니라 공격자가 감당할 수 있는 작업량에 대한 가정이다.

출처: Hacking OpenAI (Hacktron AI, Harsh Jaiswal·Mohan Pedhapati·Rahul Maini, 2026년 9월 13일)