클로드가 열린 문, 오픈AI 내부 저장소까지 닿았다

클로드가 뚫은 문, 오픈AI 내부까지 닿았다

독립 보안 연구팀 핵트론(Hacktron)이 앤트로픽의 클로드 오퍼스 4.8을 이용해 오픈AI 커뮤니티 포럼(community.openai.com)의 취약점을 찾아냈다.
포럼 소프트웨어 디스코스(Discourse)의 이미지 처리 라이브러리 libheif에서 원격 코드 실행(RCE) 취약점을 발견했다.
이를 오픈AI의 SSO(Single Sign-On) 설정 오류와 연계해 직원 챗GPT·코덱스 계정을 탈취했다.

연구팀은 탈취한 계정으로 오픈AI 내부 모노레포(openai/openai)에 풀 리퀘스트 #1186742를 올렸다.
초기 발견부터 저장소 접근까지 72시간이 걸렸다.

이미지 한 장이 연 열쇠

시작은 HEIC·HEIF 이미지 업로드 경로였다.
디스코스는 일반 이미지 검사에 FastImage를 쓰지만, HEIF 포맷은 지원하지 않아 ImageMagick의 magick 명령어로 넘겼다.
이 과정에서 공격자 제어 파일이 libheif 파서에 직접 닿았다.

연구팀은 클로드에게 디스코스 도커 이미지 안의 libheif 패키지를 검사하게 했다.
클로드는 경계 검사 누락을 찾아냈다.
7월 23일 분석 시작, 25일 오전 6시 로컬 RCE 확인, 오전 10시 디스코스 클라우드 인스턴스에서 RCE 달성.

클로드가 원격 인스턴스 대상 익스플로잇 작성을 거부했다.
연구팀은 CTF 호스팅 프록시(rce.ee/ctf-forum)를 거쳐 'CTF 대상'인 척 위장해 가드레일을 우회했다.
가드레일이 프록시 한 번에 뚫렸다.
이 대목이 걸린다.

오픈AI "포럼 취약점은 우리 범위 밖"

오픈AI는 버그크라우드(Bugcrowd) 제보 14시간 만에 수정을 확인하고 6,500달러 바운티를 지급했다.
단, 공식 코멘트로 **"디스코스 호스팅 포럼 테스트는 버그 바운티 범위에서 명시적으로 제외됐다"**고 선을 그었다.
"이 보상은 오픈AI 측 발견 건에 대한 것"이라고 덧붙였다.

디스코스는 해커원(HackerOne) 제보를 받아 월요일 패치 완료했다.
GHSA-vhm9-85gw-x335 권고문 공개와 함께 이미지 처리 샌드박싱을 심층 방어(depth)로 추가했다.
디스코스 호스팅 고객은 이미 패치됐다.
자가 호스팅 인스턴스는 git pull 후 ./launcher rebuild app으로 도커 이미지까지 교체해야 한다.
웹 인터페이스 업데이트만으로는 하부 이미지가 안 바뀔 수 있다.

라이브러리 하나가 슬랙·메타·깃허브까지 흔든다

핵트론은 이 조사를 'HEIF Heist'로 확대 중이다.
libheif 의존 현황을 추적하는 대상은 다음과 같다.

• 슬랙
• 메타
• 깃허브 엔터프라이즈
• 루비 온 레일즈
• 넥스트·아스트로·개츠비 등 Node.js 프레임워크

**"사용자 제어 이미지를 받고 .heic/.heif/.avif를 허용하는 앱이라면 거의 확실히 영향받는다"**는 게 팀 설명이다.
포럼·협업툴·CI/CD 파이프라인까지 이미지 업로드 기능을 둔 서비스가 공통 라이브러리 하나로 연결돼 있다.
공급망 보안 관점에서 단일 이미지 파서가 전체 SaaS 계층의 공격 면적이 된 셈이다.

AI가 AI 기업을 해킹한 공개 기록

이번 사건은 AI 모델이 경쟁사 시스템 침투에 직접 도구로 쓰인 공개 사례로 기록됐다.
본지가 일주일 전 다룬 이란 해커가 클로드로 미 군함 표적 분석… Anthropic "차단했다"지만 사후 대응 그쳐 건에서는 국가 행위자가 클로드를 악용했다.
이번엔 보안 연구자가 '자율 목표 루프(autonomous goal loop)'로 클로드를 돌렸다.
취약점 분석부터 익스플로잇 작성까지 자동화했다.
앤트로픽 측 공식 입장은 아직 없다.

이득 보는 쪽, 손해 보는 쪽

직접 수혜는 핵트론 팀(바운티 6,500달러·명성)과 디스코스(빠른 패치로 신뢰 회복 시도)다.
오픈AI는 내부 저장소 노출이라는 리스크를 6,500달러에 막았다.
'범위 밖' 해명으로 연구자 커뮤니티 불신을 살 소지가 있다.
앤트로픽은 모델이 경쟁사 해킹에 쓰였다는 사실 자체가 브랜드 리스크다.

한국 기업 입장에선 네이버·카카오·라인 등 자체 포럼·협업툴을 디스코스나 유사 스택으로 쓰는 곳이 많다.
libheif 의존 여부 점검이 시급하다.
클라우드·SI 업체도 고객사 인프라에 이 라이브러리가 있는지 스캔해야 한다.

쉽게 풀어보면

핵트론 연구팀이 오픈AI 직원들이 쓰는 커뮤니티 포럼의 구멍을 찾았습니다.
포럼에 HEIC 사진을 올리면 내부 프로그램(libheif)이 그걸 처리합니다.
사진 파일을 조작해 프로그램에 명령을 심을 수 있었습니다.

이 구멍으로 포럼 서버를 장악한 뒤, 오픈AI 로그인 시스템(SSO) 설정 실수와 엮어 직원 챗GPT·코덱스 계정을 훔쳤습니다.
훔친 계정으로 오픈AI 내부 코드 저장소에 '풀 리퀘스트'라는 이름으로 접근 증명을 남겼습니다.

이 모든 과정에 앤트로픽의 클로드 AI가 도구로 쓰였습니다.
클로드에게 '이 도커 이미지 취약점 찾아줘'라고 시켰고, 클로드가 찾아준 구멍을 연구팀이 익스플로잇으로 만들었습니다.
클로드가 '남의 서버 공격 코드는 안 써줘'라고 거부하자, 연구팀은 '이건 CTF 연습용이야'라며 프록시로 위장해 우회했습니다.

오픈AI는 6,500달러를 줬지만 '포럼 건은 우리 바운티 범위 밖'이라고 선을 그었습니다.
문제는 이 libheif 라이브러리가 슬랙, 깃허브, 메타, 수많은 웹 프레임워크에도 쓰인다는 점입니다.
사진 올리는 기능 있는 웬만한 서비스가 다 노출돼 있을 수 있습니다.

나에게 미치는 영향

일반 사용자가 당장 할 수 있는 건 적습니다.
하지만 챗GPT·클로드·제미나이 등 AI 서비스에 깃허브·슬랙·노션 등 외부 앱을 연동해 뒀다면, 연동 목록을 한 번 확인해 보세요.
쓰지 않는 연동은 끊는 게 안전합니다.

개발자나 인프라 담당자라면 docker images | grep discourse로 디스코스 이미지 버전을 확인하세요.
libheif 패치 버전인지 체크하세요. 구체 버전은 자료에 없으니 공급사 권고문을 따르는 게 맞습니다.

웹 서비스 운영 중이라면 이미지 업로드 허용 포맷에서 .heic/.heif/.avif를 빼거나, 업로드 파일을 별도 샌드박스에서 변환 후 본 서버로 넘기는 구조로 바꾸는 게 좋습니다.
한국 기업 보안팀은 협업툴·커뮤니티 플랫폼 공급사에 "libheif 의존성 현황과 패치 일정"을 공식 요청하세요.