| 항목 | 내용 |
|---|---|
| CVE ID | CVE-2026-15772 |
| 영향 제품 | Google Chrome for Android |
| 영향 버전 | 150.0.7871.125 미만 |
| CVSS v3.1 | 8.3 (High) — AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H |
| CWE | CWE-416: Use-After-Free |
| 공개일 | 2026-07-14 |
| 수정 | Chrome for Android 150.0.7871.125 이상, Chromium 변경 958d91fe0da1 |
| WBO 분류 이유 | Android Chrome의 GPU 명령 처리 경로에서 발생하며, 벤더는 이미 손상된 renderer가 조작된 HTML을 통해 잠재적으로 샌드박스를 탈출할 수 있다고 설명함 |
CVE-2026-15772은 Chrome Android의 GPU 읽기 경로가 임시 framebuffer object(FBO)를 삭제하는 순서에서 발생한 Use-After-Free 문제다. 벤더 설명의 전제는 일반 웹페이지가 곧바로 이 문제를 악용한다는 것이 아니라, 이미 renderer를 손상시킨 원격 공격자가 조작된 HTML로 GPU 경로를 자극해 잠재적인 샌드박스 탈출을 시도할 수 있다는 것이다. 따라서 이 CVE는 독립적인 renderer 침해 수단이 아니라, 그 뒤에 이어질 수 있는 권한 경계 문제로 해석해야 한다.
공개 Chromium 수정은 GLTextureHolder::ReadbackToMemory에서 임시 FBO를 삭제하기 전에 이전
FBO 바인딩을 복원하도록 수명 관리를 바꿨다. 수정 설명에 따르면 일부 GPU 드라이버는 FBO를
전환한 뒤에도 이전 바인딩의 내부 참조를 유지할 수 있다. 이런 상태에서 아직 바인딩 상태와
연관된 FBO를 삭제하고 다시 바인딩하면, 드라이버가 해제된 상태를 역참조할 수 있다.
웹 콘텐츠의 그래픽 작업은 renderer에서 요청되고, GPU 경로는 공유 메모리 command buffer를 통해 명령을 받아 네이티브 GL 호출을 수행한다. Chromium의 GPU 설계 문서는 Android에서 GPU 구현이 browser 프로세스의 GPU thread에서 동작하는 예외가 있더라도, renderer가 명령을 보내고 GPU 측이 이를 실행하는 역할은 같다고 설명한다.
웹 콘텐츠 / renderer
│ graphics command buffer
▼
Chrome의 GPU 경로
│ OpenGL / 드라이버 호출
▼
GPU 드라이버와 그래픽 자원
그래픽 코드는 웹 콘텐츠에서 널리 접근 가능하면서도 네이티브 C++와 드라이버 상태를 만난다. Chromium 보안 문서가 이 경로를 별도 연구 주제로 다루는 이유도 여기에 있다. Android의 GPU 프로세스 격리 구성은 버전·기기·플랫폼 정책에 따라 달라질 수 있지만, Chromium의 공개 플랫폼 문서는 Android GPU를 다른 데스크톱 플랫폼과 달리 별도 GPU sandbox 대상으로 열거하지 않는다.
FBO는 텍스처 같은 그래픽 자원을 렌더링하거나 읽기 위한 대상이다. ReadbackToMemory는 텍스처를
임시 FBO에 연결한 뒤 glReadPixels 계열 호출로 내용을 메모리로 읽어 온다. 여기서 FBO 식별자는
단순 정수가 아니라 드라이버가 추적하는 객체의 핸들이며, 어느 FBO가 현재 바인딩됐는지도 GL
상태의 일부다.
이전 FBO 바인딩
│
├─ 임시 FBO 생성·바인딩
├─ 텍스처 읽기
└─ 이전 FBO 복원 후 임시 FBO 삭제
따라서 객체 삭제와 바인딩 복원은 교환 가능한 두 동작이 아니다. 드라이버가 바인딩 전환 사이의 내부 참조를 보유할 수 있으므로, 복원 전에 삭제하면 그 참조가 해제된 FBO를 가리킬 수 있다.
C++에서 자동 객체는 선언한 역순으로 파괴된다. 이 수정은 이 성질을 이용한다. 임시 FBO 소유자와 바인딩 복원 객체를 각각 RAII 객체로 만들고, 임시 FBO를 먼저 선언했다. 그러면 scope를 벗어날 때 바인딩 복원 객체가 먼저 파괴되어 이전 FBO를 복원하고, 그 다음에 임시 FBO가 삭제된다.
선언 순서
1. ScopedTemporaryFramebuffer temp_fbo
2. ScopedFramebufferBinder binder
파괴 순서
1. binder: 이전 FBO 복원
2. temp_fbo: 임시 FBO 삭제
이 순서 의존성은 수동 DeleteFramebuffers 호출보다 코드 리뷰와 테스트로 검증하기 쉽다.
패치 전 ReadbackToMemory는 임시 FBO를 직접 만들고, 바인딩을 보존하는 객체가 아직 살아 있는
상태에서 해당 FBO를 직접 삭제했다. 이후 scope 종료 시 바인딩 보존 객체가 이전 FBO를 복원했다.
공개 수정 설명은 일부 드라이버가 이전에 바인딩한 FBO의 내부 참조를 전환 사이에 유지한다고
명시한다. 그러므로 삭제 후 재바인딩 과정에서 드라이버 내부 상태가 해제된 FBO를 역참조할 수
있었다.
패치 전
임시 FBO 생성 → 임시 FBO 바인딩 → 읽기 수행
│
▼
임시 FBO 삭제
│ (바인딩 복원 객체는 아직 살아 있음)
▼
scope 종료 시 이전 FBO 재바인딩
│
▼
드라이버 내부 참조가 해제된 FBO를 가리킬 가능성
이는 JavaScript 객체를 직접 해제하는 문제가 아니다. 공개 근거가 가리키는 UAF는 GPU 드라이버가 관리하는 FBO 바인딩 상태에서 발생할 수 있는 네이티브 수명 오류다. 실제 영향은 드라이버 구현과 기기 구성에 좌우되므로, 공개 자료만으로 특정 GPU 모델에서의 임의 코드 실행을 단정할 수는 없다.
NVD의 벤더 제공 설명은 공격자가 renderer를 이미 손상시킨 상태에서 조작된 HTML로 이 경로를 유도할 수 있다고 제한한다. renderer가 그래픽 명령을 GPU 경로에 전달할 수 있기 때문에, GPU 네이티브 코드나 드라이버 상태의 오류는 renderer 샌드박스에 갇힌 공격자에게 더 높은 권한의 경계를 건드릴 기회를 줄 수 있다. 이것이 CVSS의 Scope Changed와 "potential sandbox escape"라는 표현의 배경이다.
다만 이는 샌드박스 탈출이 확정됐다는 뜻이 아니다. 공개 이슈는 제한되어 있고, 벤더도 renderer 침해라는 선행 조건을 명시했다. 이 보고서는 그 조건을 생략한 단일 웹페이지 공격 또는 완전한 공격 체인을 주장하지 않는다.
Chromium 변경 958d91fe0da1은 직접 FBO를 삭제하던 코드를 ScopedTemporaryFramebuffer로
교체하고, 그 뒤에 ScopedFramebufferBinder를 선언했다. 결과적으로 scope 종료 때 binder가
먼저 이전 FBO를 복원하고, 임시 FBO는 그 후에 삭제된다. 새 단위 테스트는 임시 FBO 삭제보다
이전 FBO의 BindFramebufferEXT 호출이 먼저 일어나는 순서를 확인한다.
패치 후
임시 FBO 소유자 생성 → binder가 임시 FBO 바인딩 → 읽기 수행
│
▼
scope 종료
│
├─ binder 파괴: 이전 FBO 복원
└─ temp_fbo 파괴: 임시 FBO 삭제
사용자는 Chrome for Android를 150.0.7871.125 이상, 가능한 경우 현재 안정 채널 버전으로 업데이트해야 한다. 이 CVE가 renderer 침해를 전제로 하므로, 별도로 renderer·V8·웹 콘텐츠 취약점에 대한 보안 업데이트를 지연 없이 적용하는 것도 중요하다.
필수 후보 검색으로 확인한 공개 자료에는 검증 가능한 독립 PoC가 없었다. 이 보고서는 Chromium의 공개 수정과 단위 테스트를 정적으로 분석했으며, 취약 동작이나 공개 재현 절차를 실행하지 않았다.
- Chromium 이슈 525317502는 공개 접근이 제한되어 있다. 따라서 영향을 받은 정확한 드라이버, 기기 범위, 충돌 재현 조건, 완전한 공격 체인은 공개 근거만으로 확정할 수 없다.
- 공개 수정은 드라이버 내부 FBO 참조의 UAF를 설명하지만, 해당 UAF가 어떤 메모리 손상 원시값으로 이어지는지는 드라이버와 플랫폼 완화책에 따라 다르다.
- GPU sandbox 구성은 Chromium 버전과 플랫폼별로 달라질 수 있다. Android의 프로세스 배치를 설명하는 공개 문서는 보안 경계의 일반적 맥락이며, 개별 기기의 실제 격리를 보증하지 않는다.
GPU 드라이버가 바인딩 전환 사이에 객체 참조를 유지하는 경우, API 계층은 어떤 수명 불변식을 명시하고 자동 검사해야 할까?
renderer 침해를 전제로 하는 GPU 취약점의 실제 위험도를 평가할 때, 기기별 드라이버 배포와 브라우저 sandbox 구성을 어떻게 함께 측정할 수 있을까?
- Chrome Releases — Stable Channel Update for Desktop (2026-07-14)
- NVD — CVE-2026-15772
- Chromium 변경
958d91fe0da1— FBO delete-while-bound 수정 - 수정된
gl_texture_holder.cc - FBO 삭제 순서 단위 테스트
- Chromium GPU 가속 합성 구조
- Chromium 그래픽 보안 연구 문서
- Chromium 플랫폼별 sandbox 문서
- Chromium 소스 라이선스
본문 참고 자료로 충분했다.