72시간 만에 뚫린 OpenAI 포럼 | 발주자가 점검할 5가지
보안 스타트업 3명이 Claude로 OpenAI 커뮤니티 포럼의 이미지 업로드 취약점을 뚫고 72시간 안에 내부 코드 저장소까지 닿았어요. 원인은 CVE 없이 고쳐져 배포판에 안 들어간 패치였어요. 우리 서비스에서 점검할 5가지를 정리했어요.
핵심 요약
- 인도의 3인 보안 스타트업 Hacktron AI가 Claude로 공격 코드를 만들어 OpenAI 커뮤니티 포럼을 뚫었어요. 포럼에서 시작해 72시간 안에 직원의 ChatGPT·Codex 계정과 내부 코드 저장소까지 닿았어요.
- 입구는 포럼의 이미지 업로드였어요. 원본 라이브러리에선 이미 고쳐졌지만 CVE(공개 취약점 번호)가 없어서 서버 배포판에 수정이 안 들어간 상태였어요.
- 버그바운티(보안 제보 보상) 안에서 한 일이라 실제 피해는 없었어요. OpenAI는 제보 약 14시간 뒤 수정을 마쳤고 6,500달러를 지급했어요.
- 직접 만들고 운영해본 개발사 기준으로, 우리 서비스에서 점검할 5가지를 정리했어요.
📰 2026년 9월 19일 기준 최신 소식 | 이 글은 특정 시점의 뉴스를 다루고 있어요.
“우리 같은 회사를 누가 굳이 공격하겠어요?”
보안 요건을 이야기하면 자주 듣는 말이에요. 이번 사건을 공개한 연구진은 바로 그 생각이 흔들리고 있다고 적었어요. 공격이 복잡하고 전문가가 드물어서 그동안 평범한 회사들이 덜 노려졌는데, AI가 그 전문성을 컴퓨팅 비용으로 바꿔 버리고 있다는 거예요.
1. 무슨 일이 있었나요
9월 18일 TechCrunch·Ars Technica 등이 보도한 내용이에요. 연구진이 직접 공개한 기록을 기준으로 흐름을 정리하면 이래요.
| 시점(7월 25일, UTC) | 일어난 일 |
|---|---|
| 05:00～06:00 | 커뮤니티 포럼(community.openai.com)에서 원격 코드 실행 확인 |
| 08:00～10:00 | Bugcrowd(보안 제보 플랫폼)로 OpenAI에 보고 |
| 13:30～15:30 | 직원 계정 장악을 시연하고, 내부 저장소에 무해한 PR(코드 변경 요청) 1건 생성 후 중단 |
| 22:49 | OpenAI가 수정 배포 확인 (보고 후 약 14시간) |
포럼 서버를 연 뒤에는 OpenAI 로그인 연동(SSO, 한 번 로그인으로 여러 서비스를 쓰는 방식)의 설정 실수를 이용해 직원 계정으로 넘어갔어요. 그 계정에 연결된 Codex가 GitHub 권한을 갖고 있었고, 그 권한으로 내부 코드 저장소까지 갔어요.
공식 외부 기준 — Hacktron AI 블로그 “Hacking OpenAI”(2026년 9월), TechCrunch(2026년 9월 18일) 보도를 기준으로 했어요. 연구진은 민감한 정보는 열람하지 않았다고 밝혔어요.
2. 입구는 왜 이미지 업로드였을까요
서버가 올라온 파일을 ‘열어 보는’ 순간이 가장 위험하기 때문이에요.
포럼은 사진이 올라오면 크기를 줄이고 형식을 바꿔요. 이 포럼(Discourse 기반)은 보통 FastImage로 먼저 검사하는데, 아이폰 사진 형식인 HEIC·HEIF는 이 도구가 지원하지 않아 검사를 건너뛰었어요. 대신 ImageMagick이 파일을 넘겨받았고, 그 안의 libheif라는 라이브러리가 공격자가 만든 이미지를 그대로 읽었어요. 거기에 메모리를 넘치게 하는 결함이 있었고요.
본서비스인 ChatGPT가 아니라 고객 지원용 포럼이 입구였다는 점이 눈여겨볼 대목이에요. 발주자 입장에선 “메인 기능”만 보안 검토 대상으로 잡기 쉬운데, 실제로는 게시판·문의 첨부·프로필 사진 같은 곁가지 기능이 같은 서버에서 같은 라이브러리를 쓰는 경우가 많아요. 파일 업로드 범위를 어떻게 잡는지는 파일 업로드 기능 견적 글에서 따로 다뤘어요.
3. 이미 고쳐진 결함인데 왜 서버에 남아 있었을까요
원본에서 고친 코드가 ‘보안 수정’으로 표시되지 않았기 때문이에요.
libheif 개발진은 해당 코드를 이미 바꿔 뒀어요. 그런데 이 변경에 보안 수정이라는 설명도, CVE 번호도 붙지 않았어요. 리눅스 배포판(Debian)은 보통 CVE가 붙은 수정만 골라 기존 버전에 옮겨 넣어요. 그래서 서버에 깔린 libheif 1.19.7 패키지엔 수정이 빠져 있었고, 연구진 보고 시점에도 Debian 13은 취약한 1.19.8을 배포하고 있었다고 해요.
이 부분이 운영하는 입장에서 가장 불편한 대목이에요. “운영체제 보안 업데이트는 자동으로 돌려요”라는 답만으로는 충분하지 않다는 뜻이거든요. 업데이트를 성실히 돌려도, 업데이트 목록에 올라오지 않은 결함은 남아요.
4. AI는 이 공격에서 무엇을 했나요
결함을 실제로 작동하는 공격 코드로 바꾸는 일을 했어요. 결함이 있다는 것과 그걸로 서버를 여는 것 사이엔 원래 꽤 긴 거리가 있어요.
연구진은 처음엔 이전 모델로 시도했다가 실패했어요. Claude Opus 5가 나온 뒤 같은 문제를 새 세션으로 맡겼더니, 3시간 만에 맥(ARM64)에서 돌아가는 공격 코드가 나왔어요. 이어서 포럼 서버 환경(x86-64·jemalloc)에 맞게 옮기게 했고, 결국 이미지 한 장을 올려 서버에서 코드를 실행하는 데 성공했어요. TechCrunch는 연구진이 쓴 도구 비용을 월 200달러로 전했어요.
여기서 과장은 피해야 해요. 대상을 고르고, 진입점을 찾고, 결과를 판정한 건 전부 사람이에요. AI가 줄인 건 “전문가 몇 명이 몇 주 걸리던 부분”이에요. 다만 그 부분이 줄면, 예전엔 공격할 가치가 없던 작은 서비스도 계산이 달라져요.
5. 우리 서비스에서 점검할 5가지
이번 사례를 우리 서비스에 옮겨 보면 확인할 것은 다섯 가지예요.
| # | 점검 항목 | 확인하는 질문 |
|---|---|---|
| 1 | 파일을 받는 모든 곳 | 게시판·문의·프로필 사진까지, 올라온 파일을 서버가 변환하는 곳이 어디인가요? |
| 2 | 라이브러리 목록 | 이미지·문서 변환에 쓰는 라이브러리 이름과 버전을 적어 둔 목록이 있나요? |
| 3 | 패치 반영 기준 | 보안 업데이트를 며칠 안에 반영하는지, CVE 없는 수정은 누가 챙기는지 정했나요? |
| 4 | 로그인 연동 범위 | 한 계정이 뚫리면 어느 시스템까지 이어지나요? |
| 5 | AI 에이전트 권한 | 코딩·업무 에이전트가 쓰기 권한을 어디까지 갖고 있나요? |
1·2번은 개발사에 요청하면 대개 하루 이틀이면 나오는 자료예요. 이 목록이 아예 없다면 그게 첫 번째 위험 신호예요. 3번은 유지보수 계약의 문제라 유지보수 계약(SLA) 범위 글을 함께 보시면 좋아요.
6. 사내 AI 에이전트 도입은 권한부터 나눠요
이번 사건에서 피해 범위를 키운 건 직원 계정에 연결된 에이전트의 권한이었어요. 사람 계정 하나가 넘어가자 그 계정이 맡겨 둔 GitHub 권한까지 같이 넘어갔어요.
AI 에이전트 도입을 검토하는 회사가 늘면서 “일단 붙여 보자”는 얘기를 많이 들어요. 순서를 바꾸는 게 맞아요. 에이전트 계정은 사람 계정과 따로 만들고, 업무마다 읽기·쓰기를 나눠서 주고, 쓰기 권한은 사람이 승인하는 단계를 둬요. 신원 보안용 에이전트 AI 같은 새 도구를 사기 전에 이 세 가지를 먼저 적어 보면 무엇이 부족한지 보여요. 권한을 나누는 기준은 AI 에이전트 계정 접근 범위 글에 정리해 뒀어요.
7. 운영까지 보면 달라지는 것
OpenAI는 보고를 받고 약 14시간 만에 수정을 배포했어요. 제보 창구가 있었고, 받은 사람이 판단할 수 있었고, 고칠 사람이 있었기에 가능한 속도예요.
저희도 자체 SaaS 4종을 운영하면서 보안 업데이트를 “시간 날 때 하는 일”로 두면 반드시 밀린다는 걸 배웠어요. 그래서 긴급 보안 건은 다른 작업보다 먼저 처리하는 등급을 따로 둬요. 외주로 만든 서비스라면 오픈 뒤 이 역할을 누가 맡는지부터 정해 두세요. 만든 회사와 운영하는 회사가 다르면, 이 공백이 가장 먼저 생겨요.
우리 서비스에서 파일을 받는 곳과 연결된 계정 범위를 한 번 펼쳐 보고 싶다면 점검 목록부터 같이 만들어 볼게요 →
저희는 10년 넘게 50개가 넘는 프로젝트를 만들어 왔고 자체 SaaS 4종을 지금도 직접 운영하고 있어요. 롯데·캐논 같은 곳의 시스템을 만든 경험도, 오픈 뒤 매일 업데이트를 챙기는 운영 경험도 함께 가진 개발사예요.
8. 자주 묻는 질문
우리 회사 서비스도 이런 방식으로 뚫릴 수 있나요?
이미지나 파일을 올려 받는 기능이 있다면 같은 구조를 갖고 있어요. 서버가 올라온 파일을 변환하는 순간 외부 라이브러리가 그 파일을 읽기 때문이에요. 어떤 라이브러리의 어떤 버전이 돌고 있는지 목록부터 확인하면 위험한 곳이 좁혀져요.
보안 패치는 유지보수 계약에 포함되나요?
계약서에 적지 않으면 포함되지 않는 경우가 많아요. 운영체제와 라이브러리 보안 업데이트를 몇 일 안에 반영할지, 긴급 건은 누가 몇 시간 안에 대응할지를 유지보수 범위에 숫자로 적어 두는 편이 안전해요.
사내 AI 에이전트를 도입하면 보안 위험이 커지나요?
에이전트에 준 권한만큼 커져요. 이번 사례에서도 직원 계정에 연결된 코딩 에이전트가 코드 저장소 권한을 갖고 있어 피해 범위가 넓어졌어요. 에이전트 계정은 사람 계정과 분리하고, 읽기와 쓰기 권한을 업무 단위로 나눠 주는 것부터 시작하세요.
9. 마무리
이번 사건에서 기억할 숫자는 두 개예요. 공격 코드를 만드는 데 걸린 3시간, 그리고 입구가 된 포럼 이미지 업로드 한 곳이요. AI는 공격하는 쪽의 시간을 줄였고, 입구는 여전히 아무도 신경 쓰지 않던 곁가지 기능이었어요.
오늘 할 수 있는 일은 하나예요. 우리 서비스에서 파일을 받는 곳을 전부 적어 보세요. 생각보다 목록이 길다면, 거기서부터 시작하면 돼요.
함께 보면 좋은 글