이미지 업로드에서 내부 저장소까지: Hacktron의 OpenAI 연구로 본 권한 경계

Hacktron의 「Hacking OpenAI」는 이미지 처리 취약점과 OpenAI의 로그인 관련 문제를 연결해 직원의 ChatGPT·Codex 계정에 접근한 연구다. 연구진은 직원 계정의 Codex에 연결된 GitHub 권한으로 내부 저장소에 변경을 제안하는 풀 리퀘스트(PR)를 생성했다고 밝혔다.

공개 커뮤니티의 이미지 업로드 기능에서 시작된 문제가 어떻게 내부 개발 저장소까지 이어졌을까? 이미지 처리 환경에서 코드가 실행된 것과 내부 저장소에 접근한 것은 각각 다른 권한이 필요한 사건이다. 한쪽의 침해가 다른 쪽으로 이어진 이유를 따라가면, 개별 취약점의 패치와 함께 점검해야 할 부분이 보인다.

사건 분석은 공개 자료를 바탕으로 정리했다. 공격을 직접 재현하거나 비공개 감사 로그를 확인한 결과는 아니다.

이미지 처리 취약점이 출발점이었다

Discourse의 공식 보안 공지는 libheif 취약점으로 인해 이미지 업로드가 원격 코드 실행(RCE)으로 이어질 수 있었다고 명시한다. RCE는 외부에서 전달한 입력으로 서버에서 의도하지 않은 코드를 실행할 수 있는 상태를 뜻한다. 이 Discourse 공지의 심각도 평가는 CVSS 8.8, High다.

Discourse의 이미지 업로드 RCE 공지.

이미지 업로드 기능은 파일을 저장하는 데서 끝나지 않는다. 서버가 이미지를 읽고 크기나 형식을 바꾸는 과정에서 파일의 내용은 프로그램이 해석하는 입력이 된다.

공개된 설명을 바탕으로 접근 경로를 정리하면 다음과 같다.

이미지 처리 취약점
    ↓
커뮤니티 서버 환경에서 코드 실행
    ↓
커뮤니티 로그인 토큰의 과도한 권한
    ↓
ChatGPT·Codex 계정 접근
    ↓
기존 GitHub 연동을 통한 내부 저장소 접근

다만 이미지 처리 취약점의 세부 원인에는 공개 자료만으로 확정하기 어려운 부분이 있다. Discourse는 관련 취약점으로 CVE-2026-32882를 명시하지만, libheif의 해당 CVE 권고는 이미지 합성 과정에서 허용된 메모리 범위 밖을 읽는 문제와 그에 따른 충돌·정보 노출 가능성을 설명한다.

Discourse가 RCE를 공식 공지한 것은 분명하지만, 해당 CVE 설명만으로 연구진이 이용한 결함과 코드 실행까지의 경로를 확정하기는 어렵다. 두 자료의 설명 차이가 RCE 공지를 부정하는 근거가 되는 것도 아니다.

커뮤니티의 로그인 권한이 다른 서비스에서도 통했다

OpenAI는 SecurityWeek에 전달한 설명에서 커뮤니티 로그인용 토큰이 과도한 권한을 가지고 있어 연결된 ChatGPT·Codex 계정의 API 접근을 허용했다고 밝혔다. 대응으로 해당 토큰의 권한을 축소하고, 영향을 받은 토큰과 세션을 폐기했다고 설명했다.

이 문제를 이해하려면 로그인과 작업 권한을 나누어 봐야 한다. SSO는 여러 서비스에서 공통된 로그인 체계를 사용하는 방식이다. 같은 사용자임을 확인하더라도, 그 사용자가 각 서비스에서 할 수 있는 작업까지 같아야 하는 것은 아니다. 포럼 로그인에 필요한 자격 증명이 다른 제품의 API를 사용하는 권한으로 통한다면, 포럼 침해의 영향도 그만큼 커진다.

OAuth 보안 권고인 RFC 9700의 2.3절은 접근 토큰에 필요한 최소 권한만 부여하고, 사용할 수 있는 대상 서버를 제한하도록 권고한다. 요청을 받는 서버도 해당 토큰이 자신을 위한 것인지 확인해야 하며, 대상이 맞지 않으면 요청을 거부해야 한다. 허용된 자원과 행동에 대한 검증도 필요하다.

이에 따라 점검할 것은 커뮤니티용 토큰을 다른 서비스에 제시했을 때 요청이 거부되는지다. 이는 공개된 권한 문제에서 도출한 설계 점검 기준이며, OpenAI 토큰의 내부 구조나 특정 검증 코드의 결함을 확인한 것은 아니다.

서버를 분리해 운영하는 것만으로는 이 경계가 보장되지 않는다. 한쪽에서 얻은 자격 증명을 다른 쪽에서 받아들인다면, 서버 사이에 계정 권한을 통한 접근 경로가 남는다. 네트워크 구성과 함께 어떤 서비스가 어떤 자격 증명을 신뢰하는지도 살펴봐야 하는 이유다.

내부 저장소에서 확인된 접근 범위

OpenAI가 SecurityWeek에 전달한 자체 조사 결과에는 비공개 저장소의 메타데이터와 커밋에 대한 제한적인 읽기, 그리고 README 파일을 대상으로 한 PR이 포함돼 있다. 직원 Slack 메시지에 실제로 접근했는지는 연구진이 검증하지 않았다고도 설명했다.

출처: Hacktron. 연구진이 재구성한 화면.

PR은 변경 사항을 제안하고 검토하는 기능이므로, 생성에 성공했다고 병합이나 운영 환경 배포까지 가능했다고 볼 수는 없다. 다만 README 변경이라는 작은 시연에서도 의도하지 않은 사람이 직원 계정을 통해 내부 개발 자원에 작업을 요청할 수 있었다는 점은 확인된다. 시연에 사용한 변경의 크기와 계정의 전체 권한은 별개다.

AI가 기여한 작업과 사람이 맡은 작업

Hacktron은 Claude를 활용해 이미지 처리 취약점의 공격 코드를 개발했다고 설명한다. 동시에 더 넓은 연구 과정에 대해 완전 자율적인 해킹은 아니었으며, 숙련된 사람의 지도가 여전히 중요했다고 밝혔다.

AI의 기여를 평가할 때는 성공 결과와 함께 작업 조건을 봐야 한다. 연구자가 어떤 환경과 정보를 제공했는지, 실패 원인을 누가 좁혔는지, 다음 실험과 중단 시점을 누가 결정했는지에 따라 자율성의 의미가 달라진다. 같은 조건에서 반복한 결과 없이 이 사례를 모델의 보편적인 성능을 보여 주는 벤치마크로 보기는 어렵다.

패치 이후에도 점검할 권한

공개된 접근 경로를 바탕으로 보면 아래와 같은 점검이 필요하다.

먼저 실제 운영 중인 이미지 처리 환경에 수정 사항이 반영됐는지 확인해야 한다. Discourse는 수정된 libheif가 포함된 Docker 이미지로 재빌드하도록 안내했다. 애플리케이션 코드가 최신인지와 운영 컨테이너의 라이브러리에 보안 수정이 포함돼 있는지는 따로 확인할 사항이다.

Discourse는 지원되는 환경에서 이미지 처리 작업을 격리하는 샌드박싱도 추가했다. 이런 격리는 이미지 처리 코드에 다시 문제가 생겼을 때 주변 자원으로 접근할 수 있는 범위를 줄이기 위한 장치다. 패치 적용과 함께 실제 배포 환경에서 격리가 동작하는지도 확인할 필요가 있다.

로그인 토큰은 앞서 살펴본 RFC 9700의 권고가 실제 서비스에서 지켜지는지, 다른 대상의 토큰이나 허용되지 않은 작업이 거부되는지 확인해야 한다.

AI 계정에 연결된 도구도 작업별로 권한을 살펴볼 필요가 있다. 저장소 읽기, 변경 제안, 병합, 운영 환경 배포는 서로 다른 영향을 주는 작업이다. 필요한 저장소와 행동만 허용하고, 영향이 큰 작업에는 별도의 권한 조건을 둘 수 있다.

모든 요청에 확인창을 띄울 필요는 없다. 자동으로 진행할 작업과 더 좁은 권한이나 추가 확인이 필요한 작업을 정하고, 실행 시스템이 그 구분을 강제할 수 있어야 한다.

부록. 내가 연결해 둔 GitHub 권한도 확인해 봤다

나도 에이전트에 GitHub를 연결해 사용하고 있어, 이번 글을 정리하면서 Codex와 함께 개인 계정의 앱 설치 화면과 블로그 저장소의 보호 설정, 원격 배포 워크플로를 확인했다.

점검 항목	확인한 설정
연결된 저장소 범위	`All repositories`. 개인 계정이 소유한 현재·향후 모든 저장소가 대상이었다.
앱에 부여된 권한	코드, PR, 이슈, Actions, 워크플로에 읽기·쓰기 권한이 있었다.
블로그 저장소의 보호 규칙	Classic branch protection과 Ruleset이 모두 설정돼 있지 않았다.
배포 조건	원격 워크플로는 `main`에 푸시되면 검증을 거쳐 배포하도록 구성돼 있었다.