Собрали главное за последнюю неделю. Начнём с того, что эксплуатируют прямо сейчас, — роутеры MikroTik. Дальше два долгожителя: уязвимость PostgreSQL продержалась в СУБД около двенадцати лет, а самая старая из восемнадцати дыр в ядре Linux — восемь. Закончим двумя историями про объём: 3,2 млн необновлённых сайтов на WordPress и 966 патчей Microsoft за один вторник.
MikroTik RouterOS: два бага складываются в полный захват роутера
CERT Polska нашла в MikroTik RouterOS шесть уязвимостей. Две из них в связке дают полный контроль над устройством без аутентификации, если открыт удалённый доступ по SSH, — и это уже применяли в реальных атаках. Проблемы затрагивают SSH-сервер и SSH-клиент, службу тестирования пропускной способности, обработку сертификатов X.509 и веб-интерфейс WebFig. Исправления вышли в версиях 7.25beta3, 7.24.2, 7.23.4 и 6.49.21.
CERT Polska также опубликовала описание трёх самых серьёзных из этих уязвимостей:
CVE-2026-67276— обход аутентификации SSH, 9,2 балла по шкале CVSS. Зная имя пользователя и открытый модуль его ключа, атакующий может собрать другой ключ и войти без закрытого. Права — как у целевой учётной записи.CVE-2026-86060— подмена привилегий сессии, 9,2 балла. RouterOS некорректно разбирала имена, начинающиеся с запрещённого символа. Специально составленное имя пользователя даёт сессии полные административные права.CVE-2026-67277— утечка памяти и сбой в проверке пропускной способности, 8,8 балла. Неаутентифицированное соединение переходило в состояние, доступное только после входа. В связке с утечкой неинициализированных данных из буфера пакетов и переполнением в проверке размера это даёт либо утечку памяти ядра, либо удалённую DoS-атаку с перезагрузкой устройства.
Следы взлома придётся искать вручную. В новой прошивке RouterOS при запуске сканирует конфигурацию на признаки несанкционированных изменений, отключает подозрительные записи и вешает маркер Flagged — но ловит только отдельные следы, так что отсутствие маркера ничего не доказывает.
Что делать. Немедленно обновиться, проверить журналы и значение маркера в выводе /system/device-mode/print, затем поискать в конфигурации неизвестных пользователей, посторонние скрипты, задачи планировщика и туннели. Если патч поставить нельзя — закрыть доступ к SSH, WWW/WWW-SSL и серверу проверки пропускной способности со всех адресов за пределами доверенной сети управления. Также рекомендуется не инициировать TLS-соединения с устройства и не использовать встроенные SSH-клиенты (/system ssh и /system ssh-exec), особенно когда связь проходит через незащищённые сети или направлена на незащищённые хосты.
PostGREShell: репликационная учётка запускает свой код внутри процесса PostgreSQL
Исследователи Cyera Research раскрыли подробности уязвимости PostGREShell — CVE-2026-6471, 7,2 балла по шкале CVSS. Обычный пользователь с атрибутом REPLICATION, без прав суперпользователя мог через логическое декодирование заставить сервер загрузить произвольную нативную библиотеку. Код из неё исполнялся уже не с SQL-правами атакующего, а в адресном пространстве СУБД — с правами системной учётной записи сервера.
Ошибка появилась вместе с логическим декодированием WAL в PostgreSQL 9.4, вышедшей в декабре 2014 года, и прожила незамеченной около двенадцати лет. За это время на этой инфраструктуре выросли логическая репликация и системы Change Data Capture.
Причина — расхождение между двумя путями загрузки расширений. Обычная команда LOAD проверяет имя библиотеки у непривилегированного пользователя, а загрузка output-плагина через replication protocol такой проверки не делала: имя доходило до системного загрузчика напрямую. Порог входа при этом высокий — нужна учётная запись с атрибутом REPLICATION и сервер с wal_level = logical. Но именно такие учётки живут в контурах репликации, бэкапов и CDC.
На Windows атака полностью удалённая: достаточно передать UNC-путь вида \\server\share\file.dll, и DLL с машины атакующего подтянется по SMB. На обычном Linux сложнее — вредоносный .so надо сначала каким-то другим способом положить в доступную PostgreSQL файловую систему. Дальше в обоих случаях повышение привилегий происходит одинаково: нативный код правит системный каталог pg_authid и превращает исходную учётку в суперпользователя в обход SQL ACL.
Что делать. Обновиться до PostgreSQL 18.6, 17.11, 16.15, 15.19 или 14.24 — патч вышел 13 августа, на неподдерживаемых ветках его не будет. В исправленных версиях появился параметр output_plugin_libraries: сервер грузит только библиотеки из явного списка, по умолчанию — pgoutput и test_decoding. Если используете сторонние плагины, впишите их туда вручную, иначе репликация не поднимется. Заодно стоит пересмотреть роли с атрибутом REPLICATION и ограничить источники их подключения через pg_hba.conf.
18 эксплоитов для ядра Linux: путь от обычного пользователя до root
Исследователи Nebula Security раскрыли сведения сразу о 18 уязвимостях в ядре Linux и написали к ним рабочие эксплоиты. Все решают одну задачу: непривилегированный локальный пользователь получает root. Сами уязвимости уже закрыты — исправления разошлись с весенними и летними обновлениями ядра.
Большая часть проблем приходится на сетевую подсистему: IPVS, ip6_tunnel, таблицы маршрутизации IPv6, сетевые мосты, nf_queue в netfilter, IPSec XFRM, MPLS, openvswitch, заголовки IPv6 SRH и B.A.T.M.A.N. Отдельно набралось три уязвимости в SCTP. За пределами сети — io_uring, SysV IPC и posix-cpu-timer. Преобладающий класс ошибок — обращение к памяти после её освобождения. Самая старая, ZcopyReaper в подсистеме RDS, тянется с ядра 4.17 и была закрыта только в мае.
Показательно, где исследователи демонстрировали эксплоиты: Debian 13 и RHEL 10 с ядром 6.12, Ubuntu 26.04 с ядром 7.0, Fedora и Arch с 6.19, openSUSE с 6.4. Не стенды, а то, что стоит в продакшене.
Что делать. Проверить, что на серверах стоит ядро из свежих обновлений дистрибутива, и убедиться, что машины после установки перезагружались: патчи расходились с апреля по август, и на долгоживущих хостах новое ядро вполне может лежать на диске, но не работать. Отдельного внимания стоят системы, где локальный доступ есть у недоверенных пользователей.
All-in-One WP Migration: атака закладывается заранее, а срабатывает при восстановлении бэкапа
В плагине All-in-One WP Migration and Backup для WordPress нашли SQL-инъекцию, которая приводит к удалённому выполнению кода без аутентификации. Уязвимость получила идентификатор CVE-2026-19949 и 8,8 балла по шкале CVSS, затронуты все версии до 7.109 включительно.
Схема атаки построена вокруг секретного ключа ai1wm_secret_key, которым защищён импорт архивов. Сначала атакующий без аутентификации отправляет специально подготовленные trackback-запросы к любой публичной публикации — данные оседают в базе и ждут. Ошибка кроется в обработке экранированных слешей и кавычек при восстановлении: во время импорта плагин переписывает в SQL-дампе URL и префиксы таблиц, и заготовленные данные превращаются в исполняемый запрос, который выкладывает секретный ключ в публичный комментарий. Дальше ключ забирают через WordPress REST API и с ним импортируют собственный .wpress-архив с вредоносным must-use-плагином — он выполнится при первой же загрузке страницы.
Главное здесь — момент срабатывания. Эксплоит срабатывает не при атаке, а когда администратор снимает резервную копию и разворачивает её через тот же плагин: вредоносная нагрузка приезжает в новую инсталляцию вместе с бэкапом, которому все привыкли доверять.
Разработчик, компания ServMask, выпустила исправленную версию 7.110 ещё 20 августа. Но, по данным WordPress.org, к началу сентября на неё перешли лишь около 35% пользователей — уязвимые версии остаются примерно на 3,2 млн сайтов.
Что делать. Обновить плагин до 7.110. Если бэкапы снимали на уязвимой версии, относиться к ним как к потенциально заражённым: перед разворачиванием проверить дамп на посторонние записи и убедиться, что ключ плагина не утёк в публичные комментарии.
966 исправлений за один «вторник обновлений» — и объяснение, почему их будет больше
В сентябрьский «вторник обновлений» Microsoft закрыла 966 уязвимостей в собственных продуктах, а вместе со сторонними компонентами — 974. Это крупнейший набор исправлений в истории компании. В Windows исправили 723 бага, в Office — 222, из них 111 приходится на Office 2016; патчи также затронули SQL Server, SharePoint Server, Azure, Exchange Server и другие продукты.
Две уязвимости уже эксплуатируют. CVE-2026-85880 — переполнение буфера в динамической памяти Windows Advanced Local Procedure Call: локальный атакующий, выполняющий код в AppContainer с низкими привилегиями, выбирается из песочницы и получает SYSTEM без всякого участия пользователя. Прошлый раз баг в этом компоненте чинили ещё в апреле 2023 года. Вторая, CVE-2026-81963 в Windows Update Stack, приводит к SYSTEM через некорректную обработку символических ссылок. Как именно их применяли в атаках, в компании не раскрывают.
В Zero Day Initiative советуют присмотреться к RCE-багам в Exchange Server, SharePoint и Remote Desktop Services — CVE-2026-55007, CVE-2026-69465 и CVE-2026-69525 соответственно. А еще — к уязвимостям повышения привилегий CVE-2026-80097 в Authenticator и CVE-2026-65669 в SQL Server. По оценке эксперта ZDI Дастина Чайлдса (Dustin Childs), около 20 закрытых проблем обладают потенциалом червя: позволяют выполнить код удалённо, без аутентификации и без действий пользователя. Сам рост числа патчей в Microsoft объясняют внедрением ИИ в поиск и анализ уязвимостей — и предупреждают, что дальше исправлений будет только больше.
Что делать. Приоритизировать: сначала две эксплуатируемые 0-day и потенциально червеобразные RCE на периметре, а уже потом всё остальное. Раскатать почти тысячу исправлений одним махом всё равно не выйдет.
