TECH 으로 돌아가기
TECH HACKER NEWS 오늘 8분 읽기 25 READS

OpenAI 내부 저장소까지 뚫은 libheif 취약점과 SSO 설정 오류의 교훈

OpenAI 내부 저장소까지 뚫은 libheif 취약점과 SSO 설정 오류의 교훈
SOURCE IMAGE · HACKER NEWS

보안 연구 기업 Hacktron은 2026년 7월 25일, 두 개의 취약점을 엮어 여러 OpenAI 직원의 ChatGPT 및 Codex 계정을 탈취하고 OpenAI 내부 저장소에 접근했다고 공개했다. 하나는 OpenAI가 운영하는 커뮤니티 포럼(community.openai.com)에 쓰인 이미지 처리 라이브러리 libheif의 힙 버퍼 오버플로였고, 다른 하나는 OpenAI 자체 SSO(싱글사인온) 설정 오류였다. 연구팀은 실제로 민감 정보를 열람하지 않았음을 보이기 위해, 탈취한 직원의 Codex를 통해 내부 모노레포에 무해한 풀 리퀘스트를 올리는 방식으로 침투를 증명한 뒤 테스트를 중단했다. 최초 발견부터 저장소 접근까지 걸린 시간은 72시간이 채 되지 않았고, OpenAI는 이 건에 대해 6,500달러의 버그바운티를 지급했다.

포럼 하나가 계정 전체로 번진 구조

이 사건의 핵심은 포럼 자체의 문제가 아니라 신원 연동 구조에 있다. OpenAI는 포럼에 Discourse를 사용하면서 auth.openai.com을 통한 'OpenAI로 로그인'을 허용했는데, 이 SSO 구성의 허점 때문에 포럼을 장악하면 그 흐름을 타고 ChatGPT와 Codex 계정으로 넘어갈 수 있었다. 연구팀이 강조하듯 이는 Discourse에 국한된 문제가 아니다. 같은 SSO를 쓰는 1차·3차 서비스 중 어느 하나라도 뚫리면 동일한 접근이 가능했고, 포럼은 그것을 증명하기 위한 하나의 경로였을 뿐이다. Codex와 ChatGPT에는 GitHub, Slack, 이메일 같은 다양한 커넥터가 연결될 수 있어, 이론적 피해 범위는 계정 하나를 넘어 조직 전반으로 확장됐다.

연구팀이 진입점으로 삼은 것은 Discourse의 이미지 업로드 파이프라인이었다. Discourse는 통상 FastImage로 이미지를 검사하지만 이 라이브러리가 HEIF를 지원하지 않아, HEIC·HEIF 파일은 ImageMagick의 변환 경로로 넘어가면서 그 아래의 libheif 파서가 공격자 제어 파일에 직접 노출됐다. 문제의 libheif는 상위 프로젝트에서 이미 코드가 바뀌었지만 해당 커밋이 보안 수정으로 문서화되지 않았고 CVE도 부여되지 않았다. 그 결과 Debian 12·13이 제때 백포트를 받지 못했고, Debian 12 기반이던 Discourse 도커 이미지에는 취약한 1.19.7 버전이 그대로 실렸다. Debian 13조차 당시 취약한 1.19.8을 배포하고 있었고, 보안 업데이트는 2026년 8월 8일에야 나왔다.

AI가 익스플로잇 개발을 압축하다

이번 사례에서 눈여겨볼 대목은 취약점 자체보다 그것을 실제로 작동하는 익스플로잇으로 만드는 과정이다. 연구팀은 Opus 4.8 세션에 도커 이미지를 물려 libheif 패키지를 점검시켰고, 백포트되지 않은 수정 지점에서 힙 버퍼 오버플로와 경계 밖 읽기·쓰기 원시 조작을 찾아냈다. 다만 ASLR이 켜진 실제 환경에서 안정적으로 동작하는 익스플로잇은 Opus 4.8로는 여러 세션에 걸쳐도 만들어지지 않았다. 반면 Anthropic이 Claude Opus 5를 공개한 직후 같은 문제를 던지자 몇 시간 만에 성공했다. 먼저 ARM64 맥용 익스플로잇이 3시간 만에 나왔고, 이후 Discourse가 쓰는 x86-64와 jemalloc 환경으로 포팅됐다.

원격 인스턴스에 대해서는 모델이 익스플로잇 작성을 거부해, 연구팀은 자체 Discourse 클라우드 인스턴스를 rce.ee/ctf-forum으로 프록시해 CTF 과제처럼 보이도록 위장한 뒤 자율 루프를 돌렸다. 몇 시간 뒤 에이전트는 이미지 업로드를 통한 원격 코드 실행에 성공했고, 그렇게 만들어진 스크립트로 OpenAI 인스턴스에서도 실행 권한을 얻었다. 넓게 보면 이 공격은 libheif가 얼마나 광범위하게 쓰이는지를 드러낸 'HEIF Heist' 연구의 일부다. 연구팀은 세 명이 두 달, 토큰 비용 3,000달러 미만으로 Slack·Meta·GitHub Enterprise·Ruby on Rails, 그리고 Next.js·Astro·Gatsby 같은 프레임워크까지 이 라이브러리 의존성을 추적했으며, 새 대상에 익스플로잇을 맞추는 데는 보통 하루 이틀이면 충분했다고 밝혔다.

실무자가 챙겨야 할 지점

한국의 개발·보안 담당자에게 당장 실질적인 함의는 명확하다. 사용자 업로드 이미지를 처리하고 .heic·.heif·.avif를 받아들이는 애플리케이션이라면 libheif 의존성을 점검해야 한다. Discourse를 자체 호스팅한다면 웹 인터페이스 업데이트만으로는 기반 이미지가 교체되지 않을 수 있으므로, /var/discourse에서 git pull 후 ./launcher rebuild app으로 재빌드해야 한다. Discourse는 이번 건에 대해 GHSA-vhm9-85gw-x335 권고를 발표하고 이미지 처리 샌드박싱을 방어층으로 추가했다. 더불어 이번 사건은 단일 서비스의 침해가 SSO를 매개로 조직 전체 자산으로 번질 수 있음을 보여주므로, 신원 연동 범위와 커넥터 권한을 최소화하는 설계가 중요하다.

한 가지 명확히 해둘 점은 보상의 범위다. OpenAI는 community.openai.com에 대한 Discourse 측 테스트는 자사 버그바운티 대상에서 명시적으로 제외돼 있으며, 6,500달러의 보상은 OpenAI 쪽 취약점에 대한 것이라고 선을 그었다. 또한 이 연구는 완전 자율 해킹이 아니라 숙련된 사람의 판단이 여전히 필요했다는 점, 그리고 수천 장의 이미지가 오가며 이미지 처리기가 반복적으로 다운됐음에도 이를 탐지한 곳은 Shopify뿐이었다는 관찰도 함께 기록됐다. 오랫동안 보안을 지탱하던 '복잡성에 의한 보호', 즉 공개된 버그라도 신뢰할 만한 익스플로잇으로 만드는 데는 희소한 전문성과 시간이 든다는 전제가 AI로 인해 빠르게 무너지고 있다는 것이 이 연구의 핵심 메시지다. 위협 모델은 이제 '누가 정교한 공격을 할 수 있는가'라는 낡은 가정 대신, 익스플로잇 개발이 실제로 얼마나 저렴해졌는지를 반영해 다시 짜여야 한다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://www.hacktron.ai/blog/hacking-openai
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기
처리 중...