На проверке CVE-2026-11645 Chrome V8 zero-day: разбор OOB-уязвимости и техники эксплуатации движка V8

[Сергей Попов]

Google подтвердил: эксплойт гуляет в дикой природе. Ни кампания, ни атрибуция, ни полная exploit chain публично не раскрыты - но класс бага, два CWE в одном CVE и модель эксплуатации прозрачны для каждого, кто хоть раз разбирал V8 OOB-уязвимости через d8 shell. Разберём, что именно сломалось, как это эксплуатируют и почему «обновите Chrome» - рекомендация верная, но неполная.

Бизнес-логика атаки: зачем ломать V8​

Браузерная эксплуатация V8 - один из самых дорогих примитивов для APT-групп и коммерческих spyware-вендоров. Вектор доставки не требует ни вложения, ни компрометации сервера. Жертва открывает страницу - crafted HTML запускает JavaScript, и движок обрабатывает hostile-код как обычный контент. Тихо, чисто, ни одного алерта на периметре.

В терминологии MITRE ATT&CK цепочка: Drive-by Compromise (T1189, Initial Access) → Exploitation for Client Execution (T1203, Execution), исполнение вредоносного кода через JavaScript (T1059.007, Execution). Атакующий получает foothold в renderer-процессе без единого срабатывания на стороне SOC.

Финансовый импакт определяется тем, что лежит по ту сторону renderer sandbox: session tokens SaaS-приложений, OAuth credentials, cloud CLI tokens, пароли в автозаполнении, содержимое корпоративных дашбордов. Renderer-level foothold - уже серьёзно, а в паре с sandbox escape (отдельная уязвимость) - полная компрометация устройства. На рынке 0-day полная browser chain для Chrome стоит семизначные суммы.

Между появлением эксплойта в дикой природе и фактическим обновлением всех Chromium-зависимостей в инфраструктуре проходят недели. Это и есть окно, в которое бьют.

Google намеренно ограничил детали - домыслы о root cause без patch diff бессмысленны и опасны.

Параметр	Значение
CVE ID	CVE-2026-11645
Компонент	V8 (JavaScript/WebAssembly engine)
Класс уязвимости	Out-of-bounds read and write
CWE	CWE-125 (Out-of-bounds Read), CWE-787 (Out-of-bounds Write)
CVSS 3.1	8.8 HIGH
Вектор	AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Исправлено в	Chrome 149.0.7827.103 (Windows/macOS), 149.0.7827.102 (Linux)
CISA KEV	Добавлен 2026-06-09, дедлайн 2026-06-23
SSVC Decision	Act - патчить немедленно (active exploitation, total technical impact)
EPSS	0.0219, перцентиль 80.9% (выше медианы)
Bounty	$55 000, анонимный исследователь
Затронутые ОС	Windows, macOS, Linux (согласно NVD)
Затронутые браузеры	Google Chrome, Microsoft Edge, Opera и другие Chromium-based (согласно CISA KEV)

Разбор CVSS-вектора: AV:N - атака по сети (достаточно HTTP/HTTPS), AC:L - низкая сложность, PR:N - привилегии не нужны, UI:R - от жертвы требуется открыть страницу. S:U - уязвимость не выходит за пределы security scope компонента V8/renderer; эксплуатация ограничена рамками renderer-процесса без sandbox escape. C:H/I:H/A:H - полная компрометация конфиденциальности, целостности и доступности в рамках sandbox-контекста.

Два CWE одновременно - вот что делает этот CVE интересным. CWE-125 (OOB Read) + CWE-787 (OOB Write) в одной уязвимости означают, что баг даёт и leak, и corruption. В типичном браузерном эксплойте нужны два отдельных бага: один для утечки адресов (обход ASLR), второй - для перезаписи структур в heap. Здесь обе способности в одном CVE - сложность эксплуатации падает резко.

Что НЕ подтверждено: точный компонент V8 (TurboFan, Maglev, Sparkplug, Liftoff, WebAssembly pipeline), конкретный root cause, код эксплойта, атрибуция атакующих, профиль жертв, наличие sandbox escape в наблюдённых атаках. По данным HelpNetSecurity, Google стандартно ограничивает «доступ к деталям бага и ссылкам, пока большинство пользователей не получит обновление».

Архитектура V8 и поверхность out-of-bounds memory уязвимости Chrome​

JIT-конвейер: где рождаются OOB-баги​

V8 обрабатывает JavaScript через многоуровневый pipeline. Ignition генерирует bytecode, Sparkplug компилирует его в baseline machine code, Maglev выполняет mid-tier оптимизацию, TurboFan - агрессивную optimizing compilation. Каждый следующий уровень делает всё более рискованные предположения о типах, формах объектов и диапазонах значений. И именно здесь начинается веселье.

Спекулятивные оптимизации - главный источник OOB-багов в JIT-engine. TurboFan может выкинуть bounds check на доступ к элементу массива, если type feedback говорит, что индекс всегда в пределах length. Если после оптимизации runtime-поведение отклоняется от профилированного - bounds check уже убран, и V8 читает или пишет за границами. Классика.

Предусловия для JIT-related OOB: код должен пройти через hot path достаточное число раз (обычно тысячи итераций), чтобы JIT применил оптимизацию. PoC для таких багов всегда содержит warming loop - прогрев type feedback перед переключением на payload path. Если запустить d8 --trace-opt --print-bytecode, можно наблюдать момент компиляции TurboFan и деоптимизации - именно в этой зоне ищут расхождения.

OOB может сидеть не только в JIT. Runtime-функции V8, обработка регулярных выражений, garbage collector, WebAssembly bounds checking, объектная модель - любой из этих компонентов может оказаться источником бага.

Maps, Hidden Classes и объектная модель​

V8 представляет каждый JavaScript-объект через внутреннюю структуру Map (hidden class), которая определяет layout свойств в памяти. Добавление свойства или изменение типа значения вызывает Map transition - объект получает новую Map с другими смещениями полей.

Если JIT-код кэширует Map и обращается к полям по «старым» смещениям после transition - получаем type confusion или OOB-доступ. В heap V8 это задевает соседние объекты: запись по некорректному offset попадает в метаданные соседа, и баг превращается в эксплуатацию памяти браузера.

Typed Arrays и ArrayBuffer как цели​

Typed arrays (Uint8Array, Float64Array и др.) хранят backing store pointer и length в предсказуемых позициях. Если OOB-запись позволяет подменить length typed array (скажем, записать 0xFFFFFFFF вместо 0x100), атакующий получает read/write примитив на весь 4 ГБ cage V8 Sandbox. Подмена backing store pointer даёт read/write за пределами cage - но тут уже нужен bypass V8 Sandbox (pointer compression, external pointer table), а это отдельная задача.

OOB read/write в V8: от бага до RCE через Chrome V8​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Все пять Chrome zero-day 2026 года добавлены CISA в KEV как активно эксплуатируемые:

CVE	Компонент	Класс	CISA KEV	EPSS перцентиль
CVE-2026-2441	CSS	Use-After-Free (CWE-416)	2026-02-17	97.5% (Top 5%)
CVE-2026-3909	Skia	OOB Write (CWE-787)	2026-03-13	74.2%
CVE-2026-3910	V8	Inappropriate Implementation (CWE-94, CWE-119)¹	2026-03-13	79.0%
CVE-2026-5281	Dawn	Use-After-Free (CWE-416)	2026-04-01	91.5% (Top 10%)
CVE-2026-11645	V8	OOB Read/Write (CWE-125, CWE-787)	2026-06-09	80.9%

Все пять - CVSS 8.8, SSVC decision Act. Четыре из пяти эксплуатируются через crafted HTML page напрямую; CVE-2026-5281 (Dawn) требует предварительной компрометации renderer-процесса. CVE-2026-3910 (CWE-94, CWE-119) - не OOB-баг, а «Inappropriate implementation» в V8, где CWE-94 (Improper Control of Generation of Code) отражает специфику JIT-компиляции, а не классический OOB-доступ. Распределение по компонентам показательно: атакующие бьют не только по V8. CSS-движок (CVE-2026-2441), Skia (CVE-2026-3909), Dawn/WebGPU (CVE-2026-5281) - целью становится любой компонент renderer, который обрабатывает untrusted content.

CVE-2026-2441 выделяется особо: EPSS 97.5-й перцентиль, публичные PoC-репозитории на GitHub (huseyinstif/CVE-2026-2441-PoC, 134 звезды), публичный эксплойт на Exploit-DB (EDB-52542). Use-After-Free в CSSFontFeatureValuesMap - другой класс бага, но результат тот же: heap corruption → fake object → arbitrary read/write. Разница в EPSS между CVE-2026-2441 (97.5%) и CVE-2026-11645 (80.9%) объясняется просто: у первого есть публичный PoC, у второго - нет. Хотя оба активно эксплуатируются.

Верификация экспозиции: патч CVE-2026-11645 и скрытые зависимости​

Проверка версий​

Минимальная верификация - убедиться, что Chrome обновлён. Внутри браузера: chrome://version. Для автоматизации:

google-chrome --version | awk '{print $NF}'
# Ожидаемый вывод: 149.0.7827.103 или выше
# Edge: microsoft-edge --version

Требования к окружению: любая ОС с установленным Chrome/Chromium/Edge, доступ к shell. Для enterprise: osquery (SELECT name, version FROM chrome_extensions + custom query на бинарь Chrome).

Скрытая поверхность: Electron и bundled Chromium​

По данным LinuxSecurity, обновление Chrome не закрывает все поверхности. И вот тут начинается самое интересное. V8 - зависимость VS Code, Slack, Discord, Signal Desktop, Teams, 1Password и десятков других Electron-приложений. Каждый поставляет собственную копию Chromium и обновляется по своему расписанию. Flatpak, Snap, AppImage - отдельные runtime с отдельными циклами обновления.

# Поиск V8 runtime в файловой системе Linux
find /opt /usr/lib /snap -name "v8_context_snapshot*" 2>/dev/null
# Каждый найденный путь - потенциально уязвимый runtime

Headless Chrome в CI/CD (Puppeteer, Playwright), Chromium Embedded Framework в десктопных приложениях, preview-рендеринг в SaaS - всё это V8 за пределами browser auto-update. На каждом втором проекте мы находим такие «забытые» runtime, о которых ИТ-отдел не подозревает.

Детектирование попыток эксплуатации​

Публичного PoC для CVE-2026-11645 нет, но мониторинг возможен на уровне класса бага:

• Crash telemetry: неудачная эксплуатация V8 OOB-бага вызывает crash renderer-процесса (SIGSEGV/SIGBUS). Мониторинг chrome://crashes, Windows Error Reporting, macOS crash reporter выявляет аномальные падения renderer.
• Сетевой уровень: crafted HTML для V8 exploit содержит характерные JavaScript-паттерны - массивные typed array allocations, прогревающие циклы с тысячами итераций, обращения к ArrayBuffer с нестандартными размерами. Network-level inspection (proxy, WAF) может детектировать такие аномалии.
• Endpoint: renderer-процесс, выполняющий нехарактерные IPC-запросы к browser process после обработки определённой страницы - косвенный индикатор renderer compromise.

Ограничение: все эти методы - косвенные. Без signature конкретного эксплойта detection остаётся probability-based, а не deterministic. Это не повод их игнорировать, но и серебряной пули тут нет.

Контекст для пентестера: эксплойт для Chrome браузера в threat model​

При оценке attack surface клиента​

[Применимо: внешний и внутренний пентест, modern-инфраструктура]

1. Инвентаризация Chromium-зависимостей - браузеры, Electron, headless Chrome в CI/CD, CEF в десктопных приложениях. Каждая - отдельная entry point для Drive-by Compromise.
2. Exposure window - измеряется не в часах, а в неделях. Auto-update Chrome ≠ auto-update всех V8 runtime в инфраструктуре. Спросите клиента, когда последний раз обновлялся его Slack или VS Code - ответ вас удивит.
3. Browser policy audit - Chrome Enterprise policies TargetVersionPrefix, UpdateDefault, RelaunchNotification определяют, обновится ли браузер автоматически или повиснет на уязвимой версии.

При моделировании угроз​

OOB read/write в V8 с активной эксплуатацией - не теоретический риск. В threat model:

• Включить T1189 (Drive-by Compromise) как реалистичный вектор
• Учитывать, что renderer-level foothold даёт доступ к cookies, session tokens, OAuth credentials, browser storage - без sandbox escape
• Оценивать цепочку T1189 → T1203 → T1059.007 как complete initial access path

Аспект, который RU-публикации обычно не покрывают: V8 - это не только Chrome. Node.js, Deno, Bun используют V8 для серверного JavaScript. Для CVE-2026-11645 NVD указывает crafted HTML page как вектор, что ограничивает scope browser-контекстом. Но при анализе каждого V8 CVE стоит проверять: доступен ли уязвимый code path из серверного runtime? Если да - поверхность атаки значительно шире.

Пять Chrome zero-day за шесть месяцев - и каждый с одинаковым CVSS 8.8 - создают ощущение рутины. Очередной High severity, ну обновились, ну ладно. Но CVE-2026-11645 выделяется из пятёрки. Два CWE одновременно - CWE-125 и CWE-787 - означают, что одна уязвимость даёт и информационную утечку для обхода ASLR, и запись для corruption. Обычно для стабильной browser exploitation нужны два бага; здесь хватает одного. Это не рутина - это удешевление атаки.

Большинство защитных рекомендаций сводятся к «обновите Chrome». Рекомендация верная, но неполная. V8 - shared dependency, и патч Chrome не закрывает Electron-приложения, headless Chromium в CI, CEF-обёртки в десктопных продуктах. На реальных проектах инфраструктура клиента содержит десятки Chromium-runtime, о которых ИТ-отдел не знает. Инвентаризация этих зависимостей - задача того же уровня приоритета, что и обновление самого Chrome. V8 Sandbox, CFI, MTE реально поднимают стоимость эксплуатации - но пока рынок 0-day жив и browser chains продаются, эти механизмы замедляют атакующих, а не останавливают. Единственная стратегия, которая работает - агрессивный asset management всех V8-зависимостей, а не только иконки Chrome в трее. Запустите find /opt /usr/lib /snap -name "v8_context_snapshot*" на своих серверах - количество результатов может неприятно удивить.