Chrome V8 CVE-2026-11645: JIT 범위 초과 쓰기와 브라우저 샌드박스 대응

2026년 6월 구글은 Chrome 브라우저의 V8 JavaScript 엔진에서 야생 악용이 확인된 제로데이 CVE-2026-11645를 긴급 패치했다. 특수 제작된 HTML 페이지 하나로 샌드박스 내부의 임의 코드 실행이 가능한 취약점이며, CVSS 8.8(High)에 해당한다. 2026년 들어 다섯 번째 Chrome 제로데이 패치다.

보안 연구자 "303f06e3"은 2026년 4월 27일 이 취약점을 발견해 보고했고, 5만 5천 달러의 버그 바운티를 수령했다.

JIT 최적화가 배열 경계를 잘못 판단할 때

V8은 JavaScript 코드를 실행 중 네이티브 기계어로 변환하는 JIT(Just-In-Time) 컴파일러를 핵심 구성 요소로 둔다. Turbofan/Maglev 같은 최적화 컴파일러는 타입 피드백을 바탕으로 메모리 접근 패턴을 추론한다. 이 과정의 특정 엣지 케이스에서는 배열 인덱스 범위 검사가 제거되거나 우회될 수 있다.

CVE-2026-11645의 핵심은 JIT 최적화 단계에서 일어나는 OOB(Out-of-Bounds) 메모리 접근이다. 공격자가 정밀하게 설계한 JavaScript를 실행하면 Turbofan이 잘못된 범위를 추론하고, 배열 객체 경계 바깥의 메모리를 읽거나 쓸 수 있다.

⤢✕

성능을 위한 speculative optimization(추론적 최적화)은 JIT에 필요하다. 다만 추론이 틀렸을 때 deoptimization(역최적화) 없이 OOB 접근이 발생할 수 있다는 점이 구조적 위험으로 남는다.

렌더러 격리가 막는 범위와 한계

Chrome은 다중 프로세스 격리 모델을 사용한다. 낮은 권한으로 동작하는 렌더러 프로세스는 브라우저 프로세스와 IPC(Inter-Process Communication)를 통해서만 통신한다.

⤢✕

이 취약점으로 가능한 것은 렌더러 프로세스의 V8 엔진 내부 임의 코드 실행이며, 그 자체가 샌드박스 탈출을 뜻하지는 않는다. 그러나 렌더러에서의 코드 실행은 샌드박스 탈출 취약점과 체이닝될 수 있고, 완전한 시스템 장악으로 이어질 수 있어 심각도가 높다.

격리 계층은 다음과 같이 구성된다.

Site Isolation: 웹사이트 출처마다 별도 렌더러 프로세스를 할당한다.
Sandboxing: OS 수준에서 시스템 콜을 필터링한다. Linux는 Seccomp, Windows는 AppContainer, macOS는 Seatbelt를 사용한다.
IPC Validation: 브라우저 프로세스가 렌더러 요청의 무결성을 검사한다.

메모리 손상 이후에 남는 방어선

OOB 취약점이 실제 익스플로잇으로 발전하려면 메모리 접근부터 샌드박스 탈출까지의 단계를 통과해야 한다.

단계	기법	방어 메커니즘
OOB 읽기/쓰기	배열 경계 외 메모리 접근	Pointer Compression, Heap Sandbox
정보 유출	ASLR 우회를 위한 주소 노출	V8 Pointer Cage
가짜 객체 조작	타입 혼동으로 네이티브 코드 실행	Type Confusion 탐지
샌드박스 탈출	브라우저 프로세스 IPC 취약점 체이닝	MojoJS Fuzzing

V8 Heap Sandbox는 V8 힙 바깥의 포인터를 직접 역참조하지 못하도록 설계됐다. Pointer Compression은 64비트 주소 공간을 32비트 오프셋으로 압축해 포인터 위조 공격의 효용을 낮춘다.

그럼에도 CVE-2026-11645의 야생 악용이 확인됐다는 사실은 이러한 방어를 우회했거나, 다른 취약점과 체이닝하는 기법이 사용됐을 가능성을 시사한다.

엔진별 메모리 안전 접근 방식

브라우저/엔진	메모리 안전 언어	JIT 보호	샌드박스
Chrome / V8	C++ (일부 Rust 도입)	Turbofan Hardening, V8 Heap Sandbox	Seccomp, AppContainer
Firefox / SpiderMonkey	C++, Rust (Stylo, Oxidation)	WarpMonkey, Wasm GC	RLBox (Wasm 격리)
Safari / JavaScriptCore	C++, Swift	LLINT, DFG, FTL	macOS Sandbox
Edge / V8 기반	Chrome 동일	Chrome 동일	Enhanced Security Baseline

Firefox의 RLBox는 서드파티 라이브러리를 WebAssembly 샌드박스로 격리하는 접근이다. Chrome 역시 메모리 안전 언어 도입 로드맵에 따라 신규 컴포넌트의 Rust 적용을 점진적으로 확대하고 있다.

Chrome 제로데이에서 드러난 공격 경로

2026년 6월 기준으로 Chrome에서 야생 악용이 확인된 제로데이는 다섯 건이다.

⤢✕

이 기간의 패턴은 V8 엔진과 렌더러가 집중 공격 대상이 되고 있다는 점이다. 다섯 건 중 세 건은 V8 또는 렌더러 취약점이며, 공격자들은 단독 취약점보다 둘 이상의 취약점을 연결하는 체이닝 패턴을 늘리고 있다.

CVE-2026-11645는 4월 27일 발견된 뒤 약 6주 만에 패치가 배포됐다.

야생 악용 확인 시 패치 우선순위

구글의 Chrome 보안 대응 체계에서는 야생 악용이 확인되면 최우선 대응(P0)으로 분류한다.

⤢✕

패치 버전: Chrome 149.0.7827.102/103 (Windows/Mac), 149.0.7827.102 (Linux)

관리형 기기에서 업데이트를 강제하는 방법

기업 환경에서는 자동 업데이트를 제어하는 경우가 많아 제로데이 패치가 늦어질 수 있다. 긴급 배포를 위해 GPO 또는 MDM의 업데이트 정책을 적용할 수 있다.

Windows Group Policy (GPO) 설정:

Computer Configuration → Administrative Templates → Google → Google Chrome → 업데이트
→ "자동 업데이트 허용" 활성화
→ "업데이트 재정의" → "항상 업데이트 허용"

Google Admin Console (ChromeOS/관리형 기기):

기기 → Chrome → 업데이트 설정
→ "자동 업데이트 사용" 켜기
→ "업데이트 채널" → Stable
→ "업데이트 기간 제한" 해제 (긴급 시)

macOS MDM (Jamf 등):

defaults write com.google.Chrome.plist AutoUpdateCheckPeriodMinutes -int 60
defaults write com.google.Chrome.plist DisableAutoUpdateChecks -bool false

IOC와 렌더러 행위로 탐지 범위를 넓히기

야생 악용이 확인된 취약점은 IOC(Indicators of Compromise)를 기반으로 탐지할 수 있다.

네트워크 측면에서는 Snort/Suricata 규칙을 이용한 비정상 JavaScript 난독화 패턴, 단발 방문 뒤 실행 파일을 내려받는 드라이브-바이 다운로드 패턴, 렌더러 프로세스의 비정상 아웃바운드 연결을 확인한다.

엔드포인트에서는 chrome.exe의 자식 프로세스로 cmd.exe, powershell.exe, wscript.exe가 생성되는지 탐지한다. 렌더러 프로세스의 파일 시스템 쓰기 시도와 Chrome 힙 외부 실행 시도도 감시 대상이다.

SOC Prime / MITRE ATT&CK 매핑은 다음과 같다.

T1203: Exploitation for Client Execution
T1059.007: JavaScript 실행
T1055: Process Injection (샌드박스 탈출 후)

취약점 관리 체계에 연결되는 보안 원칙

CVE-2026-11645는 소프트웨어 취약점 관리의 여러 개념과 맞닿아 있다.

취약점 유형은 CWE-787 Out-of-Bounds Write로 분류되며, 정보 유출 단계의 CWE-125 Out-of-Bounds Read 및 관련 클래스인 CWE-416 Use-After-Free와 함께 검토할 수 있다.

보안 아키텍처 관점에서는 렌더러 프로세스 샌드박스가 최소 권한 원칙(Least Privilege)의 사례다. V8 Heap Sandbox, 프로세스 샌드박스, OS 보안 계층은 심층 방어(Defense in Depth)를 이룬다. 취약점 공시 정책으로는 구글 Project Zero의 90일 공시 정책이 연결된다.

패치 관리는 취약점 식별, 위험 평가, 패치 우선순위 결정, 테스트, 배포, 사후 검증의 흐름으로 운영한다. 야생 악용이 확인된 이번 사례에서는 업데이트 강제 정책과 렌더러 이상 행위 탐지를 함께 적용해야 한다.