Chrome Dawn WebGPU UAF 제로데이와 GPU 프로세스 샌드박스 방어

Dawn의 객체 수명 문제가 GPU 프로세스까지 이어질 때

2026년 4월 Google은 Chrome의 WebGPU 구현 엔진 Dawn에서 발생한 Use-After-Free(UAF) 제로데이 CVE-2026-5281을 긴급 패치했다. 실전 공격 사용이 확인됐고, CISA는 같은 날 이를 Known Exploited Vulnerabilities 목록에 올리면서 미국 연방기관에 4월 15일까지 패치를 적용하도록 했다. 2026년 들어 Chrome의 네 번째 제로데이 패치였으며, Edge·Brave·Opera·Vivaldi처럼 Chromium을 기반으로 한 브라우저도 같은 영향권에 있다.

이 취약점은 브라우저 렌더러에서 끝나는 문제가 아니다. WebGPU 요청이 Dawn Wire를 지나 GPU 프로세스에서 처리되는 구조 때문에, 객체 수명 관리 결함은 GPU 프로세스의 코드 실행으로 연결되는 교두보가 될 수 있다.

해제된 메모리를 다시 참조하는 UAF

UAF는 힙(heap) 메모리를 해제한 뒤에도 그 주소를 담은 포인터를 다시 사용하는 결함이다. C/C++에서 free() 또는 delete가 호출되면 할당 블록은 반환되지만, 포인터 변수는 기존 주소를 계속 보유할 수 있다. 이렇게 유효하지 않은 주소를 가리키는 포인터가 댕글링 포인터(dangling pointer)다.

악용은 해제된 객체를 만들고, 그 자리를 공격자가 제어하는 데이터로 재점유한 뒤, 취약한 코드가 이전 포인터를 따라가도록 유도하는 순서로 진행된다. 이때 타입 혼동(Type Confusion)이 생기면 프로그램은 공격자가 채운 메모리를 원래 객체로 오인해 처리할 수 있다.

// 취약 코드 패턴 (C++ 의사코드)
WGPUObject* obj = createWebGPUObject();
// ... 이벤트 콜백 등록, obj 내부 참조 유지
releaseWebGPUObject(obj);    // 해제
// ... 공격자가 같은 크기 힙 슬롯을 악의적 데이터로 재점유
obj->dispatch();             // UAF: 이미 오염된 메모리 호출

힙 스프레이(heap spray), tcmalloc/PartitionAlloc 버킷 예측, 타이밍 기반 경쟁 조건은 해제된 슬롯을 다시 차지할 가능성을 높이는 데 사용된다. Dawn에서는 WebGPU 커맨드 버퍼와 GPU 오브젝트의 수명 관리가 비동기로 이뤄진다. 버퍼, 텍스처, 렌더 파이프라인, 커맨드 버퍼가 서로 참조하는 상태에서 CPU 쪽 객체는 해제됐지만 GPU 큐에는 아직 해당 리소스를 쓰는 작업이 남아 있을 수 있다.

특히 JavaScript에서 gpuDevice.queue.submit()으로 CommandBuffer를 빠르게 연속 제출하고 해제하면, Dawn이 렌더러 프로세스에서 추적하던 비동기 실행 상태와 GPU 작업 큐의 처리 상태가 어긋날 수 있다. 참조 카운팅 객체의 원시 포인터를 보관하면서 다른 위치의 참조가 계속 유지된다고 가정하는 패턴이 깨지면, 이미 파괴된 CommandBuffer를 가리키는 댕글링 포인터가 GPU 커맨드 큐에 남는다. 이후 비동기 콜백이나 GPU 파이프라인이 이 포인터를 역참조하면 메모리 손상으로 이어질 수 있다.

CVE-2026-5281이 영향받는 경로

항목	내용
CVE ID	CVE-2026-5281
유형	Use-After-Free (CWE-416)
심각도	High
영향 버전	Chrome 146.0.7680.177/178 미만
패치 버전	146.0.7680.177(Linux), 146.0.7680.178(Win/macOS)
공개 일자	2026년 4월 1일
KEV 등재	CISA KEV 2026년 4월 1일

Dawn은 Chrome이 WebGPU API 호출을 Vulkan, Metal, D3D12 같은 플랫폼별 GPU 명령으로 바꾸는 C++ 라이브러리다. 렌더러 프로세스에서 JavaScript가 GPUDevice.createBuffer() 같은 WebGPU API를 호출하면 Dawn Wire 클라이언트가 요청을 직렬화해 GPU 프로세스로 보낸다. GPU 프로세스의 Dawn Wire 서버는 이를 역직렬화한 뒤 Dawn Native에 전달하고, 그 결과 실제 GPU 하드웨어 명령이 만들어진다.

CVE-2026-5281은 이 GPU 오브젝트 수명 관리 경로에 존재하는 UAF다. 공격자는 먼저 렌더러 프로세스를 장악한 다음, 조작된 HTML 페이지로 GPU 프로세스의 Dawn 객체가 해제 뒤에도 참조되도록 유도한다. 성공하면 GPU 프로세스 컨텍스트에서 임의 코드 실행(Remote Code Execution, RCE)이 가능해진다.

완전한 시스템 침해에는 추가 단계가 필요하다.

⤢✕

렌더러 프로세스는 가장 낮은 신뢰 수준의 샌드박스에서 동작한다. 따라서 공격자는 렌더러 탈출, GPU 프로세스 침해, OS 수준 권한 상승으로 이어지는 다단계 체인을 구성해야 한다. 2026년 상반기에 CVE-2026-4676, CVE-2026-5281, CVE-2026-5284, CVE-2026-6310 등 Dawn 관련 UAF가 연속 등장했다는 점은 WebGPU 스택이 공격 그룹의 집중 대상이 되고 있음을 보여준다.

프로세스 분리가 만드는 방어 경계

Chrome은 하나의 브라우저 프로세스에 모든 기능을 모으지 않는다. 탭 하나의 침해가 전체 세션에 번지는 범위를 줄이기 위해 역할과 권한을 분리한 다중 프로세스 모델을 사용한다.

⤢✕

브라우저 프로세스(Browser Process)는 UI, 탭, IPC를 조율하고 네트워크와 파일시스템 관련 작업을 담당한다. 상대적으로 높은 OS 권한을 가진다.

렌더러 프로세스(Renderer Process)에서는 Blink와 V8이 HTML·CSS·JavaScript를 처리한다. Site Isolation이 활성화되면 도메인별로 별도 렌더러가 배정된다. Windows에서는 Untrusted 무결성 수준, Linux에서는 seccomp-BPF + namespace 격리, macOS에서는 Seatbelt sandbox profile이 이 프로세스에 적용된다.

GPU 프로세스(GPU Process)는 렌더러가 3D API에 직접 접근하지 못하게 하는 중간 계층이다. 렌더러는 WebGL·WebGPU 호출을 직렬화해 공유 메모리의 커맨드 버퍼에 넣고, GPU 프로세스가 이를 소비해 Vulkan·Metal·D3D12 같은 플랫폼 API를 호출한다. GPU 프로세스의 샌드박스는 렌더러보다 느슨한 편이다. CVE-2026-5281 같은 취약점이 GPU 프로세스를 RCE의 교두보로 삼을 수 있는 이유다.

Site Isolation은 서로 다른 오리진(Origin)의 콘텐츠가 하나의 렌더러 프로세스를 함께 쓰지 못하도록 한다. Spectre·Meltdown 계열 사이드채널 공격에서 크로스-사이트 데이터 유출을 막기 위해 도입됐다. 이 격리가 없다면 bank.com과 malicious.com이 같은 렌더러에서 실행될 수 있고, UAF 하나가 다른 사이트의 메모리 접근으로 이어질 수 있다.

권한이 필요한 파일 접근, 네트워크 연결, 쿠키 읽기 요청은 렌더러에서 브라우저 프로세스로 직접 전달되지 않고 Mojo IPC 경계를 통과한다. 브라우저 프로세스는 요청을 엄격히 검증해야 한다. IPC 메시지 처리 자체에 결함이 있으면 브라우저 프로세스 침해로 이어질 수 있으므로, IPC 핸들러 검토는 Chrome 보안 팀의 우선 과제다.

WebGPU 경계에서 넓어지는 공격 면

WebGPU는 OpenGL ES 기반의 WebGL보다 저수준 GPU 제어 기능을 JavaScript에 제공한다. 기능이 넓어진 만큼 검증해야 할 경계도 늘어난다.

⤢✕

Dawn Wire의 직렬화·역직렬화 경계는 특히 민감하다. 오브젝트 핸들의 유효성 검증이 충분하지 않으면 UAF 또는 타입 혼동으로 연결될 수 있다. 비동기 GPU 작업에서는 렌더러의 Dawn Wire 클라이언트 객체, GPU 커맨드 버퍼에 담긴 직렬화된 표현, GPU 프로세스의 Dawn Wire 서버 객체, 네이티브 GPU 리소스가 서로 다른 수명으로 존재한다. 한 표현이 해제된 뒤 다른 표현의 작업이 큐에 남아 있으면 그 불일치 자체가 공격 표면이 된다.

GPU 드라이버도 공격 면에 속하며, 드라이버 결함은 커널 모드 코드 실행을 허용할 수 있다. Chrome 팀은 잘못된 입력이 GPU 프로세스에 도달하기 전에 렌더러 수준에서 WebGPU 명세 준수 여부를 검증하는 방향을 택하고 있다. GPU 프로세스에는 시스템 콜 필터를 추가 적용해 드라이버 취약점의 악용 경로를 제한하려 한다.

PartitionAlloc과 MiraclePtr의 역할

PartitionAlloc은 Chrome이 개발한 힙 할당자다. 타입과 크기에 따라 힙을 격리된 파티션으로 나눠 배치하므로, 서로 다른 파티션의 메모리가 섞이지 않는다. 한 파티션에서 일어난 UAF가 다른 파티션 데이터를 오염시키기 어려워진다. 공격자가 힙 스프레이로 슬롯을 재점유하려면 같은 파티션과 버킷 안에서 정밀하게 조작해야 하므로 난도가 높아진다.

MiraclePtr(BackupRefPtr)은 UAF 익스플로잇을 줄이기 위해 도입된 스마트 포인터 시스템이다. 원시 포인터 T* 대신 raw_ptr<T>를 쓰고, PartitionAlloc의 참조 카운트 지원을 활용한다.

raw_ptr<T>가 생성되면 PartitionAlloc은 해당 할당 블록의 숨겨진 참조 카운트를 늘린다. 포인터가 파괴되거나 수정되면 카운트는 줄어든다. free() 호출 시 참조 카운트가 0이 아니면 실제 메모리 해제를 지연한다. 이후 댕글링 포인터 접근이 발생하면 독립된 격리 공간의 데이터를 만나게 되어 익스플로잇이 성립하지 않는다.

Google은 2024년 기준으로 MiraclePtr이 권한 있는 프로세스(렌더러 제외)의 UAF 취약점 57%를 효과적으로 완화했다고 보고했다. 렌더러 프로세스는 메모리 5.5~8% 증가라는 성능 오버헤드 우려로 초기 적용 대상에서 제외됐지만, 2026년 현재 적용 범위 확대가 진행 중이다.

CVE-2026-5281이 MiraclePtr을 우회한 이유는 Dawn 코드 일부가 아직 raw_ptr<T> 전환을 끝내지 않았기 때문으로 분석된다. 이 취약점이 수정된 Chrome 147에서는 해당 코드 경로의 raw_ptr<T> 적용이 확대됐다.

신규 컴포넌트에는 Rust도 점진적으로 도입되고 있다. Rust의 컴파일 타임 소유권 시스템은 UAF, 이중 해제, 경쟁 조건을 언어 수준에서 막는다. 다만 수천만 줄에 이르는 기존 C++ 코드를 단기간에 바꾸기는 현실적으로 어렵기 때문에, MiraclePtr 같은 C++ 수준의 완화책이 함께 사용된다.

패치 운영과 방어 설계의 과제

Chrome은 146.0.7680.178(Windows/macOS) 또는 146.0.7680.177(Linux) 이상으로 업데이트해야 한다. Edge, Brave, Opera, Vivaldi도 상류 패치가 배포되는 시점에 업데이트가 필요하다.

기업 환경에서는 Chrome 엔터프라이즈 정책으로 자동 업데이트를 강제하거나 SCCM·Intune 같은 패치 관리 솔루션, Google Chrome Enterprise 관리 콘솔 또는 MDM(Mobile Device Management)을 통해 24시간 이내 배포를 목표로 삼아야 한다. Chromium 기반 브라우저는 각 벤더가 상류 Chromium 픽스를 반영하는 시점을 별도로 확인해야 한다. KEV 등재 취약점은 이미 실전 공격이 확인된 상태이므로 일반 패치 주기를 기다리는 대응은 위험하다.

패치 적용이 어려운 기간에는 WebGPU를 사용하지 않는 환경에서 --disable-webgpu 플래그로 WebGPU를 임시 비활성화하거나, 기업 정책으로 특정 사이트에서만 WebGPU를 허용하는 WebGPU 허용 목록(allowlist) 정책을 적용할 수 있다. 의심스러운 웹 콘텐츠를 격리하는 Remote Browser Isolation(RBI) 솔루션도 단기 완화책으로 고려할 수 있다. WebGPU API의 비정상 호출 패턴, GPU 프로세스의 비정상 메모리 사용량, 렌더러에서 GPU 프로세스로 향하는 과도한 IPC 트래픽은 점검 대상이며, EDR 솔루션에는 Chrome GPU 프로세스의 예외적 행동을 모니터링하는 탐지 규칙을 추가할 필요가 있다.

CVE-2026-5281은 다중 프로세스 샌드박스가 피해 반경을 줄여도 완전한 방패는 아니라는 점을 드러낸다. GPU 프로세스는 렌더러보다 높은 권한으로 실행되며, 이 프로세스 침해는 더 많은 시스템 리소스 접근으로 이어질 수 있다. GPU 프로세스에 렌더러 수준에 준하는 시스템 콜 필터를 적용하고, Dawn Wire 역직렬화 계층의 퍼징 테스트를 강화하며, 중요한 GPU 오브젝트 수명 관리에 raw_ptr<T>를 전면 적용하는 접근이 필요하다.

WebGPU처럼 복잡한 멀티미디어 API가 브라우저에 계속 추가될수록 공격 면도 넓어진다. 메모리 안전 언어로의 전환, 퍼징 자동화, MiraclePtr 같은 C++ 수준의 완화책은 함께 유지돼야 할 브라우저 보안 과제다.