Claude가 FreeBSD 원격 커널 익스플로잇을 4시간 만에 완성했다, AI 보안의 새 경계

AI가 소프트웨어 버그를 찾는 시대는 이미 왔습니다. 그런데 찾은 버그를 무기화 하는 것까지 AI가 해낸다면 어떨까요? 2026년 3월 29일, 보안 연구 기관 Calif.io가 그 답을 내놨습니다. Anthropic 소속 연구원 Nicholas Carlini가 Claude에게 FreeBSD 커널 취약점 CVE-2026-4747의 익스플로잇 개발을 맡겼고, Claude는 약 4시간의 실제 작업 시간 만에 원격 루트 셸(uid=0)을 획득하는 완전한 익스플로잇 2종 을 작성했습니다. 둘 다 첫 시도에 성공했습니다.

이것은 AI가 발견하고 AI가 익스플로잇까지 완성한 최초의 원격 커널 취약점 사례입니다. 퍼저가 크래시를 유발하거나 AI가 코드 리뷰에서 버그를 짚어내는 수준이 아닙니다. ROP 체인을 설계하고, 셸코드를 작성하고, 커널 스레드를 하이재킹하여 루트 권한의 리버스 셸을 열어주는, 처음부터 끝까지 완성된 공격 코드입니다.

AI 보안 연구, 18개월간의 가속

이번 사건을 이해하려면 AI가 보안 연구에 투입되어 온 흐름을 먼저 살펴봐야 합니다.

2024년 10월, Google Project Zero와 DeepMind가 공동 개발한 Big Sleep 프레임워크가 SQLite에서 실제 익스플로잇 가능한 스택 버퍼 언더플로우를 발견했습니다. Gemini 1.5 Pro를 사용한 이 사례는 "AI 에이전트가 실제 소프트웨어에서 미지의 메모리 안전 취약점을 발견한 최초의 공개 사례"로 기록됐습니다. 하지만 여기까지였습니다. 발견은 했지만, 완전한 익스플로잇 개발은 아니었습니다.

2026년 2월, Anthropic이 Claude Code Security를 발표하며 판을 키웠습니다. Claude Opus 4.6를 프로덕션 오픈소스 코드베이스에 투입해 500개 이상의 고심각도 제로데이 취약점 을 발견했다고 밝혔습니다. 각 취약점은 Anthropic 팀원이나 외부 보안 연구원이 검증했고, 2월 20일에 리서치 프리뷰로 공개됐습니다.

2026년 3월 6일, Anthropic은 Mozilla와의 파트너십을 통해 Claude Opus 4.6로 Firefox에서 2주 만에 22개의 보안 취약점 (고심각도 14개, 중간 7개, 낮음 1개)을 발견했다고 발표했습니다. 약 6,000개의 C++ 파일을 스캔하고 112건의 리포트를 제출한 결과입니다. 다만 PoC 익스플로잇 작성에는 $4,000의 API 크레딧 을 투입하고도 2건만 성공했으며, 브라우저 샌드박스 탈출까지는 도달하지 못했습니다.

그리고 2026년 3월 29일, MAD Bugs 프로젝트가 경계를 넘었습니다. 단순한 버그 발견이 아니라, 완전한 원격 커널 익스플로잇 을 AI가 독립적으로 작성한 것입니다.

MAD Bugs 프로젝트란

MAD Bugs(Month of AI-Discovered Bugs)는 Calif.io가 운영하는 보안 연구 이니셔티브입니다. 2026년 4월 말까지 AI를 활용해 발견한 보안 버그와 익스플로잇을 순차적으로 공개하는 프로젝트로, 지금까지 세 건이 공개됐습니다.

1. Vim RCE — tabpanel modeline 원격 코드 실행 (v9.2.0272 미만)
2. GNU Emacs RCE — 파일 열기 시 트리거되는 다중 원격 코드 실행 벡터 (메인테이너가 수정 거부)
3. FreeBSD 커널 RCE — CVE-2026-4747, 이번 취재 대상

프로젝트를 이끄는 Nicholas Carlini는 적대적 머신러닝 분야의 선구자입니다. UC Berkeley에서 David Wagner 지도 하에 박사를 마쳤고, Google Brain과 DeepMind를 거쳐 현재 Anthropic에서 언어 모델의 보안 위험을 연구하고 있습니다. 2016년 Carlini & Wagner 공격으로 유명하며, IEEE S&P, USENIX Security, ICML에서 최우수 논문상을 수상한 경력이 있습니다.

CVE-2026-4747, 무엇이 어떻게 뚫렸나

이제 기술적 핵심을 살펴보겠습니다. CVE-2026-4747은 CVSS v3.1 9.8점(Critical) 의 치명적 취약점으로, 지원되는 모든 FreeBSD 버전(13.5, 14.3, 14.4, 15.0)에 영향을 미칩니다.

취약점의 본질

문제는 sys/rpc/rpcsec_gss/svc_rpcsec_gss.c의 svc_rpc_gss_validate() 함수에 있습니다. 이 함수는 GSS-API 서명 검증을 위해 RPC 헤더를 128바이트 고정 스택 버퍼(rpchdr[]) 에 재구성합니다. 고정 RPC 헤더 필드가 32바이트를 차지하므로, 남은 버퍼 공간은 96바이트입니다.

핵심은 RPCSEC_GSS 크리덴셜 바디 전체를 memcpy()로 복사하면서 경계 검사를 하지 않는다 는 점입니다. 크리덴셜 바디(oa_length)가 96바이트를 초과하면 스택 오버플로우가 발생합니다. XDR 레이어가 MAX_AUTH_BYTES = 400을 적용하므로, 오버플로우 범위는 97에서 400바이트 사이입니다.

공격 벡터는 NFS 서버 포트(2049/TCP)를 통한 네트워크 접근이며, 유효한 Kerberos 티켓만 있으면 됩니다. 사전 인증은 필요하지 않습니다.

스택 레이아웃을 보면 왜 이 취약점이 치명적인지 명확해집니다.

[rbp - 0xc0]  rpchdr[0]
[rbp - 0xa0]  rpchdr[32]   ← memcpy 목적지 시작
[rbp - 0x40]  rpchdr[128]  ← 버퍼 끝 (96바이트)
[rbp - 0x28]  저장된 RBX   ← 오버플로우 시작
[rbp - 0x20]  저장된 R12
[rbp - 0x18]  저장된 R13
[rbp - 0x10]  저장된 R14
[rbp - 0x08]  저장된 R15
[rbp + 0x00]  저장된 RBP
[rbp + 0x08]  리턴 어드레스 ← 제어 흐름 하이재킹 목표

버퍼를 넘치게 하면 저장된 레지스터들을 지나 리턴 어드레스 까지 덮어쓸 수 있습니다. 제어 흐름을 완전히 장악하는 것이 가능한 구조입니다.

패치는 놀라울 정도로 단순합니다. 단일 경계 검사 하나를 추가하는 것으로 수정됐습니다.

if (oa_length > sizeof(rpchdr) - 8 * BYTES_PER_XDR_UNIT) {
    rpc_gss_log_debug("auth length %d exceeds maximum", oa_length);
    client->cl_state = CLIENT_STALE;
    return (FALSE);
}

이런 유형의 취약점은 보안 업계에서 "고전적이지만 치명적인" 것으로 분류됩니다. 경계 검사 누락이라는 단순한 실수가 원격 루트 권한 탈취로 이어지는 전형적인 패턴입니다. 문제는 이 "단순한 실수"를 AI가 무기화하는 데 4시간밖에 걸리지 않았다는 사실입니다.

Claude의 익스플로잇 개발 과정

3월 29일 오전 9:45(PDT)에 Claude에게 익스플로잇 개발을 요청했고, 오후 5:00에 작동하는 익스플로잇이 전달됐습니다. 벽시계 기준 약 8시간이지만, 인간이 자리를 비운 시간을 빼면 Claude의 실제 작업 시간은 약 4시간 입니다.

Claude는 두 가지 전혀 다른 전략의 익스플로잇을 완성했습니다.

전략 1: 멀티라운드 ROP + 셸코드 (15라운드)

각 라운드의 구조는 다음과 같습니다. NFS 서버와 새로운 Kerberos GSS 컨텍스트를 수립하고, 오버사이즈 크리덴셜 바디가 포함된 RPCSEC_GSS DATA 패킷을 전송합니다. 오버플로우로 리턴 어드레스를 ROP 가젯으로 덮어쓰고, ROP 체인이 커널 메모리에 데이터를 쓰거나 셸코드를 실행합니다. 마지막으로 kthread_exit()를 통해 깔끔하게 스레드를 종료시켜 커널 패닉을 방지합니다.

15라운드는 이렇게 진행됩니다.

• 라운드 1: pmap_change_prot()을 호출해 커널 BSS 섹션을 실행 가능하게 변경 (0x2000바이트, RWX 권한)
• 라운드 2-14: 432바이트 셸코드를 32바이트씩 점진적으로 커널 메모리에 기록 (13라운드)
• 라운드 15: 마지막 16바이트 기록 + BSS 진입점 주소로 점프

셸코드(432바이트)가 실행되면 kproc_create()로 새 프로세스를 생성하고, kern_execve('/bin/sh')로 프로세스 이미지를 교체한 뒤 리버스 셸로 연결합니다. 최종 결과는 이렇습니다.

sh: can't access tty; job control turned off
# id
uid=0(root) gid=0(wheel) groups=0(wheel)

전략 2: SSH 공개키 주입 (6라운드)

셸코드 대신 .ssh/authorized_keys에 공개키를 기록하는 전략입니다. 15라운드를 6라운드로 줄였고, 상세 내용은 비공개로 공유됐습니다.

두 전략 모두 첫 시도에 성공 했습니다.

Claude가 스스로 해결한 6가지 기술적 난제

이 익스플로잇이 인상적인 이유는 단순히 "코드를 짰다"는 것이 아닙니다. Claude가 개발 과정에서 마주친 예상치 못한 문제들을 스스로 진단하고 해결 했다는 점입니다.

1. 랩 셋업: FreeBSD VM에 NFS, Kerberos 인증, 취약한 커널 모듈을 직접 설정했습니다. FreeBSD가 CPU당 8개의 NFS 스레드를 생성하고 익스플로잇이 라운드당 1개의 스레드를 소모하므로 2개 이상의 CPU가 필요하다 는 것을 직접 파악한 점이 주목할 만합니다.

2. 스택 오프셋 보정: 초기 디스어셈블리 기반 오프셋(168바이트)이 실제와 32바이트 차이가 났습니다. Claude는 De Bruijn 패턴(위치 식별을 위한 순차 바이트 패턴)을 크리덴셜 바디로 전송하고, 커널 크래시 덤프를 분석해 실제 오프셋(200바이트)을 발견했습니다. 이것은 인간 보안 연구원이 사용하는 표준적인 디버깅 기법입니다.

3. 멀티패킷 셸코드 전달: 432바이트 셸코드가 단일 패킷의 400바이트 한계를 초과하는 문제를 만났습니다. Claude는 15라운드에 걸쳐 32바이트씩 점진적으로 전달하는 전략을 자체 설계했습니다.

4. 깨끗한 스레드 종료: 각 오버플로우가 NFS 커널 스레드를 하이재킹하므로, 이후 라운드를 위해 서버가 안정적으로 유지돼야 합니다. kthread_exit()를 사용해 커널 패닉 없이 스레드를 정리하는 방법을 적용했습니다.

5. 커널-유저랜드 전환: NFS 커널 스레드에서 직접 유저랜드 프로그램을 실행할 수 없는 제약이 있습니다. Claude는 kproc_create()로 새 프로세스를 생성하고, P_KPROC 플래그를 클리어한 뒤, kern_execve()로 유저 모드 실행을 가능하게 하는 시퀀스를 설계했습니다.

6. 디버그 레지스터 상속 버그: 자식 프로세스가 디버그 예외로 크래시하는 문제를 만났습니다. 원인은 커널 디버거(DDB)에서 상속된 오래된 디버그 레지스터였고, DR7 레지스터를 프로세스 포킹 전에 클리어하는 수정을 적용했습니다.

이 과정은 단순한 코드 생성이 아닙니다. 가설을 세우고, 실험하고, 결과를 분석하고, 전략을 수정하는 반복적 문제 해결 의 과정입니다. 이것이야말로 오랫동안 "인간만의 영역"으로 여겨졌던 부분입니다.

이전 사례와 무엇이 다른가

차이를 선명하게 보기 위해 이전 AI 보안 사례들과 비교해 보겠습니다.

• Google Big Sleep (2024.10): SQLite에서 스택 버퍼 언더플로우를 발견 했습니다. 익스플로잇은 작성하지 않았습니다.
• Claude Code Security (2026.02): 다수 오픈소스 프로젝트에서 500개 이상의 취약점을 발견 했습니다. 일부 PoC가 포함됐지만 원격 RCE는 아니었습니다.
• Mozilla 파트너십 (2026.03): Firefox에서 22개 취약점을 발견 하고, $4,000을 투입해 PoC 2건을 작성했습니다. 샌드박스 탈출에는 실패했습니다.
• MAD Bugs CVE-2026-4747 (2026.03): FreeBSD 커널에서 취약점을 발견하고, 완전한 원격 커널 익스플로잇 2종을 작성 했습니다. 둘 다 첫 시도에 원격 루트 셸을 획득했습니다.

패턴이 보이시나요? "발견"에서 "PoC 시도"로, 다시 "완전한 익스플로잇"으로, 18개월 만에 세 단계를 뛰어넘었습니다. 물론 중요한 맥락이 있습니다. FreeBSD 14.x에는 KASLR(커널 주소 공간 레이아웃 랜덤화)이 없습니다. 커널 주소가 고정적이고 예측 가능하며, 정수 배열에 대한 스택 카나리도 없습니다. 이러한 보안 완화 부재가 익스플로잇을 상당히 용이하게 만든 것은 사실입니다. 하지만 그렇다고 해서 ROP 체인 설계, 셸코드 작성, 커널-유저랜드 전환 같은 고급 기법을 AI가 수행했다는 사실의 의미가 줄어드는 것은 아닙니다.

방어와 공격, 동전의 양면

이번 사건이 실무에 미치는 영향은 양면적입니다.

방어 측면에서, 같은 기술을 활용하면 조직이 패치 전에 자사 시스템의 취약점을 AI로 검증할 수 있습니다. 공격자보다 먼저 취약점을 발견하고 수정하는 "비대칭적 이점"이 가능해집니다. Anthropic의 Claude Code Security가 이 방향을 이미 제품화한 것이기도 합니다.

공격 측면에서는, 보안 업계의 오래된 격언이 있습니다. "Patch Tuesday, Exploit Wednesday" — 패치가 나오면 다음 날 익스플로잇이 나온다는 뜻입니다. AI가 익스플로잇 개발을 4시간으로 단축시킨다면, 이 격언은 "Patch Tuesday, Exploit Tuesday Afternoon" 으로 바뀔 수 있습니다.

RSAC 2026에서 Kevin Mandia, Alex Stamos 등 보안 리더들은 이렇게 경고했습니다.

"향후 2년이 미칠 것이다."

AI가 위협 환경에 작동하는 익스플로잇을 쏟아내는 반면, 조직은 패치 속도를 따라잡지 못할 것이라는 전망입니다.

C/C++ 코드베이스의 위기 도 주목해야 합니다. FreeBSD, Linux 커널, Firefox 같은 레거시 C/C++ 코드베이스가 AI 공격의 우선 타겟이 될 것이라는 전망이 지배적입니다. 경계 검사 누락, 버퍼 오버플로우, use-after-free 같은 메모리 안전 문제는 C/C++의 구조적 약점이며, AI는 이런 패턴을 대규모로 탐지하는 데 탁월합니다. Rust로의 전환 압력이 더욱 강해질 수밖에 없는 이유입니다.

기존 SAST/DAST 도구 시장(Snyk, Checkmarx 등)에도 근본적인 도전이 제기됩니다. 패턴 매칭 기반의 전통적 보안 도구와 달리, LLM 기반 접근은 코드의 의미적 맥락 을 이해하고 복합적인 공격 경로를 추론할 수 있습니다. AI 보안 도구 시장의 재편이 가속화될 것으로 보입니다.

커뮤니티 반응, 경탄과 우려 사이

이 소식은 Hacker News 프론트페이지에서 95포인트, 31개 댓글을 기록했습니다. 같은 날 Claude Code 소스 유출 건(1,245포인트)에 상대적으로 묻혔지만, 보안 관점에서는 더 의미 있는 뉴스라는 평가가 있었습니다.

"발견과 익스플로잇은 다르다"는 지적 이 가장 먼저 나왔습니다. 최상단 댓글을 단 magicalhippo는 이렇게 썼습니다.

"Claude가 버그를 발견한 것이 아니라, CVE 설명을 받고 익스플로잇 프로그램을 작성한 것이다."

이에 대해 jsnell은 FreeBSD 보안 권고에 "Nicholas Carlini using Claude, Anthropic"으로 발견자 크레딧이 기재되어 있음을 반박했습니다. Claude가 발견 과정에도 참여했다는 뜻입니다.

FreeBSD의 보안 수준에 대한 비판 도 있었습니다. dheerajmp는 "FreeBSD 취약점을 찾는 데 Claude가 필요하지 않다. 맨눈으로도 된다"며 FreeBSD의 상대적으로 낮은 보안 수준을 꼬집었습니다. ptx는 FreeBSD 14.x에 KASLR이 없다는 점을 기술적으로 지적하며, 15.x에서의 상태를 질문했습니다.

반면 AI 보안 연구의 미래를 긍정적으로 본 시각 도 만만치 않았습니다. petcat은 "C 코드베이스는 AI 봇이 CVE를 사소하게 찾아낼 것"이라 단언했고, Cloudef는 "LLM이 정의된 목표를 가진 퍼징에 효과적"이라 평가했습니다. vinnymac은 1년간의 실무 경험을 바탕으로, 테스트 파일에 쓰기 권한을 제거하면 에이전트가 더 끈질기게 동작한다는 실무 팁까지 공유했습니다.

듀얼유스 우려 는 명확했습니다. sheepscreek은 "프론티어 LLM이 누구 손에나 들어가면 축복이자 저주"라며 양날의 검 문제를 지적했습니다.

한국어 커뮤니티(GeekNews 등)에서는 조사 시점 기준 이 뉴스가 직접 다뤄지지 않은 상태입니다. Claude Code 소스 유출 관련 게시물은 다수 있으나, CVE-2026-4747 익스플로잇 건은 아직 한국어로 보도되지 않았습니다.

Anthropic의 모순, 그리고 AI 보안의 다음 질문

이번 사건은 몇 가지 근본적인 질문을 던집니다.

첫째, Anthropic의 위치가 모순적입니다. Anthropic은 AI 안전을 핵심 가치로 내세우는 기업입니다. 그런데 자사 소속 연구원이 자사 모델로 공격적 커널 익스플로잇을 작성해 공개했습니다. Anthropic의 기존 정책에서 "자율적 사이버 공격" 능력은 ASL-3 이상의 안전 수준을 요구하는 트리거 중 하나였습니다. 물론 이번 사례는 인간 연구원의 감독 하에, 이미 패치된 취약점을 대상으로 수행됐습니다. 하지만 같은 능력이 악의적 사용자의 손에 들어가면 어떤 일이 벌어질지는 자명합니다.

둘째, KASLR이 있는 현대 OS에서도 가능할까요? 이번 익스플로잇은 KASLR이 없는 FreeBSD 14.x에서 수행됐습니다. 커널 주소가 고정적이라 ROP 가젯 주소를 예측할 수 있었습니다. 현대 Linux 커널은 KASLR, 스택 카나리, CFI(Control Flow Integrity) 등 다층 보호를 갖추고 있습니다. 동일한 성과가 가능한지는 다음 질문입니다. 그러나 AI가 이런 보호 기제의 우회 기법까지 발견해낸다면, 위협 수준은 급격히 상승합니다.

셋째, 듀얼유스 규제는 어디까지 가능한가요? Cisco의 2026 보안 보고서는 AI 보안의 듀얼유스 문제를 핵심 도전으로 지적합니다. 방어적 혁신을 늦추지 않으면서 유해한 사이버 사용 사례를 제한하기 어렵다는 분석입니다. 2026년 국제 AI 안전 보고서도 이를 핵심 리스크로 다루고 있으며, 미국 국방수권법(FY2026)은 국방부에 AI/ML 기술의 사이버보안 프레임워크 개발을 지시했습니다.

MAD Bugs 프로젝트는 4월 말까지 계속됩니다. 추가 취약점과 익스플로잇이 공개될 예정입니다. FreeBSD 커널보다 더 경화된 타겟에서의 성과가 나올지, AI가 KASLR 우회까지 해낼 수 있을지가 업계의 다음 관심사입니다.

한 가지는 확실합니다. AI가 버그를 찾는 시대는 이미 지났습니다. 우리는 이제 AI가 버그를 무기화하는 시대 의 초입에 서 있습니다. 방어자가 먼저 이 도구를 채택하느냐, 공격자가 먼저 활용하느냐에 따라 보안 환경의 판도가 결정될 것입니다. "향후 2년이 미칠 것"이라는 RSAC 보안 리더들의 경고가 과장이 아닐 수 있습니다.