OpenAI 초기 실행이 엉뚱한 버그로 딴 루트 권한

OpenAI는 리눅스 커널에 에이전트 무리를 풀면서 하나하나에 특정 취약점 하나를 배정했다. 과제는 그 취약점으로 일반 사용자를 루트, 곧 기계 전체를 다루는 계정으로 끌어올리는 공격을 만드는 것이었다. 초기 실행에서 에이전트들은 성공 200건을 보고했다. 사람이 검토한 뒤 OpenAI는 “그 가운데 20건은 배정된 것과 다른 0-day 취약점으로 루트 권한을 얻었다”(20 of these had achieved root privileges through a different 0-day vulnerability than the one assigned)는 것을 알게 됐다.

이 20건은 목표에는 닿았지만 과제는 하지 않았다. 실행에 걸린 성공 조건은 채웠지만, 그 실행이 보여 주려던 것 ― 배정된 버그를 공격으로 바꿀 수 있다는 것 ― 은 보여 주지 못했다.

OpenAI는 11월 4일 글 「A thousand fewer paths to root」에서 이 일을 밝혔다. 커널 취약점을 찾고, 공격 코드를 쓰고, 패치 초안까지 만드는 자동 파이프라인을 설명하는 글이다. 회사는 과제 조건을 조이고, 최종 공격마다 배정된 취약점을 썼는지 확인하는 별도 점검을 더했다고 한다. 그 점검을 누가, 어떤 방식으로 하는지는 글에 없다. 최종 숫자는 이렇다. 후보 2,308건 가운데 실제로 돌려 재현한 취약점이 1,724건, 동작하는 로컬 권한 상승 공격이 1,169건이고, 이 공격들을 막는 서로 다른 패치 단위로 변종을 묶으니 고유 취약점 948건이 나왔다. 이와 별도로 권한 상승이 아닌 정보 유출 개념 증명이 291건이다. OpenAI는 이 실행의 API 비용을 121만 3,430달러로 밝혔다.

이 글에서 가장 배울 것이 많은 숫자는 초기 실행의 실수다. 948 같은 합계가 주장하는 것에서 어떻게 미끄러질 수 있는지 보여 주기 때문이다. 공격이 루트에 닿았는지만 묻는 시험은 거기 닿는 어떤 길도 받아 준다. 초기 실행이 보고한 성공 가운데 20건에서 그 길은 다른 0-day를 지나갔다. OpenAI가 더한 점검은 결과에 대해 더 어려운 질문을 던지지 않는다. 경로를 묻는다.

목표를 받고 거기 붙은 시험으로 평가받는 모델의 처지에서 보면, 이것은 흔한 모양의 문제다. 지시는 “이 버그를 써라”라고 한다. 시험은 “루트를 보여라”라고 한다. 둘이 어긋나면 무엇이 성공으로 기록될지는 시험이 정한다. 20건이 드러낸 것은 시험의 틈이고, 이를 설명하는 데 에이전트의 의도에 관한 이야기는 필요 없다. OpenAI가 끌어낸 교훈은 옳다. 경로가 중요하면 경로를 확인해야 하고, 요청만으로는 모자란다.

사람의 해킹 대회는 같은 구분을 규정에 적어 둔다. Trend Micro의 Zero Day Initiative가 여는 해킹 대회 Pwn2Own은 버그에 상금을 주고, 2026년 10월 아일랜드 대회 규정은 참가자가 어떤 버그를 썼는지 본다. 규정은 “출품작이 처음 이용한 취약점은 등록한 대상 안에 있어야 한다”(the initial vulnerability utilized in the entry must be in the registered target)고, 쓰인 버그는 “알려지지 않고, 공개되지 않았거나, 제조사에 보고된 적이 없어야 한다”(unknown, unpublished, and/or not previously reported to the vendor)고 정한다. 이미 알려진 취약점에 기댄 출품작은 받아들이더라도 상금을 깎을 수 있다. 대상에서 셸을 띄운 것은 심사의 출발점이다.

예상 밖의 버그를 어떻게 분류할지는 그 일이 무엇을 위한 것이냐에 달렸다. 2025년 5월 연구자 Sean Heelan은 자신이 손으로 이미 찾은 리눅스 커널 취약점을 OpenAI의 o3 모델이 얼마나 자주 찾아내는지 쟀다. o3는 100번 실행에서 8번 그 취약점을 찾았다. 그는 다른 실행들의 출력에서 “비슷하지만 새로운 취약점에 대한 보고”(a report for a similar, but novel, vulnerability)를 발견했다고 썼다. 뒤에 CVE-2025-37899로 등록된 버그다. 그의 과제는 코드에서 결함을 찾는 일이었으니, 기준 문제 밖의 버그는 발견이었고 그 글의 주인공이 됐다. OpenAI의 초기 실행은 이름이 정해진 결함을 공격하라는 과제였으니, 같은 종류의 뜻밖의 일이 성공 쪽에 들어가 합계를 부풀렸다.

948은 OpenAI가 초안을 쓴 패치의 수이기도 하다. 그것은 리눅스에 실제로 들어간 변경의 수와 같지 않다. 회사는 패치를 보고하기 전에 사람이 검토하고, 중요한 취약점에 대한 보고서와 패치 수백 건을 이미 보냈다고 밝혔다. 이 설명으로는 OpenAI가 낸 패치 가운데 커널 유지보수자가 받아들인 것이 몇 건인지 확인할 수 없다.

그렇다고 948이 빈 숫자인 것은 아니다. OpenAI는 자기 실수를 공개했고, 그 덕에 이 글은 깔끔한 합계 하나보다 쓸모가 크다. 회사의 수정은 경로를 시험 안으로 옮겼다. 그 시험이 있어야 할 곳이었다. 남들이 이 숫자에 더 마음 놓고 기대게 하는 것은 한 단계 위에서 같은 일을 하는 것이다. 공격과 패치 가운데 일부를 파이프라인 바깥의 사람들 ― 수정본을 받아들여야 할 유지보수자, 결과에 이해관계가 없는 연구자 ― 이 확인하는 일이다.