libheif 이미지 파서 결함 연쇄로 OpenAI 직원 ChatGPT 계정까지 뚫렸다

Hacker News22일 전조회 4

보안 연구팀 Hacktron이 OpenAI의 커뮤니티 포럼(community.openai.com)에서 원격 코드 실행(RCE)을 확보한 뒤, 이를 OpenAI의 인증 인프라 설정 오류와 결합해 직원 계정을 탈취했다고 공개했다. 탈취된 ChatGPT·Codex 계정을 매개로 내부 저장소 접근까지 이어졌고, 최초 발견에서 내부 저장소 접근까지 걸린 시간은 72시간이 채 되지 않았다.

출발점은 이미지 처리 라이브러리 libheif였다. Discourse는 이미지 검사에 FastImage를 쓰는데, 이 라이브러리가 HEIF를 지원하지 않아 해당 파일을 ImageMagick의 magick 명령으로 넘겨 변환한다. 이 과정에서 공격자가 업로드한 파일이 libheif 파서에 그대로 노출된다. 연구팀은 Discourse Docker 이미지에 설치된 libheif 패키지를 점검하다 일부 보안 수정이 백포트되지 않은 사실을 확인했고, HEIC 디코딩 중 힙 버퍼 오버플로가 발생해 임의 읽기·쓰기(OOB R/W) 원시 동작으로 이어질 수 있음을 밝혀냈다.

문제의 코드는 이미 1년 전 업스트림에서 수정됐지만 보안 수정으로 문서화되지 않았고 CVE도 부여되지 않았다. 그 결과 Debian 12와 13 모두 적시에 백포트를 받지 못했다. Debian 12 기반이던 Discourse Docker 이미지에는 libheif 1.19.7이, 당시 Debian 13에는 1.19.8이 들어 있었다. Debian은 이후 2026년 8월 8일에 Debian 13용 보안 업데이트를 배포했다.

익스플로잇 개발에는 Claude 모델이 동원됐다. Opus 4.8로 ASLR을 끈 상태의 ImageMagick/libheif 코드 실행 익스플로잇을 만들었지만, ASLR이 켜진 Discourse 기본 구성에서는 여러 세션을 돌려도 성공하지 못했다. 그날 저녁 Anthropic이 Opus 5를 내놓았고, 새 세션은 3시간 만에 로컬 Mac용 ARM64 익스플로잇을 완성했다. 이어 Discourse가 쓰는 x86-64 환경과 jemalloc 구성으로 포팅하면서 7월 25일 오전 6시경 이미지 업로드를 통한 로컬 RCE를 확인했다.

연구팀은 자체 Discourse Cloud 인스턴스를 CTF 타깃처럼 보이도록 프록시한 뒤 에이전트를 자율 루프에 투입했고, 오전 10시에는 해당 인스턴스에서 RCE를 달성해 /etc/hosts를 읽어 접근을 입증했다. 같은 익스플로잇 스크립트로 OpenAI 인스턴스에서도 RCE를 얻었다. 이후 포럼 활동 중인 OpenAI 직원 계정이 상호작용 없이 탈취된다는 가설을 확인하고 곧바로 신고했으며, 내부 코드를 실제로 열람하지 않은 상태에서 영향도를 증명하기 위해 해당 직원의 Codex에 내부 모노레포 openai/openai에 PR #1186742를 열도록 지시하는 방식으로 그쳤다.

신고와 대응은 빨랐다. OpenAI에는 Bugcrowd 프로그램을 통해 보고했고 약 14시간 만에 수정 완료 회신을 받았다. Discourse에는 HackerOne으로 보고했으며 토요일 접수, 일요일 답변, 월요일 수정이라는 속도로 대응했고 이미지 처리 샌드박싱을 심층 방어로 추가했다. Discourse는 GHSA-vhm9-85gw-x335를 공개하며 패치와 재빌드 안내를 함께 내놨다. OpenAI는 6,500달러의 바운티를 지급했지만, Discourse가 호스팅하는 community.openai.com 대상 테스트는 자사 바운티 프로그램에서 명시적으로 제외돼 있었고 이 보상은 OpenAI 측 발견에 대한 것이라고 범위를 분명히 했다.

연구팀은 이번 조사를 HEIF Heist라는 이름의 장기 프로젝트로 확장해 Slack, Meta, GitHub Enterprise, Ruby on Rails는 물론 Next.js·Astro·Gatsby 같은 Node.js 프레임워크까지 libheif 의존성을 추적하고 있다. 하나의 이미지 처리 라이브러리에 예상보다 훨씬 많은 소프트웨어가 얽혀 있다는 것이 이 조사의 출발점이다.

실무에서 확인할 지점은 두 가지다. 사용자가 올린 이미지를 처리하면서 .heic/.heif/.avif를 받아들이는 애플리케이션이라면 영향을 받을 가능성이 높으므로, 사용 중인 libheif 버전과 배포판 보안 업데이트 적용 여부를 점검해야 한다. Discourse를 자체 호스팅한다면 /var/discourse에서 git pull 후 ./launcher rebuild app을 실행해야 한다. 웹 인터페이스 업데이트만으로는 기반 Docker 이미지가 교체되지 않아 취약한 libheif가 그대로 남을 수 있다. Discourse가 호스팅하는 고객은 이미 패치된 상태다.

한 가지 짚어둘 점은 이번 사례가 단일 취약점이 아니라 이미지 파서 결함과 인증 흐름 설정 오류가 결합된 연쇄라는 사실이다. 이미지 처리 경로 하나가 코드 실행으로 이어지고, 그것이 다시 SSO를 타고 다른 서비스로 번지는 구조이기 때문에, 이미지 파이프라인과 인증 설정을 별개 문제로 다루는 팀이라면 위험 노출 범위를 다시 계산해볼 필요가 있다.