AI 뉴스 · 계정 보안
클로드를 활용한 OpenAI 침투 연구, 핵심은 연결된 권한
Hacktron이 OpenAI 직원 계정에서 내부 저장소로 이어지는 접근 경로를 입증한 연구를 공개했습니다. 실제 사건은 7월 25일, 원문 공개는 9월 13일입니다. OpenAI는 관련 로그인 토큰의 권한을 줄이고 영향받은 토큰과 세션을 폐기했다고 밝혔습니다.
이 글에서 다룰 내용
연구 공개와 사건 시점, SSO·연동 권한, Claude와 사람의 역할, 대응·보상 범위, 업무용 AI 점검 기준
9월에 공개된 연구, 실제 사건은 7월입니다
클로드로 OpenAI 직원 계정에 접근했다는 보안 연구가 공개됐습니다. 독립 보안 연구팀 Hacktron은 직원의 ChatGPT·Codex 계정에서 연결된 GitHub 내부 저장소까지 접근할 수 있었던 경로를 설명했습니다.
실제 사건은 2026년 7월 25일입니다. 연구 원문인 ‘Hacking OpenAI’는 9월 13일 공개됐고 9월 18일 Business Insider의 후속 보도에는 OpenAI 대변인의 답변이 실렸습니다.
9월 18일 새 공격이 발생했다는 소식은 아닙니다. 연구 주체 역시 Anthropic 회사가 아니라 클로드를 도구로 활용한 Hacktron입니다.
출발점은 이미지 처리, 영향이 커진 이유는 SSO
Hacktron이 설명한 경로에는 이미지 처리 라이브러리 libheif의 메모리 취약점과 OpenAI의 SSO 구성 문제가 함께 등장합니다. SSO는 한 번의 로그인으로 여러 서비스를 사용하는 통합 인증 방식입니다.
커뮤니티 포럼의 문제는 포럼 안에서 끝나지 않았습니다. 연구진에 따르면 인증 구성 문제로 ChatGPT·Codex 계정에 접근할 수 있었고 계정에 연결된 GitHub 권한을 통해 내부 저장소까지 영향이 이어졌습니다.
SSO 자체가 위험하다는 뜻은 아닙니다. 한 서비스의 로그인 권한이 다른 서비스에서 어디까지 통하는지, 연결된 도구가 어떤 작업을 허용하는지가 중요합니다.
업무용 AI도 대화창만 살펴서는 충분하지 않습니다. 계정 뒤에 연결된 저장소와 외부 서비스의 권한까지 함께 확인해야 하는 이유입니다.
클로드가 도운 작업과 연구진이 입증한 범위
Hacktron은 Claude Opus 4.8과 이후 Claude Opus 5를 활용했다고 설명했습니다. 모델은 취약점 분석과 공격 코드 개발을 도왔지만 연구진은 완전 자율 해킹이 아니었으며 숙련된 사람의 지도가 중요했다고 명시했습니다.
비전문가 누구나 같은 결과를 낼 수 있다는 근거는 아닙니다. Anthropic이 경쟁사 공격을 수행하거나 전체 테스트를 승인했다는 의미도 아닙니다.
연구진은 직원 계정에 연결된 Codex에 내부 저장소의 무해한 변경 제안인 PR을 만들도록 해 접근을 입증했고 추가 시험을 중단했다고 밝혔습니다.
PR 생성은 코드 병합이나 실제 제품 변조와 다릅니다. PR은 코드 변경을 검토해 달라는 제안입니다. 연구진은 내부 코드 내용을 실제로 열람하지 않았다고 설명했습니다.
따라서 공개된 결과를 소스코드 대량 유출이나 모든 ChatGPT 이용자의 피해로 확대해서는 안 됩니다. 입증한 접근 권한과 실제로 수행한 작업을 나눠 봐야 합니다.
OpenAI의 대응과 6500달러 보상의 의미
Hacktron의 타임라인에 따르면 OpenAI는 최초 신고 뒤 약 14시간 만에 OpenAI 측 문제의 수정 완료를 답했습니다. Discourse도 별도로 수정하고 이미지 처리 작업의 격리를 보강했다고 합니다.
OpenAI 대변인은 Business Insider에 커뮤니티 로그인 토큰의 권한을 좁히고 영향받은 토큰과 세션을 폐기했다고 밝혔습니다. 인증 정보의 사용 범위를 줄이고 관련 로그인 상태를 종료했다는 설명입니다.
현재도 동일한 경로가 열려 있다고 볼 근거는 없습니다. 다만 이번 대응이 모든 유사한 인증·연동 문제까지 해결했다는 보장은 아닙니다.
보상에도 범위 구분이 필요합니다. Hacktron은 OpenAI가 9월 1일 6500달러를 보상하고 해결 처리했다고 설명했습니다.
원문에 실린 OpenAI의 설명에 따르면 Discourse가 호스팅한 커뮤니티에 대한 테스트는 버그바운티 프로그램에서 명시적으로 제외됐습니다. 보상은 OpenAI 측 발견에 대한 것으로, 모든 테스트의 사전 승인을 뜻하지 않습니다.
업무용 AI 보안, 로그인부터 배포까지 살펴야 합니다
다음은 사건에서 도출한 일반적인 방어 권고입니다. OpenAI가 새로 발표한 보안 기능이 아니라, 업무용 AI를 운영할 때 확인할 기준입니다.
먼저 AI 서비스에 연결한 도구와 저장소 권한을 살펴보는 것이 좋습니다. 사용하지 않는 연결은 해제하고 필요한 연결도 업무에 필요한 범위만 허용해야 합니다.
연결을 처음 승인할 때뿐 아니라 담당자나 업무가 바뀔 때도 점검할 필요가 있습니다. 편의를 위해 남겨 둔 권한이 지금도 필요한지 확인하는 과정입니다.
로그인 이상 징후가 나타났을 때 누가 토큰과 세션을 폐기할지도 정해 둬야 합니다. 비밀번호 변경만으로 끝내지 않고 남아 있는 로그인 상태와 외부 연결 권한을 함께 확인하는 절차가 필요합니다.
소프트웨어 의존성은 패치 여부와 실제 적용 상태를 구분해 점검해야 합니다. 업데이트를 준비하는 데서 그치지 않고 실행환경에 수정된 구성 요소가 반영됐는지 확인하는 방식입니다.
마지막으로 AI가 만든 변경 제안과 실제 배포 사이에는 사람의 검토를 유지해야 합니다. 저장소에 제안을 올리는 권한과 제품에 변경을 반영하는 권한은 구분해서 관리할 대상입니다.
이번 AI 보안 연구의 교훈은 모델 하나보다 로그인·커넥터·저장소 권한의 연결 전체를 살펴야 한다는 데 있습니다. 보안 검증은 반드시 명시적으로 승인된 범위 안에서만 진행해야 합니다.
한 줄 요약: AI 보안은 모델뿐 아니라 로그인부터 연결 도구와 코드 배포까지 이어지는 권한을 관리하는 문제입니다.
참고 출처
연구 원문 공개일은 2026년 9월 13일이며 실제 사건은 7월 25일입니다. 연구진 설명과 9월 18일 Business Insider에 실린 OpenAI 답변을 구분해 정리했습니다.
감자나라 AI 강의보기 5,000 
