# ImageMagick 7의 경우
magick -list format | grep -i -E 

따라서 Debian의 보안 업데이트에는 반영되지 않아, 취약한 버전이 여전히 남아있는 상태로 Debian 12(1.19.7)와 Debian 13(1.19.8) 모두에 존재했습니다. Debian 13용 보안 업데이트(DSA-6417-1)는 이번 보고서 발표 이후인 2026년 8월 8일에 나왔습니다.

연구자들은 이 버그를 발판 삼아 Claude Opus 4.8, 그리고 중간에 등장한 Opus 5를 사용하여 Discourse 환경(x86-64, 메모리 관리에 `jemalloc`을 사용)에 맞는 공격 코드를 완성했습니다. 먼저 자체적으로 준비한 Discourse Cloud 인스턴스에서 테스트했고, 이후 OpenAI 포럼에서 원격 코드 실행(RCE)과 관리자 권한 획득에 성공했습니다.

### 우리 현장에 비유하자면

'베이스 이미지를 최신으로 하고, `apt upgrade`도 돌리고 있다.'

많은 팀에게 있어 이는 충분한 대책처럼 보입니다. 취약점 스캐너에서 CVE가 나오지 않으면 더욱 안심하게 됩니다.

하지만 이번에는 그 두 가지를 제대로 했음에도 막을 수 없었습니다. 다시 말해, 배포처의 '최신'과 상위 레벨의 '수정됨'이 같지 않았다는 것입니다.

### 확인하고 싶은 것

외부에서 들어온 데이터를 직접 해석하는 라이브러리(이미지, PDF, 비디오, 압축 파일 등)에 대해, 현재 사용 중인 버전과 상위 레벨의 최신 버전을 나란히 비교해 보세요.

## ③ '주변 도구도 SSO로 통합하면 편리하다'

### 무슨 일이 일어났나

OpenAI 포럼에는 'Sign in with OpenAI', 즉 `auth.openai.com`을 사용한 SSO가 내장되어 있었습니다. 연구자들은 '포럼이 탈취되면, 이 로그인 연동을 통해 OpenAI의 다른 서비스에도 도달할 수 있지 않을까?'라고 생각했습니다.

결과적으로 포럼 침해를 통해, 해당 포럼을 이용하던 OpenAI 직원의 ChatGPT/Codex 계정에 접근할 수 있는 상태가 되었습니다.

SSO 미비점이 구체적으로 어떤 메커니즘이었는지는 보고서에 공개되어 있지 않습니다. 다만 저자들은 '이것은 Discourse 고유의 문제가 아니라, OpenAI의 SSO 문제'라고 명확히 밝히고 있습니다.

### 우리 현장에 비유하자면

사내 Wiki, 문의 포럼, 테스트 삼아 만든 관리 화면 등. 이 같은 주변 도구들을 실제 서비스와 동일한 로그인에 연결하는 것은 흔한 일입니다. 로그인이 하나로 해결되는 것은 사용자에게도 운영자에게도 매우 편리하죠.

하지만 그때 '주변 도구가 탈취되지는 않을 것'이라고 어딘가에서 착각하고 있지는 않나요? 실제로는 주변 도구일수록 업데이트나 모니터링에 손이 덜 가는 경우가 많다고 생각합니다.

### 확인하고 싶은 것

로그인을 공통으로 사용하는 서비스를 목록화하여, 각각에 대해 다음 질문에 답해 보세요.

| 질문 | 살펴볼 포인트 |
|---|---|
| 이 서비스가 탈취되면 무엇을 얻을 수 있는가 | 전달되는 토큰이나 속성(attribute), 스코프(scope) |
| ... | |
주변 도구가 탈취되더라도 본체 계정까지는 가져가지 못한다고 단언할 수 있는지, 이곳을 한 번 확인해 보는 것만으로도 상당히 안심이 될 것입니다.

## ④ 'AI 에이전트에게 GitHub 연동을 그대로 두다'

### 무슨 일이 일어났나

접근 가능한 직원의 계정을 확인해보니, 그 사람의 Codex가 OpenAI의 GitHub 조직과 연결되어 있었습니다. 연구자들은 Codex에게 지시를 내려 회사 내부 모노레포 `openai/openai`에 무해한 풀 리퀘스트(#1186742)를 만들게 했습니다. 그리고 거기서 조사를 멈췄습니다.

여기서 주목할 점은, 연구자들이 사내 코드를 직접 조작한 것이 아니라는 사실입니다. 직원의 AI 에이전트에게 '부탁'했을 뿐입니다.

### 우리 현장에 비유하자면

Claude Code나 Codex, Cursor 같은 AI 에이전트에게 GitHub나 Slack, 클라우드의 권한을 부여하여 사용하는 것은 이미 당연해지고 있습니다.

AI 에이전트는 소유자 대신, 소유자의 권한으로 움직여 줍니다. 매우 믿음직스러운 존재이지만, 반대로 생각하면 계정을 탈취하는 순간, 똑같은 신뢰성으로 공격자의 지시에도 따르게 된다는 것입니다.

### 점검해보고 싶은 것들

- AI 에이전트와 연동된 리포지토리를 필요한 것에만 한정하고 있는가 (조직 전체에 대한 접근을 허용하지 않는가)
- main 브랜치 등에 보호 규칙(保護ルール)을 설정하여, PR이 생성되어도 리뷰 없이는 병합되지 않도록 하는가
- AI 에이전트가 만든 PR이나 커밋을 사람의 변경 사항과 구분하여 추적할 수 있는가

이번에는 'PR이 1건 생성되었다'는 지점에서 멈춘 것은 연구자들이 스스로 손을 멈췄기 때문입니다. 만약 악의적인 공격자였다고 생각하니 조금 오싹합니다.

## 요약 - 네 가지를 연결해서 보기 -

다시 살펴보니, 어떤 단계도 하나만 보면 '흔한 판단'에 불과했습니다.

표를 보면, 어느 한 곳이라도 멈춰 있었다면 체인이 거기서 끊어졌음을 알 수 있습니다.

하지만 이 네 단계를 연결하는 작업, 특히 ②의 공격 코드 제작은 지금까지 숙련자가 오랜 시간을 들여 수행하던 것이었습니다. 이번에는 AI의 힘을 빌려 취약점 발견부터 사내 리포지토리로의 PR까지 72시간도 걸리지 않았습니다. 이러한 간과를 그대로 둘 수 있는 시간은 생각보다 짧아지고 있다고 생각하는 편이 좋을 것 같습니다.

| 단계 | 현장에서 흔한 판단 | 실제로 일어난 일 |
|---|---|---|
| ① | 이미지는 라이브러리에 맡기면 된다 | 예상치 못한 HEIC 파일이 백그라운드 라이브러리까지 도달했다 |
| ② | `apt upgrade` 했으니 최신이다 | CVE가 없는 수정 사항이 배포처에 전달되지 않았다 |
| ③ | 주변 툴도 SSO로 통합하면 편하다 | 포럼의 침해가 본체 계정에 도달했다 |
| ④ | AI 에이전트에 연동을 계속 켜두기 | 탈취된 계정의 AI가 사내 리포지토리까지 도달했다 |

## 끝으로

이 보고서를 읽으면서, ①부터 ④에 걸쳐 비슷한 간과가 자신의 개발 현장에 있을 것 같다는 느낌을 받았고, 제 현장을 재점검하는 계기로 삼고 싶었습니다.

공격자 입장에서 보면, 하나하나의 흔한 판단들이 퍼즐 조각이 됩니다. 그리고 이 조각들이 맞춰지기까지의 수고는 AI에 의해 점점 줄어들고 있습니다.

본 기사가 여러분 자신의 현장에 숨겨진 간과를 발견하는 계기가 되기를 바랍니다.

## 주식회사 ONE WEDGE

【IT 엔지니어에게, IT 업계에 공헌하는 기업】

주식회사 ONE WEDGE는 웹 시스템 개발, SES(System Engineering Service), AI/DX 지원을 하는 IT 기업입니다. 생성형 AI를 활용한 업무 효율화나 차세대 시스템 개발에도 주력하고 있으며, 기업의 과제 해결뿐만 아니라 엔지니어 개개인의 성장에도 진심으로 임하고 있습니다. 또한, 기술은 '혼자 배우는 것'이 아니라 '함께 성장하는 것'이라고 생각하여 사내외 커뮤니티 조성에도 힘쓰고 있습니다.

### 토론
![](https://static.zenn.studio/images/drawing/discussion.png)