공격형 보안 테스트 기업 XBOW(엑스보우)는 2026년 10월 13일, 연구원과 오픈AI의 GPT-5.6 Sol 모델 기반 AI 에이전트가 8월 2일부터 7일까지 6일 동안 Windows용 크롬 풀체인을 만들었다고 공개했다. 공격자 웹페이지 하나를 열면 크롬 결함 3개가 차례로 이어져 브라우저 샌드박스 밖에서 프로그램이 실행되는 체인으로, 구글은 CVE가 붙은 2건을 8월 25일과 9월 3일 업데이트로 고쳤고 XBOW는 이 체인으로 25만 달러 포상을 받았다고 밝혔다.
이 체인이 실제 공격에 쓰였다는 보고는 없다. 실제 피해 사고는 AI 해킹 사고 사례 2026에 모았고, 이 글은 버그바운티로 끝난 연구 하나를 방어자 관점에서 단계별로 뜯어 본다. 기술 글과 공개 Chromium 이슈가 나온 지금은 업데이트를 받고도 재시작하지 않은 브라우저가 빈틈이다. 같은 9월 3일 업데이트로 고쳐진 별개의 V8 취약점 CVE-2026-85046은 구글이 실제 익스플로잇이 있다고 밝혔고, 다음 날 미국 CISA의 KEV(실제 악용 취약점 목록)에 올랐다.
조치는 세 가지다. 설치 버전이 아니라 실행 중인 크롬 버전으로 점검하고, 재시작 기한을 정책으로 강제하고, Windows에서 크래시 보고 프로세스(crashpad 핸들러)가 다른 프로그램을 띄운 흔적을 찾는다.
한눈에 보기
| 항목 | 내용 |
|---|---|
| 언제 | 제작 2026년 8월 2~7일, 구글 신고 8월 13·17일, 수정 배포 8월 25일·9월 3일, XBOW 공개 10월 13일 |
| 누가 | XBOW 연구원 4명과 AI 에이전트. 6일 작업은 Brendan Dolan-Gavitt가 에이전트와 함께 했다 |
| 무엇이 만들어졌나 | Windows용 크롬 3단 풀체인(V8 메모리 손상 → 애니메이션 WebP 결함으로 V8 샌드박스 탈출 → Crashpad 핸들러 결함으로 렌더러 샌드박스 탈출). 데모는 웹페이지 하나로 서명된 Chrome Beta에서 계산기 실행 |
| AI가 한 일 | 소스코드 탐색, 가설 시험, 개념증명(PoC) 제작, 익스플로잇 단계 개발, 초안 작성 |
| 사람이 한 일 | 전략과 표적 선정, 맥락 제공, 결과 반박과 검증, 탐색 방향 전환, 이을 구성요소 결정, 단계마다 대안을 둔 설계 |
| 피해·영향 | 실제 공격 사용 보고 없음. 패치 안 한 Windows 크롬이 공격자 웹페이지를 열면 샌드박스 밖에서 코드 실행(XBOW 시연, 마지막 단계 CVE-2026-78952는 CISA 평가 CVSS 3.1 8.3) |
| 지금 상태 | XBOW는 세 버그 모두 고쳐졌다고 밝혔다. CVE 기준 최저선은 152.0.7977.82(WebP 단계 반영 버전은 미확인). 10월 20일 확인한 최신 배포 공지는 Stable 155.0.8059.84/.85, Extended Stable 152.0.7977.169(둘 다 10월 15일 게시, 며칠에서 몇 주에 걸쳐 배포). 크롬 156은 10월 14일 조기 배포(Early Stable) 공지만 나왔다 |
| 출처 신뢰도 | 체인 구성·역할·비용·포상은 XBOW 자체 발표(회사 주장). 취약점·수정 버전·실제 악용 여부는 구글 릴리스노트와 NVD로 확인 |
무슨 일이 있었나: 타임라인
- 날짜 미공개: 약 2개월 걸린 첫 풀체인은 마지막 단계가 구글이 몇 달 전 내부에서 찾은 버그와 겹쳐 무산됐다.
- 2026-08-02(일)~08-07(금): Dolan-Gavitt와 에이전트가 새 체인을 만들었다(API 비용 약 4만 달러, XBOW 추산).
- 날짜 미공개: 새 체인 첫 버전의 V8 샌드박스 탈출 단계(Gin 취약점)가 Chromium issue 542670566과 중복으로 드러나, XBOW는 몇 시간 만에 애니메이션 WebP 단계로 바꿨다. 구글은 체인이 계산기를 띄우는 것을 확인했다.
- 2026-08-13·08-17: Crashpad 버그(issue 545820931)와 V8 버그(issue 547819997) 신고. 신고자 표기는 'Brendan Dolan-Gavitt, XBOW'다.
- 2026-08-25: 크롬 152 Stable(Windows·Mac 152.0.7977.64/.65) 배포. 보안 수정 327건 가운데 하나로 CVE-2026-78952를 고쳤다.
- 2026-09-03: Stable 152.0.7977.82/.83(Windows·Mac) 배포. CVE-2026-85045와 함께, 다른 연구자가 신고했고 구글이 실제 익스플로잇을 인지한 V8 타입 혼동 CVE-2026-85046도 고쳤다.
- 2026-09-04: CISA가 CVE-2026-85046을 KEV에 올렸다(미국 연방기관 조치 기한 9월 18일).
- 날짜 미공개: 구글이 25만 달러 포상을 줬다(XBOW 발표). '2026년 4월 도입된 VRP 규정의 첫 크롬 풀체인 포상'도 XBOW 주장이며 릴리스노트 보상 칸은 'TBD'다.
- 2026-10-13: XBOW 본문(Oege de Moor)과 기술 글(Brendan Dolan-Gavitt) 공개.
공격 흐름 단계별 분석
2·3단계는 렌더러 안에서 끝나 OS 로그에 흔적을 남기기 어렵다(분석). 방어자가 잡을 지점은 방문 기록(1단계), 샌드박스 밖 프로세스 동작(4·5단계), 모든 단계에 걸린 '실행 중 버전'이다.
1단계 진입: 공격자가 만든 웹페이지를 연다
- 무엇을: 피해자가 크롬으로 공격자 웹페이지를 연다. NVD는 체인 CVE 2건의 경로를 '조작된 HTML 페이지'로, 사용자 상호작용을 '필요(UI:R)'로 적었다. ATT&CK T1189(Drive-by Compromise).
- 흔적: 웹 프록시 로그의 방문 URL, DNS 로그의 질의 도메인, 브라우저 기록(프로필 폴더의
History파일, 일반 점검). 공격 URL 지표는 공개되지 않아 4·5단계 경보 시각의 방문 기록을 거꾸로 찾는 데 쓴다.
2단계: V8 엔진 메모리 손상(CVE-2026-85045)
- 무엇을: XBOW에 따르면 이 결함으로 V8이 렌더러 안에 따로 둔 샌드박스(4GiB 포인터 압축 영역, in-process sandbox) 전체를 읽고 쓰는 능력을 얻었다. NVD 설명은 '샌드박스 안에서 임의 코드 실행'이다.
- 취약점·기법: 구글은 경쟁 조건(CWE-367)으로 분류했고(CISA 평가 CVSS 3.1 7.5), XBOW는 최적화 컴파일러 Maglev가 역최적화(deoptimization) 때 값이 바뀔 수 있는 숫자 객체를 재사용한 결함으로 설명한다. 두 설명의 관계는 출처에 없다. 수정은 V8 change 8255554, 반영은 152.0.7977.82부터다. ATT&CK T1203(Exploitation for Client Execution).
- 흔적: 고유한 흔적은 기대하기 어렵다. 실행 중 버전이 152.0.7977.82 미만인지 본다.
3단계: V8 샌드박스 탈출(애니메이션 WebP, issue 548509153)
- 무엇을: XBOW 설명으로는 Blink가 WebCodecs ImageDecoder로 넘겨받은(transfer) ArrayBuffer를 자기만 쓴다고 가정했다. 공격자는 2단계 능력으로 Uint8Array 뷰 하나를 V8의 분리 알림 목록에서 빼 두고 버퍼를 넘긴 뒤에도 데이터를 바꿨다. 디코더는 바뀐 압축 데이터를 읽으면서 출력 버퍼는 바뀌기 전 프레임 크기로 잡았고(검사·사용 시점 차이, TOCTOU), 넘친 픽셀 쓰기가 디코더 객체의 내부 필드를 덮어썼다. 이렇게 얻은 샌드박스 밖 쓰기 한 번으로 Wasm 코드 포인터 테이블 기준 주소를 바꿔 렌더러에서 네이티브 코드를 실행했다.
- 취약점: CVE 번호와 반영된 크롬 버전은 확인되지 않았다. XBOW는 Chromium change 8266257과 8352899로 고쳐졌다고 밝혔다.
- 흔적: 2단계와 같다. 반영 버전을 모르니 최저선이 아니라 점검일의 최신 버전으로 본다.
4단계: 렌더러 샌드박스 탈출(CVE-2026-78952, Windows)
- 무엇을: XBOW에 따르면 크롬의 Crashpad 핸들러는 렌더러 샌드박스 밖에서 돌고, 스냅샷 요청을 받으면 렌더러를 일시 정지(NtSuspendProcess)한 뒤 그 메모리를 읽는다. 렌더러 쪽 코드는 정지에 걸리지 않는 스레드(THREAD_CREATE_FLAGS_BYPASS_PROCESS_FREEZE)로 핸들러의 읽기 실패와 재시도 사이에 페이지 보호 속성을 바꿔, 핸들러가 요청보다 많은 바이트를 복사하게 했다(범위 밖 쓰기, CWE-787).
- 취약점: NVD는 '렌더러 프로세스를 장악한 원격 공격자가 샌드박스 밖에서 임의 코드를 실행할 수 있다'고 적었다. Windows 한정이고 CISA 평가 CVSS 3.1 8.3(S:C)이다. 수정은 Chromium change 8267322, 반영은 Windows 152.0.7977.65부터다.
- 흔적: Windows의 Crashpad 핸들러는 명령줄에
--type=crashpad-handler가 붙은 chrome.exe 프로세스다(일반 점검). 이 프로세스의 자식과 크래시 덤프 폴더가 단서다.
5단계: 샌드박스 밖 프로세스 실행(데모는 계산기)
- 무엇을: XBOW 설명으로는 덮어쓴 핸들러 내부 객체를 거쳐 원래 있던 대체 크래시 핸들러 실행 함수(FallbackCrashHandlerLauncher::LaunchAndWaitForHandler)가 불렸고, 이 함수가
cmd /k calc.exe를 CreateProcessW에 넘겼다. 프로세스 트리로는 crashpad 핸들러 아래 cmd.exe, 그 아래 계산기가 뜨는 모양이다(분석). ATT&CK T1059.003(Windows Command Shell). - 완화기법: XBOW가 시험한 CET 지원 시스템에서는 사용자 모드 섀도 스택과 CFG(간접 호출 대상 제한)가 켜져 있었지만, 체인은 정상 호출·반환 순서를 지키고 CFG가 허용한 기존 함수로 호출을 돌려 피했다. OS 완화기법이 패치를 대신하지 못한다는 뜻이다(분석).
- 공개되지 않은 것: 최종 프로세스 권한(무결성 수준), 시험한 Windows 버전, macOS·Linux 동작 여부.
- 흔적: Sysmon 이벤트 1, 보안 로그 4688, EDR 프로세스 트리의 crashpad 핸들러 자식 프로세스(조건은 아래 표).
AI는 정확히 무엇을 했나
AI가 한 일
- XBOW 본문은 AI가 '크롬 소스코드를 탐색하고, 아이디어를 시험하고, 개념증명을 만들고, 익스플로잇의 가장 이른 초안을 썼다'고 적었고, 기술 글은 '익스플로잇 단계 개발'을 더했다.
- 작업은 목표를 좁힌 병렬 캠페인 5개(광범위 취약점 탐색, V8 메모리 손상, V8 샌드박스 탈출, 렌더러 샌드박스 탈출, 통합)로 나뉘었다.
- 모델은 오픈AI의 GPT-5.6 Sol과 그 이전 모델들이다(본문). XBOW는 보안 특화 모델이나 접근 제한 모델이 아닌 누구나 쓸 수 있는 모델을 일부러 골랐다.
사람이 한 일
- 연구원들은 표적을 고르고, 맥락을 주고, 결과를 반박하고, 탐색 방향을 바꾸고, 어떤 구성요소를 이을지 정했다(기술 글).
- XBOW가 '사람의 결정'으로 꼽은 것은 체인을 '대안을 하나씩 둔 독립된 세 부분'으로 나눈 설계다. 덕분에 Gin 단계가 중복으로 드러났을 때 몇 시간 만에 WebP 단계로 바꿀 수 있었다. 에이전트는 XBOW Native Team이 만든 기존 기법을 참고했다.
과장된 해석 바로잡기
- 'AI가 혼자 크롬을 뚫었다'가 아니다. XBOW 본문도 이 성과를 '연구원의 판단과 에이전트의 속도'가 함께 낸 것으로 적었고, 단계별 기여 비율은 공개되지 않았다.
- '누구나 6일이면 만든다'도 아니다. XBOW 기술 글도 이 시간과 돈이면 누구나 크롬 체인을 얻는다는 뜻은 아니며 사람의 전문성과 판단이 꽤 들어갔다고 적었다. 6일은 첫 체인의 경험, 사내 익스플로잇 기법, 미리 준비한 대체 단계 위에서 나왔고, 약 4만 달러는 이 6일 캠페인의 API 비용 추산이다. 에이전트 수와 토큰 사용량은 공개되지 않았다.
- 실제 공격에 쓰였다는 보고는 없다. 10월 20일 NVD 조회 기준 체인 CVE 2건에는 KEV 등재 표시가 없고, 실제 악용된 CVE-2026-85046은 다른 연구자(Salvatore Gulizia)가 신고한 별개 버그다.
- 검증할 수 없는 문장도 있다. 본문 제목의 '10억 사용자'는 회사 추정이고, 정보기관 출신 인사의 '6개월' 일화도 확인할 방법이 없다.
AI 모델이 브라우저 취약점을 엮은 앞선 사례와 기업 점검 항목은 미토스 쇼크 정리에 있다.
왜 뚫렸나: 원인
기술 원인
- '바뀌지 않는다'는 가정이 단계마다 깨졌다. XBOW는 세 결함 모두 바뀌지 않는다고 여긴 것을 바꾼 문제였다고 봤다. V8은 고정값으로 본 숫자 객체, WebP 디코딩은 넘겨받은 버퍼, Crashpad는 멈춘 줄 알았던 렌더러의 페이지 보호 속성이다. 믿을 수 없는 안쪽(V8 샌드박스·렌더러) 데이터를 바깥 구성요소(Blink·Crashpad)가 믿은 구조가 공격면이 됐다(분석).
운영 원인
- 재시작해야 고쳐진다. XBOW는 '크롬은 업데이트를 스스로 설치하지만 수정은 브라우저를 다시 실행해야 적용된다'며 업데이트 버튼이 보이면 매번 재시작하라고 권했다. 두 릴리스노트도 '며칠 또는 몇 주에 걸쳐' 배포한다고 적었으니, 창을 몇 주씩 닫지 않으면 설치 버전과 실행 버전이 갈린다.
- Extended Stable은 수정선에 닿는 날이 다르다. 이 채널은 8월 18일 150.0.7871.250 다음 업데이트가 9월 9일 152.0.7977.120이었다. NVD 수정선(152.0.7977.65, 152.0.7977.82) 이상 버전이 이날 처음 나와 Stable보다 15일, 6일 늦었다(150 버전에 같은 결함이 있었는지는 출처에 없다).
- 세부 정보는 결국 공개된다. 릴리스노트는 대부분의 사용자가 업데이트될 때까지 버그 세부 정보를 제한할 수 있다고 적는데, 이번에는 수정 40~49일 뒤 기술 글이 나왔고 XBOW는 V8·Crashpad 근본 원인 보고를 공개 이슈로 안내했다. 옛 버전 단말은 공개된 분석을 따라 할 수 있는 표적이다(분석).
- 패치 창이 짧다. 신고에서 수정 배포까지 Crashpad 건은 12일, V8 건은 17일이었다. CVE-2026-85046은 수정 다음 날 KEV에 올랐고 조치 기한은 2주 뒤였다.
- 같은 버그를 여러 곳이 찾는다. XBOW는 구글을 포함해 모두가 크롬 같은 코드에 LLM을 돌리는 지금 버그 중복이 큰 위험이라고 적었고, 실제로 두 체인에서 한 단계씩 구글 내부 발견 버그와 기존 이슈에 겹쳤다. 같은 결함을 쥔 사람이 또 있을 수 있으니 수정은 시간 단위로 반영한다(분석).
우리 조직에서 찾아볼 흔적
기준 버전은 구글 릴리스노트와 NVD, 수집 방법과 쿼리는 일반 점검이다. 기준값에는 최저선(152.0.7977.82, Windows Crashpad 건은 152.0.7977.65)과 점검일의 채널별 최신을 둘 다 넣는다.
| 확인할 곳 | 볼 내용 | 예시 조건 |
|---|---|---|
| EDR 프로세스 이벤트·소프트웨어 인벤토리 | 실행 버전과 설치 버전 | Defender DeviceProcessEvents의 ProcessVersionInfoProductVersion(Sysmon 이벤트 1은 FileVersion)이 기준 미만인 실행 기록은 미조치 후보. 현재 실행 버전은 chrome://version이나 EDR 실시간 프로세스 목록으로 확인하고, 같은 설치 경로·채널의 DeviceTvmSoftwareInventory SoftwareVersion보다 낮으면 '재시작 대기', 확인 못 한 단말은 미확인 |
| 크롬 설치 폴더(Windows) | 재시작 대기 표식 | C:\Program Files\Google\Chrome\Application(사용자 설치는 %LOCALAPPDATA%\Google\Chrome\Application)에 new_chrome.exe가 남아 있음(일반 경험칙) |
| 구글 관리 콘솔(Chrome Enterprise Core) | 채널·버전 분포 | 버전 보고서에서 채널별 최신 미만 추출 |
| Sysmon 이벤트 1·EDR 프로세스 트리 | crashpad 핸들러의 자식 | ParentImage가 chrome.exe, ParentCommandLine에 --type=crashpad-handler, Image가 chrome.exe 아님 |
| 보안 로그 4688 | 같은 조건 | Creator Process Name이 chrome.exe인 cmd.exe·powershell.exe 생성 → Creator Process ID로 부모의 4688을 찾아 --type=crashpad-handler 확인(명령줄 감사 필요) |
| Crashpad 폴더·chrome://crashes | 덤프 몰림 | %LOCALAPPDATA%\Google\Chrome\User Data\Crashpad\reports의 .dmp 생성(Sysmon 이벤트 11)이 하루 사이 튀는 단말(일반 경험칙, 출처의 지표 아님. 크래시 보고 설정에 따라 안 남을 수 있음) |
| EDR·취약점 관리 도구 | CVE-2026-85046 노출 단말 | 152.0.7977.82 미만이 돌던 기간에 chrome.exe가 띄운 cmd.exe·powershell.exe·rundll32.exe 조회(일반 점검, 실제 공격의 탈출 방식은 미공개) |
- Defender, 최근 실행된 버전:
DeviceProcessEvents | where Timestamp > ago(1d) and FileName =~ "chrome.exe" | summarize arg_max(Timestamp, ProcessVersionInfoProductVersion) by DeviceName | where parse_version(ProcessVersionInfoProductVersion) < parse_version("152.0.7977.82"). 프로세스 생성 기록이라 하루 동안 크롬을 새로 띄우지 않은 단말은 빠지고, 설치 경로가 둘이면 마지막 기록 하나만 남는다. 빠진 단말과 설치 경로·채널은 미확인으로 두고 chrome://version이나 EDR 실시간 프로세스 목록으로 확인한다. 설치 인벤토리는 설치 버전 비교에만 쓴다. - Defender, crashpad 자식 프로세스:
DeviceProcessEvents | where InitiatingProcessFileName =~ "chrome.exe" and InitiatingProcessCommandLine contains "--type=crashpad-handler" and not(FileName =~ "chrome.exe") - Splunk(Sysmon):
EventCode=1 ParentImage="*chrome.exe" ParentCommandLine="*--type=crashpad-handler*" NOT Image="*chrome.exe" - 버전 비교: 네 자리 숫자로 나눠 비교한다. 문자열로 비교하면 152.0.7977.120이 152.0.7977.82보다 작게 나온다.
- 오탐 줄이기: crashpad 핸들러가 chrome.exe를 띄우는 경우(대체 크래시 핸들러 등)는 정상일 수 있어 뺀다. 브라우저의 cmd.exe 실행은 확장 프로그램 연동(네이티브 메시징)으로도 생기며, 이때 자식 명령줄에
chrome-extension://과chrome.nativeMessaging파이프 이름이 보인다(일반 경험칙).
대응 순서
오늘
- 보안관제·IT 운영: 실행 중 버전을 모은다. 위 쿼리로 미조치 후보를 뽑고 chrome://version이나 EDR 실시간 프로세스 목록으로 확인해 152.0.7977.82 미만과 채널별 최신 미만을 따로 표시한다. 10월 20일 기준 Stable 단말은 155.0.8059.84/.85, Extended Stable 단말은 152.0.7977.169와 비교하고, 크롬 156의 일반 Stable 배포가 공지되면 기준을 바꾼다.
- 보안관제: 재시작 요청 전에 crashpad 자식 프로세스 쿼리부터 돌린다. 걸린 단말은 업데이트·재시작을 미루고 5번의 격리·증거 보존부터 한다. 결함이 언제부터 있었는지, 누가 같은 버그를 쥐었는지 알 수 없으니 로그가 남은 기간 전체 조회는 재시작과 함께 이어서 한다.
- IT 운영: 나머지 재시작 대기 단말에 오늘 재시작을 요청한다. 설치·실행 버전이 다르거나
new_chrome.exe가 남은 단말 목록을 사용자와 부서장에게 보내고, 사용자는 chrome://settings/help에서 '다시 시작'을 누른다. - IT 운영: 업데이트가 막혔는지 본다(일반 점검).
HKLM\SOFTWARE\Policies\Google\Update의UpdateDefault나Update{8A69D345-D564-463C-AFF1-A69D9E530F96}(크롬 앱 ID)가 0(끔)·2(수동만)인지, 같은 앱 ID가 붙은TargetVersionPrefix로 버전이 고정됐는지,AutoUpdateCheckPeriodMinutes가 0인지 본다. 막혀 있으면 사내 배포 도구로 최신 패키지를 설치한 뒤 크롬을 다시 시작하고 chrome://version에서 기준 이상인지 확인한다(2번에서 걸린 단말은 5번이 먼저다). - 침해 대응 담당: 의심 단말이 나오면(일반 사고대응) 전원을 끄지 말고 EDR로 네트워크를 격리한 뒤 메모리 덤프, EDR 타임라인, Crashpad 폴더, 브라우저 기록을 보존한다. 그 사용자의 SSO·메일·클라우드 세션을 끊고 비밀번호를 바꾼 뒤, 같은 URL에 접속한 단말로 조회를 넓힌다(침해사고 1시간 골든타임 액션북).
- 보안팀: Edge·Whale 등 다른 Chromium 기반 브라우저는 제조사 보안 공지에서 위 CVE 번호로 확인한다. 영향과 수정 버전은 이번에 확인하지 못했다.
이번 주
- 데스크톱 관리자: 재시작 기한을 정책으로 건다(일반 점검). 그룹 정책이나
HKLM\SOFTWARE\Policies\Google\Chrome에RelaunchNotification=2(필수)와RelaunchNotificationPeriod(예: 72시간=259200000ms, 고위험군 24시간=86400000ms)를 걸고, 재시작 시간대는RelaunchWindow로 정한다. 이름과 값은 적용 전에 Chrome Enterprise 정책 목록에서 확인한다. - 보안관제: crashpad 탐지 룰을 상시 경보로 등록한다. 1주일 기준선으로 오탐을 본 뒤 고위험 경보로 둔다. 4688에 명령줄이 빠진 단말은 'Audit Process Creation'과 'Include command line in process creation events' 정책을 켜거나 Sysmon을 배포한다(일반 점검).
- IT 운영: 실행 버전 보고를 매일 돌린다. 관리 콘솔 클라우드 보고(
CloudReportingEnabled)나 EDR 쿼리로 모아 기준 미만은 자동 티켓으로 만들고, 기준값은 Chrome Releases 새 게시물이나 구글 버전 기록 API(versionhistory.googleapis.com)로 매일 갱신한다. - 보안팀: Extended Stable 단말을 따로 관리한다(일반 점검). 채널을 extended로 지정한 단말(Google Update 정책
TargetChannel)과 그 이유를 확인하고, 이 채널의 기준 버전과 패치 기한을 따로 둔다.
이번 달
- 보안팀: 브라우저 패치 기준을 '실행 버전'으로 정한다(일반 점검). High·Critical 수정은 배포 후 72시간, KEV 건은 24~48시간 안을 목표로 하고 매주 미준수 단말을 보고한다(제로데이 패치 우선순위).
- 보안팀·데스크톱 관리자: 고위험 사용자군의 공격면을 줄인다(일반 점검). 임원·재무·관리자 계정 보유자·보안팀에 JIT 차단(
DefaultJavaScriptJitSetting=2, 필요한 사이트만JavaScriptJitAllowedForSites로 예외)과 향상된 세이프 브라우징(SafeBrowsingProtectionLevel=2)을 시범 적용한다. JIT 차단으로 이 체인이 막혔을지는 출처로 확인되지 않으니 호환성과 성능부터 시험한다.
자가점검
예/아니오로 답하고 '아니오'부터 위 대응 순서로 돌아간다.
1. 단말별 크롬 '실행 중' 버전을 하루 안에 뽑을 수 있는가
설치 버전만 보면 재시작하지 않은 단말이 '조치 완료'로 잡힌다.
2. 업데이트 뒤 재시작 기한을 정책으로 강제하는가
수정은 재시작해야 적용되고 구글 배포도 며칠에서 몇 주가 걸린다.
3. 모든 단말이 152.0.7977.82 이상이고 채널별 최신을 따라가는가
152.0.7977.82는 CVE 3건 기준 최저선일 뿐이고, WebP 단계의 반영 버전은 확인되지 않았다.
4. Extended Stable 단말의 수정 일정을 Stable과 따로 추적하는가
9월에는 Stable보다 6일 늦게 이 채널에 수정선 이상 버전이 나왔다.
5. crashpad 핸들러가 cmd.exe나 powershell.exe를 띄우면 경보가 울리는가
XBOW 데모의 마지막 단계가 이 모양이었다. 4688 명령줄 감사나 Sysmon이 없으면 부모가 crashpad 핸들러인지 가릴 수 없다.
6. KEV에 오른 브라우저 취약점을 실행 버전 기준 24~48시간 안에 닫는가
CVE-2026-85046은 수정 다음 날 KEV에 올랐다.
우리 서비스의 연쇄 공격 경로를 먼저 확인하기
보안 전문 기업 SENTRIX의 AI 심화 취약점 진단은 '탐색은 AI. 검증은 레드팀.' 방식이다. AI가 합의한 대상의 공격면과 취약점 후보를 찾고, 레드팀이 그 후보를 이은 연쇄 공격 경로의 재현 여부와 영향을 검토하며, 재점검 범위와 횟수는 계약 때 정한다. 브라우저 패치나 단말 헌팅을 대신하지 않고 모든 취약점의 발견을 보장하지도 않는다. 우리 웹 서비스·API의 결함 여러 개가 이어지면 어디까지 닿는지 확인하려면 진단 범위부터 상의하세요. AI 심화 취약점 진단 문의하기
참고 자료
- XBOW(Oege de Moor), XBOW Built a Chrome Full-Chain Exploit Affecting a Billion Users in Six Days(2026-10-13)
- XBOW(Brendan Dolan-Gavitt), Zero to Calc in Six Days: Inside XBOW's Chrome Full Chain(2026-10-13)
- Google Chrome Releases, Stable Channel Update for Desktop 152.0.7977.64/.65(2026-08-25)·152.0.7977.82/.83(2026-09-03)·155.0.8059.84/.85(2026-10-15)
- Chrome for Developers, VersionHistory API guide(2026-10-20 확인)
- Google Chrome Releases, Extended Stable Update for Desktop 150.0.7871.250(2026-08-18)·152.0.7977.120(2026-09-09)·152.0.7977.169(2026-10-15)
- NIST NVD, CVE-2026-85045(2026-09-03)·CVE-2026-78952(2026-08-25)·CVE-2026-85046(CISA KEV 항목 포함)(2026-09-03)