Google Chrome 136 устраняет опасную уязвимость: обновитесь как можно скорее

Google Chrome 136 устраняет опасную уязвимость: обновитесь как можно скорее

Google Chrome 136 устраняет опасную уязвимость: обновитесь как можно скорее

Команда разработчиков Google Chrome выпустила стабильную версию браузера под номером 136 для Windows, macOS и Linux. Вроде бы очередное «техническое» обновление, но есть важная причина не откладывать его установку — в новой версии закрыли сразу восемь уязвимостей, включая одну очень серьёзную.

Главная звезда (и одновременно тревожный сигнал) в списке — CVE-2025-4096, уязвимость высокой степени риска в HTML-движке Chrome.

В двух словах: это heap overflow (переполнение буфера), которое может возникнуть при обработке веб-страниц. Если злоумышленник грамотно воспользуется этой брешью, он сможет выполнить произвольный код на вашем компьютере. То есть буквально получить доступ к системе. Неудивительно, что Google заплатила $5000 исследователю, который её обнаружил.

Апдейт также закрывает несколько менее опасных, но всё равно важных проблем:

  • CVE-2025-4050 — ошибка с выходом за границы памяти в DevTools (средняя опасность);
  • CVE-2025-4051 — недостаточная проверка данных в DevTools (тоже средней степени);
  • CVE-2025-4052 — некорректная реализация одной из функций (низкая опасность).

Что делать?

Обновиться как можно скорее! Обычно Chrome обновляется сам, но лучше перепроверить:

Откройте chrome://settings/help — и убедитесь, что у вас стоит последняя версия.

Google, кстати, намеренно не раскрывает технические детали уязвимостей до тех пор, пока большинство пользователей не установит патчи.

Бесплатные VPN начали умирать за пару дней, IP уже ни при чём

Бесплатный VPN из Telegram бодро запускается, а через несколько дней Reels замирают, YouTube уходит в бесконечную загрузку, а Gemini встречает ошибкой 403. Современные системы фильтрации научились распознавать туннели даже без расшифровки трафика.

По версии пользователя Хабра Djin22, теперь одного нового IP-адреса может быть недостаточно.

Анализаторы изучают размеры пакетов, интервалы между ними, структуру TLS-соединения и другие косвенные признаки. Если трафик ведёт себя как прокси, маскировка под обычный HTTPS уже не всегда спасает.

Один из характерных сценариев автор называет «проблемой 16 КБ»: соединение успешно устанавливается, передаёт первые данные, а затем резко замедляется или обрывается. Для борьбы с этим используют фрагментацию пакетов, уменьшение размера TCP-сегментов и десинхронизацию DPI с помощью zapret. Идея проста: сервер должен получить нормальный поток, а анализатор — головоломку.

Отдельная история — сервисы Google. Они могут учитывать TLS-отпечаток клиента и замечать, когда программа притворяется Chrome не слишком убедительно. В sing-box для более правдоподобной имитации браузера применяют uTLS.

Если Telegram не работает даже через VLESS Reality, автор предлагает ShadowTLS v3: протокол маскирует соединение под обычную TLS-сессию с разрешённым ресурсом. Ещё один приём — padding, то есть добавление случайных данных для изменения размеров пакетов и усложнения статистического анализа.

В качестве готовых вариантов Djin22 перечисляет hynet.cloud, AmneziaVPN, Red Shield VPN, Cloudflare WARP и собственные серверы на Xray или sing-box. Однако часть текста о hynet.cloud выглядит рекламно, а заявления об «эмуляции JA4», residential-маршрутизации и автоматическом переключении протоколов приводятся без независимого подтверждения.

RSS: Новости на портале Anti-Malware.ru