AI가 취약점 공격 개발 가속…오픈AI 직원 챗GPT·코덱스 계정까지 탈취

AI를 이용해 이미지 처리 라이브러리의 메모리 취약점을 실제 원격코드실행 공격으로 발전시키고, 이를 오픈AI의 인증 시스템 문제와 연계해 직원의 챗GPT와 코덱스 계정까지 탈취한 보안 연구 결과가 공개됐다.

보안업체 핵트론(Hacktron) 연구진은 앤트로픽 클로드 오퍼스 5를 활용해 오픈AI 커뮤니티 포럼에서 코드 실행 권한을 확보한 뒤 오픈AI 직원 계정과 내부 코드 저장소까지 접근 가능한 공격경로를 확인했다고 밝혔다. 연구진은 실제 악성 공격이 아닌 보안 연구 과정에서 문제를 발견해 오픈AI와 디스코스에 신고했다.

앞서 공개된 자료에서도 연구진이 두 가지 취약점을 연계해 여러 오픈AI 직원의 챗GPT와 코덱스 계정에 접근했으며, 내부 저장소 접근 가능성을 무해한 풀리퀘스트(Pull Request) 생성으로 검증한 것으로 설명됐다. 고객 데이터나 내부 소스코드는 열람하지 않았다고 연구진은 밝혔다.

시작은 커뮤니티 포럼의 이미지 업로드 기능

첫 번째 공격 지점은 오픈AI가 운영하는 커뮤니티 포럼 community.openai.com이었다.

이 포럼은 오픈소스 커뮤니티 플랫폼 디스코스를 사용한다. 이용자가 HEIC·HEIF 이미지를 업로드하면 이미지매직(ImageMagick)을 통해 변환하며, 이 과정에서 HEIF·AVIF 이미지 처리 라이브러리인 libheif가 사용된다.

핵트론은 당시 디스코스 도커 이미지에 포함된 libheif 1.19.7이 최신 보안 수정사항을 반영하지 않은 상태였다고 설명했다. 연구진은 이미지 디코딩 과정에서 발생하는 메모리 손상 문제를 이용해 공격자가 조작한 이미지를 업로드하는 것만으로 서버에서 코드를 실행할 수 있는 공격기법을 개발했다.

관련 취약점 가운데 CVE-2026-32882는 libheif의 이미지 합성 과정에서 잘못된 메모리 영역을 읽을 수 있는 힙 버퍼 범위 초과 읽기 문제다. libheif 측 권고에서는 서비스 장애나 메모리 정보 노출 가능성이 설명돼 있으며, 1.22.0에서 수정됐다.

다만 디스코스는 자체 환경에서 이 문제를 이용하면 이미지 업로드를 통해 원격코드실행으로 이어질 수 있다고 평가하고 CVSS 8.8의 고위험 취약점으로 공지했다. 수정 버전은 디스코스 2026.7.0, 2026.6.1, 2026.5.2, 2026.1.6이다.

즉 CVE 자체를 곧바로 일반적인 RCE 취약점으로 보는 것보다는, 연구진이 여러 메모리 문제와 대상 시스템 환경을 분석해 디스코스 환경에서 실제 코드 실행까지 발전시켰다는 점이 핵심이다.

서버 장악 뒤 오픈AI SSO 통해 직원 계정으로 이동

더 심각한 문제는 포럼 서버 장악 이후 나타났다.

오픈AI 커뮤니티 포럼에는 'Sign in with OpenAI' 방식의 싱글사인온(SSO)이 적용돼 있었다. 핵트론에 따르면 연구진은 포럼 시스템에 대한 통제권을 확보한 뒤 오픈AI 인증 구조의 문제를 이용해 포럼에 로그인한 오픈AI 직원의 챗GPT와 코덱스 계정에 별도의 사용자 동작 없이 접근할 수 있었다.

연구진은 이 문제를 디스코스 자체의 인증 취약점이 아니라 오픈AI 측 SSO 신뢰구조의 문제로 설명했다. 공개 서비스와 내부 중요 서비스가 동일한 인증체계를 지나치게 폭넓게 신뢰할 경우 상대적으로 보안 수준이 낮은 서비스 하나가 침해됐을 때 공격 범위가 내부 시스템까지 확대될 수 있다는 것이다.

연구진은 실제 오픈AI 직원 계정 가운데 GitHub가 코덱스에 연결된 계정을 이용해 오픈AI 내부 모노레포에 풀리퀘스트 하나를 생성했다. 내부 소스코드를 읽거나 변경사항을 병합하지 않았으며, 고객 데이터에도 접근하지 않았다고 밝혔다.

챗GPT나 코덱스에 GitHub뿐 아니라 이메일, 슬랙(Slack) 등 다른 외부 서비스가 연결돼 있었다면 이론적으로 공격 범위가 더 확대될 가능성도 있었다. 다만 연구진은 이러한 추가 접근은 시도하지 않았다고 설명했다.

클로드 오퍼스 5, 난도 높은 익스플로잇 개발에 활용

이번 연구에서 주목되는 부분은 AI가 단순 취약점 검색을 넘어 실제 공격코드 개발 과정에 깊숙이 사용됐다는 점이다.

연구진은 처음 클로드 오퍼스 4.8을 이용해 libheif 취약점 분석과 익스플로잇 개발을 시도했다. ASLR(Address Space Layout Randomization, 메모리 주소를 무작위로 배치해 공격을 어렵게 만드는 방어 기법)을 비활성화한 환경에서는 코드 실행에 성공했지만 실제 디스코스 기본 환경처럼 ASLR이 적용된 상태에서는 안정적인 공격코드를 만들지 못했다.

이후 7월 24일 클로드 오퍼스 5가 공개되자 같은 문제를 다시 테스트했다. 핵트론에 따르면 오퍼스 5는 약 3시간 만에 ARM64 환경에서 동작하는 익스플로잇을 만든 뒤 이를 디스코스가 사용하는 x86-64와 jemalloc 환경에 맞게 수정하는 작업까지 수행했다. 연구진은 다음날 이미지 업로드를 이용한 RCE를 확인했다.

AI 모델의 안전장치를 우회하기 위해 연구진은 자신들이 관리하는 테스트 서버를 CTF 연습 환경처럼 구성해 실험했다. 다만 공격 과정 전체가 AI에 의해 완전히 자동화된 것은 아니며 숙련된 보안 연구자의 지시와 검증이 계속 필요했다고 밝혔다.

발견부터 오픈AI 내부 저장소 접근 확인까지 72시간 이내

핵트론에 따르면 최초 취약점 분석부터 오픈AI 내부 저장소 접근 가능성을 확인하기까지 걸린 시간은 72시간이 채 되지 않았다.

연구진은 7월 25일 오픈AI 버그바운티 프로그램을 통해 문제를 신고했다. 오픈AI는 최초 신고 약 14시간 뒤 수정 완료를 통보했으며, 9월 1일 연구진에게 6,500달러의 버그바운티를 지급했다. 오픈AI는 해당 보상이 디스코스 취약점 자체가 아니라 오픈AI 측에서 확인된 보안 문제에 대한 것이라고 설명했다.

디스코스도 별도의 신고를 받은 뒤 패치를 배포하고 이미지매직 처리 과정을 샌드박스화하는 추가 방어조치를 적용했다. 디스코스가 직접 호스팅하는 서비스는 패치됐으며, 자체 구축형 디스코스 사용자는 최신 도커 이미지를 다시 빌드해야 한다. 단순 웹 관리화면 업데이트만으로는 오래된 시스템 라이브러리가 교체되지 않을 수 있다.

AI 시대, '취약점 발견'보다 '공격 가능 상태로 만드는 속도'가 문제

이번 사례는 생성형 AI가 사이버공격에 미치는 영향을 보여주는 사례다.

메모리 손상 취약점을 실제 공격에 사용할 수 있는 안정적인 익스플로잇으로 만드는 작업은 운영체제, 메모리 할당 구조, ASLR 등 다양한 방어기법을 이해해야 해 상당한 전문성이 필요했다.

하지만 이번 연구에서는 AI 모델이 취약점 분석과 익스플로잇 수정, 대상 환경 적응 작업을 반복하면서 소규모 연구팀의 공격 개발 시간을 크게 단축했다.

핵트론은 오픈AI뿐 아니라 슬랙, 메타, GitHub 엔터프라이즈, Next.js 등 여러 환경에서 libheif 계열 문제를 조사하는 'HEIF Heist' 프로젝트를 진행했으며, 약 두 달 동안 AI 사용 비용이 3,000달러 미만이었다고 밝혔다. 다만 다른 기업들에 대한 일부 공격 영향은 각 업체나 독립된 제3자를 통해 모두 확인된 것은 아니어서 연구진 주장과 검증된 사실을 구분해 볼 필요가 있다.

이미지 처리 라이브러리·SSO 신뢰범위 함께 점검해야

보안담당자는 HEIC·HEIF·AVIF와 같이 외부 사용자가 올린 이미지를 서버에서 처리하는 서비스가 있는지 우선 확인할 필요가 있다.

libheif는 최신 보안 버전이나 운영체제 배포판에서 제공하는 패치 버전으로 업데이트해야 한다. 불필요한 경우 HEIF·AVIF 파일 디코딩 기능을 차단하고, 이미지 변환 시스템을 별도의 제한된 샌드박스에서 실행하는 것도 필요하다.

SSO 구조도 함께 점검해야 한다. 외부에 노출된 커뮤니티나 지원 시스템과 내부 개발·업무 시스템이 동일한 인증 신뢰범위를 공유하면 주변 시스템 한 곳의 침해가 핵심 계정 탈취로 확산될 수 있기 때문이다.

특히 깃허브, 이메일, 협업도구 등을 AI 에이전트와 연결하는 기업이 증가하면서 계정 하나의 탈취가 단순 정보조회가 아니라 코드 변경과 외부 시스템 작업으로 이어질 가능성도 커지고 있다.