CVE-2026-5281 Chrome WebGPU 제로데이와 샌드박스 경계

CVE-2026-5281의 Dawn WebGPU UAF 취약점과 Chrome 프로세스 격리, 긴급 패치 및 엔터프라이즈 대응 정책을 정리한다.

2026-08-14 · 최초 발행 2026-05-01

실제 악용이 확인된 Dawn WebGPU 취약점

Google은 2026년 4월, 실제 야생 악용이 확인된 Chrome 제로데이 CVE-2026-5281의 긴급 보안 패치를 배포했다. 이 문제는 Chrome의 WebGPU 구현체인 Dawn 레이어에 존재하는 Use-After-Free(UAF) 결함이다. 렌더러 프로세스를 장악한 공격자는 이를 이용해 임의 코드 실행을 시도할 수 있다.

CVE-2026-5281은 CVSS 기준 고위험(High)으로 분류됐다. Google 발표에 따르면 취약점은 오픈소스 크로스플랫폼 WebGPU 라이브러리인 Dawn에서 발생한다. 영향 버전은 Windows/macOS에서 Chrome 146.0.7680.178 미만, Linux에서 146.0.7680.177 미만이다.

미국 사이버보안·인프라보안국(CISA)은 2026년 4월 1일 이 취약점을 KEV(Known Exploited Vulnerabilities) 카탈로그에 등재했고, 연방 민간 행정부처(FCEB)에 2026년 4월 15일까지 패치를 적용하도록 요구했다. KEV 등재는 해당 취약점이 이미 실제 공격에 쓰였음을 공식적으로 확인하는 조치다.

공격은 악성 HTML 페이지 방문을 출발점으로 삼는다. 페이지가 Dawn WebGPU 레이어의 UAF를 유발하면 렌더러 프로세스 안에서 코드 실행이 가능해질 수 있다. 이후 공격자는 별도의 샌드박스 이스케이프 취약점을 연결해 운영체제 수준 권한 획득을 시도한다.

2026년에 실제 악용이 확인돼 패치된 Chrome 제로데이는 다음과 같다.

CVE 발견 시기 취약점 유형 영향 컴포넌트
CVE-2026-2441 2026년 2월 메모리 버그 폰트 처리
CVE-2026-3909 2026년 3월 범위 초과 쓰기 Skia 그래픽 라이브러리
CVE-2026-3910 2026년 3월 부적절한 구현 V8 JavaScript/WebAssembly 엔진
CVE-2026-5281 2026년 4월 Use-After-Free Dawn WebGPU 레이어

Blink와 WebGPU 경계에서 나타나는 메모리 결함

Blink는 과거 WebKit에서 갈라져 나온 Chrome의 렌더링 엔진이며, Dawn은 그 위에서 WebGPU 호출을 처리한다. 렌더링과 GPU 리소스 수명 관리가 만나는 구조는 여러 종류의 메모리 안전성 문제를 만들 수 있다.

해제된 GPU 리소스에 다시 접근하는 UAF

UAF는 메모리가 해제된 뒤에도 해당 영역을 가리키는 포인터가 남아 접근이 계속되는 결함이다. CVE-2026-5281이 이 유형이다. Dawn WebGPU 레이어에서 GPU 리소스 객체가 해제된 후 렌더러 코드가 같은 포인터를 사용하면, 공격자는 힙 스프레이(Heap Spray) 등의 기법으로 해제된 메모리 영역에 악성 데이터를 배치하고 코드 실행을 유도할 수 있다.

입력 크기 검증 실패와 범위 초과 쓰기

렌더링 파이프라인에서 입력 데이터 크기 검증이 빠지면 인접 메모리를 덮어쓰는 버퍼 오버플로우가 발생할 수 있다. Skia 그래픽 라이브러리의 CVE-2026-3909는 범위 초과 쓰기(Out-of-bounds Write) 취약점으로 이 계열에 속한다. 공격자는 오버플로우를 통해 함수 포인터나 반환 주소를 조작해 코드 흐름을 탈취할 수 있다.

객체 타입을 잘못 해석하는 V8 문제

타입 컨퓨전(Type Confusion)은 V8 JavaScript 엔진에서 자주 나타나는 유형이다. 엔진이 객체 타입을 잘못 판단해 호환되지 않는 방식으로 메모리에 접근하는 것이 핵심이다. 배열이 아닌 객체를 배열처럼 처리하거나 정수를 포인터로 다루는 경우가 여기에 해당한다. 조작된 객체를 이용하면 범위 초과 읽기·쓰기를 거쳐 임의 메모리 접근 능력을 확보할 수 있다.

JIT 최적화의 잘못된 가정

V8의 JIT(Just-In-Time) 컴파일러는 반복 실행되는 JavaScript 함수를 최적화된 기계어로 바꾼다. 이 과정은 입력 타입에 관한 가정을 바탕으로 부수 효과(Side Effect)를 분석한다. 분석이 부정확하면 잘못된 코드가 만들어지거나 보안 검사를 우회하는 최적화가 적용될 수 있다. 특수하게 만든 JavaScript로 JIT 컴파일러를 오도하면 렌더러 프로세스 내 임의 코드 실행으로 이어질 수 있다.

렌더러 침해를 제한하는 Chrome 프로세스 모델

Chrome은 렌더러가 침해되더라도 운영체제와 사용자 데이터 접근을 제한하도록 구성돼 있다. 핵심 방어선은 권한이 다른 프로세스의 분리와 사이트 격리다.

Mojo IPC (신뢰 불가 메시지검증)Mojo IPCWebGPU / Dawn APIWebGPU / Dawn APIOS 그래픽 드라이버 호출직접 파일시스템/네트워크 접근불가권한 통제 대리 접근사용자 (브라우저 UI)브라우저 프로세스 (높은 권한)렌더러 프로세스 (낮은 권한샌드박스)렌더러 프로세스 (사이트 B)GPU 프로세스네트워크 서비스 프로세스운영체제 / 하드웨어파일시스템 / OS 리소스

권한이 다른 브라우저와 렌더러 프로세스

브라우저 프로세스는 높은 권한으로 운영체제와 직접 상호작용한다. 웹 콘텐츠를 다루는 렌더러 프로세스는 낮은 권한의 샌드박스 안에서 실행되므로 파일 시스템이나 네트워크에 직접 접근할 수 없다. 렌더러의 외부 자원 요청은 IPC를 거쳐 브라우저 프로세스로 전달된다.

출처를 분리하는 사이트 격리

Chrome 67부터 기본 활성화된 사이트 격리는 서로 다른 사이트 콘텐츠를 별도의 렌더러 프로세스에서 처리하도록 강제한다. Spectre 같은 사이드 채널 공격이나 교차 사이트 데이터 탈취를 막기 위한 경계다. 각 렌더러는 단일 출처(origin)의 콘텐츠만 처리하도록 제한되며, 브라우저 프로세스는 렌더러가 보낸 IPC 요청이 해당 출처에 허용된 범위인지 계속 검증한다.

신뢰하지 않는 렌더러와 Mojo IPC

렌더러와 브라우저 프로세스의 통신에는 Mojo IPC 프레임워크가 쓰인다. Chrome은 렌더러 프로세스를 신뢰하지 않는다는 원칙을 전제로 한다. 렌더러가 Mojo 호출로 요청을 보내면 브라우저는 요청 범위를 독립적으로 검증한 뒤 처리한다. 따라서 렌더러 RCE가 성립하더라도 브라우저 프로세스나 운영체제 수준 권한을 얻으려면 추가 샌드박스 이스케이프 취약점이 필요하다.

GPU 프로세스까지 이어지는 경로

CVE-2026-5281과 관련된 GPU 프로세스는 별도로 분리된다. 렌더러는 WebGPU API 호출을 Dawn 레이어를 거쳐 GPU 프로세스로 전달한다. GPU 프로세스는 렌더러보다 높은 권한을 가지므로, Dawn 레이어의 UAF가 GPU 프로세스 장악으로 이어지면 샌드박스 이스케이프 가능성이 생긴다. 이것이 단순 렌더러 RCE보다 더 위험한 지점이다.

긴급 패치가 배포되는 경로

제로데이 패치는 일반 보안 업데이트와 다른 긴급 트랙을 따른다.

YesNo취약점 발견/신고실제 악용확인?긴급 패치 개발(hours~days)일반 패치 사이클(주간 릴리스)내부 보안 검토스테이블 채널 배포(Chrome 업데이트 서버)사용자 자동 업데이트(백그라운드 다운로드)엔터프라이즈관리 채널 배포브라우저 재시작 적용GPO/MDM 강제업데이트 정책CISA KEV 등재(실제 악용 공식 확인)FCEB 기관 의무패치 데드라인

Google은 Chrome 업데이트를 Stable, Beta, Dev, Canary 채널로 제공한다. 제로데이 긴급 패치는 Stable 채널로 직접 배포되며, 자동 업데이트 메커니즘이 백그라운드에서 패치를 내려받는다. 브라우저를 재시작하거나 chrome://settings/help에서 수동 업데이트를 확인하면 최신 버전을 즉시 적용할 수 있다.

CVE-2026-5281 대응에서는 Chrome 146.0.7680.177/178(Windows/macOS) 및 146.0.7680.177(Linux)을 통해 총 21개의 취약점이 수정됐다. 이 가운데 실제 악용이 확인된 유일한 제로데이는 CVE-2026-5281이었다.

패치 직후에는 취약점의 기술적 세부 사항이 제한된다. 다수 사용자가 업데이트하기 전 상세 익스플로잇 정보가 공개되면 패치되지 않은 시스템을 향한 추가 공격이 가능해지기 때문이다. 이는 제로데이 대응에서 책임 있는 공개(Responsible Disclosure)를 이어가는 방식이다.

조직에서 패치 적용을 앞당기는 방법

조직에서는 수천 대의 기기가 같은 취약 Chrome 버전을 실행할 수 있다. 개인 사용자의 업데이트 방식만으로는 부족하며, 브라우저 정책과 자산 상태를 함께 관리해야 한다.

Chrome Enterprise는 GPO(Group Policy Object), MDM(Mobile Device Management), Chrome Browser Cloud Management를 통해 브라우저 동작을 중앙에서 통제할 수 있다. 제로데이 발생 시에는 다음 정책을 검토할 수 있다.

RelaunchNotification 및 RelaunchNotificationPeriod 정책으로 업데이트 뒤 재시작을 강제하는 기간을 설정할 수 있다. 긴급 취약점 상황에서는 이 기간을 최소화해 패치 적용 속도를 높일 수 있다.

WebGPUEnabled 정책은 WebGPU 기능을 비활성화할 수 있다. CVE-2026-5281은 Dawn WebGPU 레이어에 영향을 주므로, 패치 적용 전 WebGPU 비활성화는 공격 면적을 줄이는 임시 조치가 될 수 있다. 다만 WebGPU를 쓰는 애플리케이션 기능은 중단될 수 있다.

ExtensionInstallBlocklist 및 허용 목록 정책은 불필요한 확장 프로그램을 막아 추가 공격 경로를 제한한다.

Chrome Browser Cloud Management의 보고 기능으로는 조직 내 Chrome 버전 분포를 실시간으로 확인할 수 있다. 취약 버전이 남아 있는 기기와 재시작이 끝나지 않아 패치가 적용되지 않은 기기를 식별해 추적하는 일이 핵심이다. 자산 관리 도구 또는 EDR(Endpoint Detection and Response) 솔루션과 연동하면 조직 전체의 패치 현황을 일원화할 수 있다.

브라우저를 단일 방어선으로 보는 접근에는 한계가 있다. Zero Trust 아키텍처는 브라우저 침해를 전제로 사용자 행동 분석, 네트워크 마이크로 세그멘테이션, 최소 권한 원칙으로 피해 범위를 제한한다. 격리 브라우저(Remote Browser Isolation, RBI)를 도입하면 실제 콘텐츠 처리가 클라우드에서 이뤄지므로, 제로데이 익스플로잇이 성공해도 엔드포인트 침해를 방지할 수 있다.

CVE-2026-5281은 다층 샌드박스가 단일 취약점으로 시스템 전체가 무너지는 일을 어렵게 만든다는 점과, GPU 프로세스 경계의 취약점이 샌드박스 이스케이프로 이어질 수 있다는 점을 함께 보여준다. 개인 사용자는 자동 업데이트 뒤 브라우저를 재시작해야 하며, 기업 담당자는 정책을 이용해 패치 적용을 앞당기고 필요 시 WebGPU 비활성화를 검토할 수 있다. 2026년에 네 번째 Chrome 제로데이가 실제 악용된 상황에서 브라우저 보안은 지속적으로 관리해야 할 대상이다.

Sources

크롬 제로데이WebGPU브라우저 보안샌드박스취약점 대응Chrome Enterprise