LLM이 N-day 익스플로잇을 얼마나 앞당기는지 잰 Anthropic 리포트를 읽고
Anthropic Frontier Red Team이 2026년 6월에 낸 「Measuring LLMs' impact on N-day exploits」를 읽었어요. 이미 공개된 보안 패치를 모델에게 주고, 익스플로잇을 얼마나 빨리 만드는지 Firefox와 Windows 커널에서 잰 리포트예요. 여기서는 인사이트 네 개를 정리했어요.
들어가기 전에 — 용어 짚기
N-day / patch gap — N-day는 이미 공개돼서 패치까지 나왔지만, 아직 모든 기기에 깔리지는 않은 취약점이에요. 소프트웨어 관리자도 모르는 zero-day와 반대쪽에 있는 개념이고요. 패치가 나온 뒤 실제 기기에 적용되기까지의 틈을 patch gap이라고 부르는데, 공격자는 이 틈에 아직 패치하지 않은 시스템을 노려요. 인사이트 1과 3에서 이 틈의 길이를 모델이 익스플로잇을 만드는 시간과 직접 비교해요.
인사이트 1: 패치가 올라온 지 한 시간 만에 익스플로잇이 나왔어요
패치 전후 코드를 비교해서 무엇이 고쳐졌는지 찾고, 거기서 버그를 역추적하는 걸 patch diffing이라고 해요. 원문은 Firefox JS 엔진(SpiderMonkey) 패치 18건의 diff와 수정 전후 빌드처럼 공개된 정보만 주고 이 과정을 모델에게 맡겼어요.
Mythos Preview는 첫 번째로 동작하는 익스플로잇을 한 시간이 채 안 돼 작성했고, 약 12시간 동안 서로 다른 익스플로잇 8개를 만들었어요. (…) Mythos Preview는 Mozilla가 패치를 올린 지 한 시간 안에 첫 익스플로잇을 만들었는데, 그 패치가 들어간 Firefox 148이 정식 릴리스되기까지는 18일이 남아 있었어요.
Firefox는 자동 업데이트에 재시작 한 번이면 적용되고, 중간 릴리스도 월 단위에서 주 단위로 줄인 소프트웨어예요. 원문도 방어자에게 거의 최선의 조건이라고 봐요. 이 실험은 Anthropic이 앞서 Mozilla와 한 공동 작업의 환경과 채점기를 그대로 가져다 썼어요.
그런 최선의 조건에서도 익스플로잇은 패치가 올라오고 한 시간 만에 나왔어요. 모델 세대가 올라가면서 크래시 PoC를 만든 패치 수도 2건에서 11건으로 늘었고요(Opus 4.5에서 Opus 4.8로). 이 두 숫자를 보니 앞으로 AI를 사용한 해킹은 늘어날 것 같아요.
인사이트 2: 소스 없이 바이너리만으로 Windows 커널 권한 상승까지 갔어요
Windows는 소스가 없어서, 모델은 변수명과 타입이 빠진 바이너리와 Ghidra 디컴파일 결과만 보고 작업했어요. 목표는 일반 사용자 권한에서 시스템 최고 권한인 SYSTEM까지 올라가는 거였고요.
전체 체인 익스플로잇을 하나 만든 데 그치지 않고 서로 다른 익스플로잇 8개를 만들었고, API 비용은 $15,700, 권한 상승 한 건당 평균 약 $2,000이었어요. 이제 N-day 공격에 필요한 건 수천 달러와 API 접근뿐이고, 그래서 N-day 공격을 할 수 있는 사람이 크게 늘어나요.
Microsoft가 "Exploitation Unlikely(악용 가능성 낮음)"로 매긴 버그 하나도 권한 상승까지 갔어요. 원문은 이 등급이 사람 연구자 기준으로 맞춰져 있어서 바뀌어야 할 수 있다고 써요.
Windows처럼 전 세계 사람들이 자주 쓰는 소프트웨어도 소스 없이 바이너리만으로 이렇게 뚫렸어요. 이런 소프트웨어도 안전할 수 없고, 바이너리만 보고 취약점을 찾는 걸 막을 방법은 없어 보여요.
인사이트 3: 패치가 기기에 깔리기 전에 익스플로잇이 먼저 완성돼요
Windows Autopatch 일정을 기준으로 보면(오늘날 패치 관리 중에서는 빠른 편일 거예요), 패치가 등록된 기기의 90%에 배포되기까지 보통 7일이 걸려요. 강제 재부팅은 11일째에야 이뤄지고요. 이 속도라면 Mythos Preview는 Windows 기기 중 어느 하나라도 업데이트로 패치를 받기 전에 전체 체인 익스플로잇 8개를 모두 완성했을 거예요.
국내에서는 KISA 보호나라가 주요 벤더의 보안 업데이트를 공지해 적용을 권고하고 있어요(boho.or.kr). 원문 결론은 월간 릴리스와 몇 주에 걸친 단계적 배포로 이뤄진 지금의 패치 방식이 더는 버티지 못한다고 말해요.
패치가 기기에 깔리기까지 걸리는 이 일주일은 웹에는 없는 시간이에요. 웹은 무중단으로 24시간 실시간 배포가 가능하지만, 소프트웨어나 바이너리는 그게 안 돼요. 그래서 대안이 필요해 보여요.
인사이트 4: 결론은 버그의 공급 자체를 줄이는 거예요
더 오래가는 해법은 패치하는 속도가 아니라 버그의 공급 자체를 공략하는 거예요. 핵심 컴포넌트를 Rust 같은 메모리 안전 언어로 옮기거나, 공격 기법 한 부류를 한꺼번에 막는 완화책(Control Flow Guard, 하드웨어 shadow stack 등)으로 단단하게 만드는 데서 시작할 수 있어요. 이것으로 공격 표면을 다 없앨 수는 없지만, 크게 줄일 수는 있어요.
Control Flow Guard와 shadow stack은 메모리 버그로 프로그램 실행 흐름을 엉뚱한 곳으로 돌리는 공격을 막는 장치예요. 버그를 고치는 쪽이 병목이라는 이야기는 앞서 읽은 글래스윙 글에서도 나왔어요.
인사이트 3에서 본 것처럼 패치는 어차피 빠르게 공급할 수 없으니, 버그 자체를 줄이자는 건 좋은 방향 같아요. 다만 메모리 안전 언어로 옮겨도 인증 같은 건 키를 어딘가에 숨겨 놓을 수밖에 없어서 구멍이 생길 수밖에 없거든요. 뭔가 그런 인증 프로토콜을 새로 만들어야 하는 건지, 고민이 많이 돼요.
원문은 결론에서 "N-day"라는 이름이 위험할 만큼 오해를 부른다며, 지금 현실은 "N-hour"에 더 가깝다고 써요.
