Android: критический RCE без действий пользователя закрыт в ноябре

Google выпустила ноябрьские security-патчи Android двумя пакетами: уровень 2026-11-01 закрыл 119 уязвимостей в компонентах Framework и System, уровень 2026-11-05 — ещё 97, в ядре Linux и сторонних компонентах. Всего патчи закрывают 216 уязвимостей, около двух дюжин из них — критического уровня. Независимо это подтверждает esecurityplanet: Framework получил больше всего фиксов (65), System — 53, отдельные критичные баги нашлись в Bluetooth, pKVM, HID-стеке и модемных компонентах MediaTek и Qualcomm.

Что случилось

Главный повод для срочного апдейта — не количество закрытых дыр, а характер самой опасной из них. Обычно критические уязвимости Android требуют хоть какого-то условия: установленного вредоносного приложения, открытой вредоносной ссылки, физического доступа к устройству. В этом выпуске условие отсутствует.

Чем опасен CVE-2026-58868

CVE-2026-58868 — критическая уязвимость в компоненте Framework, которая, по формулировке самой Google, «может привести к удалённому выполнению кода без каких-либо дополнительных привилегий исполнения, участие пользователя не требуется». Это означает атаку без клика, без установки чего-либо и без видимых пользователю признаков: эксплуатация происходит в фоне, на уровне системного компонента, который обрабатывает входящие данные до того, как пользователь вообще что-то увидел на экране. Рядом с ней в бюллетене закрыты ещё две критические RCE-уязвимости в компоненте Android System — CVE-2026-58876 и CVE-2026-58936.

SMS of Death и другие критичные фиксы

Отдельно в пакете закрыта уязвимость, которую СМИ уже окрестили «SMS of Death» — CVE-2026-58882, критический DoS-баг: специально сформированное SMS-сообщение способно обрушить сервис звонков на устройстве, включая текущий звонок (в том числе экстренный), а в некоторых сценариях — спровоцировать перезагрузку. Для патч-уровня 2026-11-05 отдельные бюллетени выпущены также для Android XR и Wear OS, то есть апдейт затрагивает не только смартфоны, но и экосистему устройств вокруг них.

Что проверить команде, которая ведёт мобильное приложение

• Статус патч-уровня на тестовых и демо-устройствах команды — сверить с 2026-11-01 / 2026-11-05, а не полагаться на автообновление «когда-нибудь»
• Таргет и compile SDK приложения: если минимальная поддерживаемая версия Android давно не пересматривалась, часть пользователей физически не получит этот патч ещё долго
• Поведение приложения на непропатченных устройствах — RCE в Framework не специфичен для конкретного приложения, но деградация системы после эксплуатации может выглядеть как баг именно в вашем продукте в отзывах пользователей
• Канал связи с пользователями о необходимости обновить прошивку, если приложение работает с чувствительными данными

Критический RCE без участия пользователя в системном компоненте — такие вещи редко попадают в зону ответственности самого мобильного приложения, но их последствия всегда долетают до него: нестабильность на старых прошивках, жалобы в отзывах, вопросы от служб безопасности корпоративных клиентов. Команде, которая держит на себе разработку мобильного приложения и его сопровождение, имеет смысл закладывать такие бюллетени в регулярный процесс — проверять патч-уровень тестовых устройств и минимальную поддерживаемую версию ОС на каждом крупном релизе Android, а не разбирать последствия постфактум, когда жалобы уже пошли.