90일 책임 공개는 LLM으로 발견자와 익스플로잇 속도가 늘며 보호 효과를 잃음
6주 동안 11명이 같은 치명적 결제 검증 버그를 보고해 동시 재발견이 드러남
React 패치 diff는 AI 도움으로 30분 만에 작동 익스플로잇으로 바뀜
Copy Fail과 Dirty Frag는 공개 PoC와 실제 악용으로 이어져 엠바고가 무너짐
치명적 이슈는 P0로 즉시 처리하고, LLM을 보안 파이프라인에 넣어야 함


90일 책임 공개 모델이 깨진 배경

90일 책임 공개 기간은 버그 발견자가 드물고 익스플로잇 개발이 느리던 환경을 전제로 만들어졌음
최근 12개월 동안 보안 담당자, 공격자, 연구자가 쓰는 도구가 비슷한 속도로 더 똑똑해졌고, LLM이 취약점 발견과 익스플로잇 개발 시간을 거의 0에 가깝게 줄였다는 판단임
2019년식 모델에서는 Google Project Zero 스타일처럼 벤더에 90일을 주고, 그동안 다음 전제를 뒀음

같은 버그를 찾은 사람이 거의 없을 것
다른 사람이 찾아도 시간이 걸릴 것
벤더가 패치 작성에서 충분한 선행 시간을 가질 것
패치가 공개된 뒤 공격자가 이를 역공학해 작동하는 익스플로잇을 만들기까지 며칠 또는 몇 주가 걸릴 것


이 전제들이 모두 틀렸고, 90일 창은 사용자를 보호하기보다 이미 버그를 가진 사람들에게 90일의 선행 시간을 주는 구조가 됐음

사례 1: 6주 동안 11명이 같은 치명적 버그를 보고함

4월 말 한 회사에 심각한 버그를 보고했지만, 트리아지 팀은 3월에 처음 보고됐고 본인이 11번째 제보자라고 답함
버그의 형태는 웹사이트에서 물건을 산 뒤 공격자가 직접 조작한 응답을 서버에 돌려보내도, 응답에 대한 서명 검증이 없어 서버가 이를 그대로 받아들이는 구조였음

예시로 5,000달러짜리 물건을 0달러에 사거나, 실제 결제 없이 구매를 완료 처리할 수 있었음


약 6주 동안 서로 다른 11명이 같은 치명적 버그를 찾았다는 점에서, LLM 지원 사냥꾼들이 거의 동시에 같은 취약점에 수렴하는 패턴이 드러남
BlueWater CTF의 한 지인은 몇 달 전부터 서로 관련 없는 리포터와 워크플로가 LLM 보조로 같은 버그에 모이는 현상을 짚었음
트리아지 측에서도 같은 현상이 관측됨

@d0rsky는 LLM 프롬프트, 스킬, 자동화로 새 취약점이 발견되면 며칠 안에 같은 근본 원인의 중복 보고가 몰린다고 썼음
연구자가 이렇게 빨리 재현할 수 있다면, 패치 전에 블랙햇도 같은 일을 할 수 있다는 우려가 커짐


10명이 보고했다면 보고하지 않은 사람도 있을 수 있고, 같은 LLM은 선의의 연구자뿐 아니라 다른 누구에게도 열려 있음
CVE 크레딧과 버그바운티는 1명만 받을 수 있어 나머지 9명이나 애초에 보고하지 않은 사람은 90일 시계에 묶여 있지 않음
90일 공개 창은 이 상황에서 사용자를 보호하지 못하고, 이미 버그를 가진 사람들에게 시간을 벌어주는 장치가 됨

사례 2: React 패치에서 작동하는 익스플로잇까지 30분

React는 여러 보안 이슈를 패치하고 공개 블로그 글을 냈음

CVE-2026-23870
CVE-2026-44575
CVE-2026-44579
CVE-2026-44574
CVE-2026-44578


로컬 테스트 앱을 대상으로 패치를 읽고 작동하는 익스플로잇을 만드는 데 30분이 걸렸음
해당 공개 이슈는 서비스 거부(DoS)였고, AI가 diff 이해, 취약한 코드 경로 식별, PoC 작성의 대부분을 처리했음
과거에는 공개 패치를 작동하는 n-day 익스플로잇으로 바꾸는 데 숙련된 역공학자가 며칠에서 몇 주를 썼고, 이 시간차가 관리자가 업데이트할 수 있는 안전망이었음
이제 단순한 버그는 몇 분, 복잡한 버그도 몇 시간 단위가 될 수 있으며, 숙련된 역공학자는 필수가 아니게 됨
패치가 나오는 순간 익스플로잇도 존재한다고 가정해야 하고, 다음 유지보수 창까지 배포를 미루는 방식은 맞지 않음

사례 3: Linux 커널에서 연달아 터진 Copy Fail과 Dirty Frag

최근 2주 동안 Linux 커널에서 연속으로 두 개의 치명적 취약점이 나왔고, 둘 다 공개 익스플로잇이 있었으며 주요 배포판에 영향을 줬음

Copy Fail

4월 29일 Xint Code가 Copy Fail을 공개함
Xint Code는 Theori 뒤의 팀이며, DEF CON CTF를 9회 우승한 팀으로 소개됨
Copy Fail은 CVE-2026-31431이며, 커널 crypto 하위 시스템의 직선적인 논리 결함으로 설명됨
레이스 컨디션 없이 100% 신뢰 가능하고, 732바이트 Python 스크립트로 2017년 이후 배포된 모든 Linux 배포판에서 root 권한을 얻을 수 있다고 함
Ubuntu, RHEL, Amazon Linux, SUSE 등 주요 배포판이 영향을 받음
AI를 사용해 커널 crypto/ 하위 시스템을 약 1시간 자동 스캔해 찾았고, 9년 동안 노출된 취약점이었다고 함
기술 분석은 Xint의 글에 있음
mainline 커밋 a664bf3d603d로 패치가 나왔고, algif_aead 모듈 비활성화라는 완화책도 있었음
이후 이란 공격자가 해당 취약점을 이용해 Ubuntu 서버를 침해하고 DDoS 캠페인 노드로 재활용하는 정황이 관측됐다고 함
AI로 발견된 커널 권한 상승 취약점이 공개 PoC와 국가 단위 공격자의 무기화로 이어지는 데 며칠밖에 걸리지 않았음



Dirty Frag

약 1주 뒤인 5월 7일 Hyunwoo Kim(@v4bel)이 Dirty Frag를 공개함
Dirty Frag는 CVE-2026-43284와 CVE-2026-43500을 연결한 취약점임
커널의 IPSec ESP(esp4/esp6)와 RxRPC 네트워킹 모듈에 있는 두 취약점을 체인으로 연결함
Copy Fail 및 Dirty Pipe와 같은 버그 계열, 같은 page-cache corruption 기법이지만 공격 경로는 다름
Copy Fail 완화책을 적용해도 Dirty Frag는 동작함

algif_aead를 블랙리스트에 올려도 Dirty Frag는 해당 모듈을 쓰지 않음


비권한 사용자에서 root로 결정적으로 상승할 수 있고, Ubuntu, RHEL 10.1, openSUSE, CentOS Stream, AlmaLinux, Fedora 44 등 주요 배포판에서 동작한다고 함
컴파일과 실행은 한 줄 명령으로 가능함



Dirty Frag 공개 과정과 엠바고 붕괴

Hyunwoo Kim은 4월 29~30일 [email protected]에 보고했고, 패치를 공개 제출했음
5월 7일 linux-distros 메일링 리스트와 조율했고 5일 엠바고가 합의됨
같은 날 몇 시간 안에 관련 없는 제3자가 ESP 취약점의 상세 익스플로잇 정보를 공개해 엠바고가 깨짐
배포판 유지관리자들과 상의한 뒤 Hyunwoo는 Dirty Frag 전체 분석, 익스플로잇 코드, 작동 PoC를 공개함
그 시점에 패치를 제공하는 Linux 배포판은 0개였음
현재 기준으로 CVE-2026-43284, 즉 ESP 쪽만 mainline 수정이 있고, CVE-2026-43500, 즉 RxRPC 구성요소는 아직 upstream 패치가 없다고 함
Ubuntu, Red Hat, Tenable 등이 자체 권고문을 냈음



Dirty Frag의 실제 악용

Microsoft Defender 팀은 공개 후 24시간 안에 제한적인 실제 악용을 확인함
공격자는 SSH 접근을 얻고, ELF 바이너리를 배포하고, su로 root 권한을 얻고, 인증 설정을 수정하고, 세션 파일을 지우고, 횡적 이동을 수행했다고 함
CTS(@gf_256)는 “responsible disclosure is dead🤦”라고 요약함



실제로 죽은 것들

90일 공개 창은 고칠 수 있는 문제가 아니라 끝난 모델임
이 모델은 발견자가 드물고 익스플로잇 개발이 느리던 세계에 맞춰졌지만, LLM은 발견자를 많게 만들고 익스플로잇 개발을 빠르게 만듦
서로 관련 없는 10명이 6주 안에 같은 버그를 찾고, AI가 patch diff를 30분 만에 작동 익스플로잇으로 바꿀 수 있다면 90일 창은 아무도 보호하지 못함
Copy Fail은 AI 스캔에서 공개 PoC, 국가 단위 공격자의 무기화까지 며칠 만에 이어졌음
Dirty Frag는 같은 버그 계열을 독립적으로 찾은 제3자 때문에 엠바고가 몇 시간 만에 깨짐
같은 취약점이 여러 연구자와 AI 도구에 의해 동시에 독립 재발견되는 환경에서는 공개 조율이 유지되기 어려움
월간 패치 주기도 끝났음

취약점과 수정 사이 30일 창은 공격자가 릴리스 트레인보다 느리다는 전제를 둠
Microsoft가 Dirty Frag 실제 악용을 24시간 안에 본 상황에서 월간 유지보수 창은 안전 여유가 아니라 공격 창이 됨


권고문을 기다리는 방식도 끝났음

방어자가 CVE 설명을 읽는 동안 공격자는 git log --diff-filter=M을 읽고 있음
권고문은 downstream 산출물이고, patch diff가 신호가 됨



업계가 바꿔야 할 대응

모든 치명적 보안 이슈를 P0로 보고 즉시 고쳐야 한다는 결론임
“24시간 안”, “다음 스프린트”, “영향 평가 후”가 아니라, 하던 일을 멈추고 바로 고치는 수준이 필요함
프로덕션 배포가 복잡하고 변경 관리가 필요한 이유는 있지만, 위협 환경은 변경 관리 절차를 기다리지 않음

벤더

치명적 버그 보고가 들어온 순간부터 시간이 흐르기 시작함
트리아지가 끝난 시점이나 엔지니어링이 맡은 시점이 아니라, 보고가 도착한 순간이 기준임
누군가 보고했다면 10명이 이미 갖고 있고 그중 최소 1명은 우호적이지 않다고 가정해야 함



연구자

치명적 버그를 오래 보유하지 말고 가능한 가장 짧은 공개 창을 밀어야 함
벤더가 1주 안에 고치지 못한다면 이는 공개 문제가 아니라 벤더 문제임
과거의 “시간을 준다”는 예의는 자신이 유일한 발견자일 때 의미가 있었지만, 이제는 유일한 발견자가 아닐 가능성이 큼



취약점 관리

취약점 관리는 실시간이어야 함
“주간 스캔, 스프린트에서 트리아지, 주기에 맞춰 패치”는 공격자가 이미 떠난 타임라인임
치명적 이슈의 새 최대 응답 시간은 며칠이 아니라 몇 시간이고, 그마저도 느릴 수 있음



블루팀이 LLM을 방어 파이프라인에 넣어야 하는 이유

공격자는 이미 LLM을 익스플로잇 파이프라인에 통합했으며, 방어 측도 같은 속도로 움직여야 함
코드 push 시점에 LLM을 통합해야 함

모든 pull request, merge, deploy에서 AI 지원 보안 리뷰를 CI 파이프라인 일부로 실행해야 함
linter와 unit test처럼 push 시점에 실행해야 하며, 분기별 감사나 사후 점검이 아니어야 함
취약점이 있으면 프로덕션 도달 전에 잡아야 하고, PR 리뷰에서 고치는 비용은 CVE 공개 후 고치는 비용보다 훨씬 낮음


패치 분석에도 LLM을 통합해야 함

upstream 의존성이 보안 패치를 내면 파이프라인이 자동으로 diff를 가져오고, 변경 내용을 분석하고, 자사 코드베이스 영향 여부를 판단하고, 플래그를 올려야 함
사람이 메일링 리스트를 읽고 Jira 티켓을 여는 방식에 의존하지 않고, 공개 저장소에 패치가 올라오는 즉시 몇 분 안에 자동으로 일어나야 함
Xint Code가 자동 스캔 1시간으로 Copy Fail을 찾았다면, 자체 의존성도 같은 방식으로 스캔해야 함


의존성 스캐닝에도 LLM을 써야 함

공급망은 가장 약한 전이 의존성만큼만 강함
AI 기반 의존성 스캐너는 의존성 트리에서 취약점 영향을 추적하고, 영향받는 버전을 표시하고, 업그레이드 경로도 제안할 수 있음
주간이 아니라 지속적으로 실행해야 함


패치 출시 전 AI로 패치를 테스트해야 함

React 사례처럼 LLM이 30분 만에 패치를 익스플로잇으로 바꿀 수 있다면, 방어자는 패치 공개 전에 같은 도구로 먼저 검증해야 함
패치가 실제로 문제를 고치는지, 새 문제를 만들지 않는지 확인해야 함
회귀 테스트 생성, 같은 패턴이 코드베이스 다른 곳에 있는지 확인하는 데 활용해야 함


“취약점 존재”와 “취약점 악용” 사이의 창은 0에 가까워지고 있으며, 방어 쪽도 공격 쪽과 같은 속도로 자동화해야 함
더 많은 zero-day가 더 빠르게 실제 환경에서 악용될 것이며, 같은 도구, 낮아진 진입 장벽, 늘어난 발견자, 짧아진 타임라인이 그 이유임
이 전환에서 살아남는 팀은 강제로 밀려나기 전에 AI를 보안 파이프라인의 일급 구성요소로 만든 팀임

결론

Dirty Frag 권고문을 읽는 시스템 관리자가 패치는 없고, 익스플로잇은 이미 공개됐고, Microsoft는 실제 악용을 보고 있으며, 완화책은 IPSec 모듈 비활성화인 상황에서 400대 서버를 만져야 하는 현실이 새 기준이 됨
90일 공개 정책, 월간 패치 주기, 공개와 악용 사이에 시간이 있다는 가정은 모두 죽었음
아직 남아 있는 것은 빠르게 움직이고, 강하게 자동화하고, 치명적 버그를 실제 긴급상황처럼 다루는 능력임
기존 모델을 깬 AI 물결은 동시에 빠른 패치, 자동 스캔, 실시간 위협 인텔리전스, AI 지원 코드 리뷰 같은 새 모델도 가능하게 함
도구는 이미 있으며, 방어자가 공격자보다 먼저 사용할지가 핵심이고, 현재는 공격자가 그 경쟁에서 앞서 있음