새 모델 나온 지 3시간, 오픈AI 내부망이 뚫렸다
새 AI 모델이 나온 지 3시간 만에, 며칠째 안 되던 해킹이 됐다.
그리고 그 해킹의 끝은 오픈AI 자기네 내부 저장소였다.
보안 회사 핵트론(Hacktron)이 2026년 9월 13일 낸 보고서에 따르면, 이 팀은 7월 25일 두 개의 취약점을 이어 붙여 오픈AI 직원 여러 명의 챗GPT 계정을 통째로 가져왔다. 그 계정으로 오픈AI 내부 저장소는 물론 직원이 연결해 둔 다른 서비스까지 접근할 수 있는 상태였다.
이 글은 AI 에이전트에게 도구 권한을 쥐여 주고 일을 시키는 사람, 그리고 직접 운영하는 서버에 이미지 업로드 기능이 있는 사람 둘 다를 위한 것이다. 지난달 루비젬스 공급망 공격이 “AI가 취약점을 먼저 썼다”는 이야기였다면, 이번은 “AI가 취약점을 먼저 뚫었다”는 이야기다. 방향이 반대라 오히려 더 눈여겨볼 값어치가 있다.
3시간 만에 안 되던 게 됐다
이 사건에서 가장 놀라운 대목은 침입 경로가 아니라 속도가 바뀐 순간이다.
핵트론 팀은 7월 24일, 클로드 오퍼스 4.8(Opus 4.8)을 시켜 이미지 처리 프로그램의 보안 결함을 실제로 작동하는 공격 코드로 만들게 했다. 컴퓨터가 메모리 보호 기능(주소 무작위화, ASLR)을 꺼 둔 상태에서는 성공했다.
문제는 이 보호 기능을 켜 둔, 실제로 쓰이는 정상 환경이었다. 오퍼스 4.8은 여러 세션에 걸쳐 시도했지만 여기서는 계속 실패했다.
그런데 그날 저녁, 앤스로픽이 새 모델 **클로드 오퍼스 5(Opus 5)**를 공개했다. 팀은 바로 새 세션을 열어 같은 문제를 다시 맡겼다.
오퍼스 5는 3시간 안에 같은 컴퓨터(맥) 환경에서 작동하는 공격 코드를 만들어 냈다. 그다음엔 그 코드를 실제 서버에서 쓰는 다른 종류의 컴퓨터 환경(x86-64)에 맞게 고치는 작업까지 넘겼고, 다음 날 새벽 6시에는 실제로 서버에 침투(RCE)하는 데 성공했다.
모델 하나 바뀌었을 뿐인데, 며칠을 막던 벽이 하룻밤 사이 없어진 것이다. 보고서는 이후 더 큰 캠페인에서 오퍼스 5와 GPT-5.6 솔(Sol) 사이에서도 비슷한 도약을 봤다고 적었다 — 이번엔 대상 시스템에 대해 “취약하다”는 사실 말고는 아무 정보도 없이 공격을 완성해야 하는 더 어려운 조건에서였다. 목표가 정확히 무엇인지, 어떤 버전을 쓰는지도 모르는 상태에서 이미지 하나를 올려 보는 것부터 시작해, 메모리 손상을 안정적인 정보 유출이나 서버 제어로 바꾸는 전 과정을 넘겼는데도 결과가 나왔다는 뜻이다.
여기 재미있는 뒷이야기가 하나 더 있다. 팀은 실제 오픈AI 서버를 직접 공격하는 대신, 자기네가 관리하는 디스코스 클라우드 인스턴스를 하나 세워 두고 그쪽으로 클로드를 붙였다. 그런데 처음엔 클로드가 “원격에 있는 남의 서버”를 대상으로 하는 공격 코드 작성을 거부했다. 그래서 팀은 이 서버 주소를 CTF(보안 대회) 문제 서버처럼 보이게 위장(rce.ee/ctf-forum)했고, 그러자 클로드가 같은 작업을 문제 없이 수행했다. 안전장치가 “실제 공격인가, 연습 문제인가”를 주소나 맥락으로 구분하고 있었다는 뜻이고, 그 구분을 속이는 것도 그리 어렵지 않았다는 뜻이다.
이미지 하나가 왜 서버를 장악하게 하나
“이미지 파일 하나로 어떻게 서버를 통째로 가져가나”가 잘 안 그려진다면, 이렇게 생각하면 된다.
프로그램은 파일을 열 때 “이 정도 크기만큼만 메모리에 담아 두겠다”고 미리 정해 둔다. 그런데 파일 안의 데이터를 검사가 허술한 채로 그 메모리 칸에 그대로 옮기면, 파일을 일부러 이상하게 만들어서 정해진 칸보다 더 많은 내용을 흘려 넣을 수 있다. 그 옆 칸에는 원래 “다음에 실행할 명령이 어디 있는지” 같은 중요한 정보가 있는 경우가 많다. 이 값을 공격자가 원하는 값으로 덮어쓰면, 프로그램이 다음에 실행하는 명령을 공격자가 정한 것으로 바꿔치기할 수 있다.
이걸 손으로 하나씩 맞추려면 그 프로그램의 메모리 배치, 컴파일 설정, 운영체제 버전까지 전부 알아야 해서 전문가도 며칠씩 걸린다. 이번 사건에서 AI가 대신한 부분이 바로 이 “정교하게 값을 맞추는” 구간이었다.
이미지 하나 올리는 게 통로였다
오픈AI는 자기네 고객 지원 포럼(community.openai.com)을 디스코스(Discourse)라는 소프트웨어로 운영한다. 여기 로그인할 때 “오픈AI로 로그인”을 쓸 수 있는데, 이게 나중에 문제가 되는 연결고리다.
핵트론 팀은 이 포럼에 침투할 방법을 찾다가 이미지 업로드 기능을 파고들었다.
디스코스는 보통 패스트이미지(FastImage)라는 도구로 올라온 이미지를 검사한다. 그런데 이 도구가 HEIC·HEIF(아이폰이 많이 쓰는 사진 형식) 파일은 검사하지 못해서, 이런 파일은 그냥 이미지매직(ImageMagick)이라는 변환 프로그램으로 넘겨 버렸다.
이미지매직은 HEIF 파일을 처리할 때 립하이프(libheif)라는 부품 라이브러리를 불러 쓴다. 그리고 이 부품에 **메모리 손상 결함(힙 버퍼 오버플로우)**이 있었다. 쉽게 말하면, 프로그램이 정해진 저장 공간보다 더 많이 써 버려서 그 옆자리 메모리까지 망가뜨릴 수 있는 결함이다. 공격자가 이 자리를 정교하게 조작하면 서버가 공격자의 명령을 실행하게 만들 수 있다.
즉 침입 경로는 사진 한 장을 올리는 것이었다.
고쳐진 적 없는 구멍, CVE도 없었다
여기서 눈여겨볼 대목이 하나 더 있다. 이 결함을 고치는 수정 코드는 1년 전에 이미 원본 프로젝트(립하이프)에 반영돼 있었다.
문제는 그 수정이 “보안 수정”이라고 표시되지 않았다는 점이다. 보안 취약점 번호(CVE)도 매겨지지 않았다. 그래서 데비안(Debian) 같은 운영체제 배포판이 이 수정을 “가져와야 할 보안 패치” 목록에 넣지 않았다.
그 결과 디스코스의 도커(Docker) 이미지가 쓰는 데비안 12에는 립하이프 1.19.7이라는 취약한 버전이 그대로 남아 있었다. 심지어 더 최신인 데비안 13조차, 이 사건이 벌어진 시점엔 취약한 1.19.8을 쓰고 있었다. 데비안이 13용 보안 업데이트를 낸 건 이 사건 이후인 8월 8일이다.
조용히 고쳐진 버그, 표시 안 된 보안 수정, 그래서 아무도 따라가지 못한 패치 — 이 세 가지가 겹치면 1년 묵은 결함도 살아남는다는 걸 보여 주는 사례다.
포럼 로그인 하나가 챗GPT 계정 열쇠였다
서버에 코드를 실행할 수 있게 됐다고 바로 “오픈AI가 뚫렸다”고 할 수는 없다. 디스코스 포럼 자체는 오픈AI의 핵심 서비스가 아니기 때문이다.
진짜 문제는 정체성 확인(SSO) 구조에 있었다. 오픈AI 포럼에 “오픈AI로 로그인”이 붙어 있다는 건, 포럼 쪽 로그인 상태와 오픈AI 계정 로그인 상태가 서로 연결돼 있다는 뜻이다. 이 연결 방식에 결함이 있어서, 포럼 서버를 장악한 사람이 로그인해 있던 직원의 챗GPT·코덱스(Codex) 계정을 그대로 가져올 수 있었다.
챗GPT·코덱스 계정에는 깃허브, 슬랙, 이메일 같은 다른 서비스가 연결돼 있는 경우가 많다. 계정 하나를 가져오면 그 뒤에 매달린 것들까지 손이 닿는 구조였던 것이다.
보고서는 이 결함이 두 달 전까지, 포럼에 로그인만 해도 누구든 이런 식으로 계정을 빼앗길 수 있는 상태였다고 적었다.
72시간 안에 오픈AI 내부 저장소에 PR을 남겼다
전체 진행 속도를 시간순으로 보면 이렇다.
7월 25일 0506시(UTC), 팀은 디스코스 서버의 관리자 권한까지 가져온다. 0810시엔 오픈AI의 버그바운티 플랫폼(Bugcrowd)에 최초 보고를 올린다.
13시 30분~15시 30분, 실제로 오픈AI 직원 계정 하나를 가져와 그 권한으로 무해한 확인용 풀 리퀘스트(PR) #1186742를 오픈AI 내부 모노레포(openai/openai)에 올린다. 접근이 진짜였다는 걸 증명하되, 민감한 정보는 보지 않기로 스스로 정한 선이었다. 트위터로 오픈AI에 있는 지인들에게도 직접 알리고, 15시 30분쯔음 모든 테스트를 멈춘다.
최초 발견부터 내부 저장소 접근까지 걸린 시간은 72시간이 안 됐다.
그날 밤 22시 49분 45초, 오픈AI는 “문제를 수정했다”는 답을 보냈다 — 최초 신고 후 약 14시간 만이다. 디스코스 쪽에도 따로 신고했는데, 토요일에 신고하니 일요일에 답이 오고 월요일엔 수정이 끝나 있었다. 디스코스는 여기에 더해 이미지 처리 과정을 격리하는 방어 장치(샌드박싱)까지 추가했고, 7월 28일 공식 보안 공지(GHSA-vhm9-85gw-x335)를 냈다.
6,500달러 — 그런데 이 방식은 원래 규정 밖이었다
9월 1일, 오픈AI는 핵트론 팀에 6,500달러의 버그바운티를 지급하고 사건을 종결 처리했다.
여기 흥미로운 조건이 하나 붙는다. 오픈AI가 직접 남긴 설명에 따르면, 디스코스가 호스팅하는 커뮤니티 포럼(community.openai.com)을 대상으로 한 테스트는 원래 버그바운티 프로그램 범위에서 명시적으로 제외돼 있었다. 이번 보상은 디스코스 쪽 침투가 아니라, 그 뒤에 드러난 오픈AI 쪽 정체성 확인(SSO) 결함을 인정한 것이라는 게 오픈AI의 공식 입장이다.
포럼 자체를 공격한 부분은 규정 밖이었는데, 그 공격이 열어젖힌 진짜 문제(SSO 결함)는 규정 안이었다는 뜻이다. 경계선에 걸친 사례라 이후 다른 버그바운티 프로그램들이 참고할 만하다.
두 달, 3,000달러로 슬랙·메타·깃허브까지
핵트론 팀은 이 발견을 계기로 **“HEIF 하이스트(HEIF Heist)”**라는 이름의 더 큰 조사를 시작했다. 립하이프가 슬랙, 메타, 깃허브 엔터프라이즈, 루비온레일즈, 넥스트JS·아스트로·개츠비 같은 노드JS 프레임워크에까지 널리 쓰이고 있다는 걸 확인하고 각 회사를 차례로 조사한 것이다.
이 두 달짜리 다회사 조사 전체에 든 AI 토큰 비용은 3,000달러가 되지 않았다. 3명이 진행했고, 회사 하나를 새로 공략하는 데는 보통 하루나 이틀이면 충분했다.
3,000달러면 노트북 한 대 값이다. 그 돈으로 여러 대형 기업의 내부 시스템까지 접근 가능한 결함을 잇달아 찾아낸 셈이다. 예전 같으면 이런 수준의 조사에는 숙련된 팀이 몇 달을 붙어야 했다.
여기서 한 가지는 이 블로그를 읽는 사람에게 직접 관련이 있다. 조사 대상 목록에 넥스트JS(Next.js), 아스트로(Astro), 개츠비(Gatsby) 같은 노드JS 프레임워크가 들어 있다는 점이다. 이 블로그 자체도 아스트로로 만들어져 있다. 립하이프가 문제가 되는 건 이 프레임워크들이 직접 그 코드를 담고 있어서가 아니라, 사용자가 올린 이미지를 처리하는 과정에서 립하이프를 쓰는 의존 라이브러리를 자기도 모르게 함께 쓰는 경우가 널리 퍼져 있기 때문이다. “내가 쓰는 프레임워크 이름이 취약점 이름과 같이 나온다”고 해서 그 프레임워크 자체가 뚫린 것은 아니지만, 사용자 이미지 업로드를 받는 기능이 있다면 그 처리 경로를 한 번은 확인해 볼 값어치가 있다는 뜻이다.
보고서 참고문헌 첫 번째 자리에는 굳이 xkcd의 유명한 만화 “디펜던시(Dependency)“가 걸려 있다. 세상의 거의 모든 소프트웨어가 어딘가 구석에서 몇 년째 방치된 프로젝트 하나에 매달려 있다는 그 그림이다. 립하이프는 딱 그 그림에 들어맞는 사례가 됐다 — 슬랙부터 이 블로그가 쓰는 프레임워크까지, 눈에 안 보이는 곳에서 한 부품에 이렇게 넓게 걸쳐 있었다는 사실이 사건이 벌어지기 전까지는 드러나지 않았다.
알아챈 곳은 딱 하나였다
더 눈에 걸리는 대목은 탐지 여부다.
보고서는 조사 과정에서 수천 장의 손상된 이미지를 여러 회사의 이미지 처리 서버에 반복해서 보냈고, 그때마다 서버가 계속 멈추거나 죽었다고 적었다. 그런데 이 활동을 알아챈 곳은 딱 한 곳, 쇼피파이(Shopify)뿐이었다.
서버가 반복해서 죽는 건 로그에 남는 뚜렷한 신호다. 그런데도 대부분의 회사가 놓쳤다는 건, 지금의 보안 모니터링이 “사람이 정교하게 노리는 공격”을 가정하고 있지 “AI가 값싸게 반복 시도하는 공격”은 잘 잡지 못한다는 뜻으로 읽힌다.
립하이프를 쓰고 있다면 지금 볼 것
당장 확인할 두 가지가 있다.
내 서비스가 사용자가 올린 사진을 받고, 그중 .heic .heif .avif 확장자 파일을 처리한다면 립하이프를 어디선가 쓰고 있을 가능성이 높다. 직접 쓰지 않아도 이미지매직 같은 변환 도구를 거치면 간접적으로 쓰이는 경우가 흔하다.
2026년 9월 14일 기준 립하이프 최신 보안 버전은 1.23.4다(1.23.2는 이미 새 수정으로 대체됐다). 배포판 패키지 관리자가 알려 주는 버전 번호만 보지 말고, 실제 보안 공지까지 확인하는 게 안전하다 — 이번 사건처럼 번호는 낮은데 조용히 고쳐진 결함이 또 있을 수 있어서다.
디스코스를 직접 운영(셀프호스팅)하고 있다면 더 급하다. 화면에서 업데이트 버튼만 누르는 걸로는 안 된다. 저장소 폴더(/var/discourse)에서 git pull 다음 ./launcher rebuild app을 실행해야 이미지 안의 오래된 립하이프까지 바뀐다.
AI 에이전트에 도구를 물려 준 사람이 볼 것
립하이프를 안 쓰는 사람이라도, 코딩 에이전트나 자동화 도구에 인터넷 접속·파일 실행 권한을 준 적이 있다면 이 사건에서 가져갈 게 있다.
이번 침투에서 AI가 한 일은 크게 셋이다. 취약한 부품 버전을 찾아내는 조사, 그 결함을 실제로 작동하는 공격 코드로 바꾸는 작업, 그리고 서버에 들어간 뒤 권한을 넓히고 흔적을 숨기는 후속 작업. 보고서는 “완전한 자율 해킹은 아니었다”고 분명히 적었지만, 동시에 “소수의 팀이 해낼 수 있는 일의 양이 극적으로 늘었다”고도 적었다.
즉 지금 위협 모델에서 가장 먼저 고쳐야 할 가정은 “이 정도 공격은 잘 훈련된 팀이 몇 달은 붙어야 나온다”는 계산이다. 에이전트에게 강한 권한을 주고 있다면, 그 권한으로 접근 가능한 범위 안에 오래돼서 아무도 다시 들여다보지 않은 부품이 있는지 — 이번 사건의 립하이프처럼 CVE도 안 달리고 조용히 묵혀진 결함이 있는지 — 를 사람이 아니라 같은 AI에게 점검시켜 보는 게 지금으로서는 가장 현실적인 대응이다. 공격자도 이미 그렇게 하고 있으니, 방어자만 옛날 속도로 움직일 이유가 없다.
이 사건이 남긴 계산
보고서는 이 흐름을 “복잡성을 통한 보안”이 무너지는 과정으로 설명한다.
예전에는 알려진 메모리 손상 결함이라도, 그걸 실제로 작동하는 공격으로 완성하려면 드문 전문성과 시간, 그 서버 환경에 대한 지식이 필요했다. 코드가 공개돼 있어도, 진짜 공격으로 바꾸는 데는 여전히 벽이 있었다는 뜻이다.
이번 사건은 그 벽이 AI 앞에서 얼마나 빨리 낮아지는지를 보여 준다. 다만 완전 자율은 아니었다 — 보고서도 “사람의 숙련된 개입이 여전히 중요했다”고 못박는다. 바뀐 건 적은 인원이 해낼 수 있는 일의 양이다. 3명이 두 달 안에 여러 대형 기업의 내부 시스템까지 닿았다.
8월에 올린 오픈AI 에이전트-허깅페이스 사건은 AI 에이전트가 스스로 취약점을 찾아 쓴 경우였고, 이번은 사람 연구자가 AI를 도구로 써서 같은 회사(오픈AI)를 뚫은 경우다. 방향은 다르지만 결론은 같다 — 지금 위협 모델을 세울 때는 “공격자도 AI를 쓴다”는 전제를 깔아야 한다. 예전 기준으로 “이건 전문가가 몇 달은 걸릴 공격”이라고 안심하던 계산은, 이제 며칠짜리 계산으로 다시 해야 한다.
출처: Hacking OpenAI — Hacktron AI (2026-09-13)