Дайджест уязвимостей от BI.ZONE EASM за июль

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

В этом выпуске:

• Удаленное выполнение кода в Microsoft SharePoint Server.
• Удаленное выполнение кода в Langflow.
• Обход аутентификации в Gitea.
• Удаленное выполнение кода в WordPress с помощью цепочки WP2Shell.

Критическая уязвимость в Microsoft SharePoint Server связана с десериализацией недоверенных данных в механизме обработки токенов аутентификации. С ее помощью удаленный злоумышленник может выполнить произвольный код в контексте службы SharePoint.

Microsoft выпустила исправление 14 июля. После публикации PoC 20 июля исследователи зафиксировали эксплуатацию CVE‑2026‑50522 в реальных атаках. Злоумышленники, в частности, извлекали с серверов SharePoint ASP.NET machine keys. Эти ключи позволяют создавать данные аутентификации, которым сервер будет доверять. Поэтому после возможной компрометации сервера одного обновления недостаточно. 22 июля CISA добавила уязвимость в каталог KEV (Known Exploited Vulnerabilities).

Рекомендации по устранению уязвимости и снижению риска

• Обновите все узлы фермы SharePoint до исправленных сборок:
  • SharePoint Enterprise Server 2016 — 16.0.5561.1001 или новее;
  • SharePoint Server 2019 — 16.0.10417.20175 или новее;
  • SharePoint Server Subscription Edition — 16.0.19725.20434 или новее.
• На каждом сервере фермы проверьте фактически установленную сборку. Загрузка обновления или успешный запуск Windows Update еще не означают, что SharePoint полностью обновлен.
• После обновления смените machine keys, учетные данные служб, административные пароли и другие секреты, которые могли храниться на доступном из интернета сервере.
• Проверьте, не был ли сервер скомпрометирован. Если до установки исправления он был доступен из интернета, отсутствие известных индикаторов не доказывает, что атаки не было.
• По возможности уберите SharePoint с внешнего периметра. Как минимум ограничьте доступ к /_trust/default.aspx адресами доверенного identity provider или корпоративной инфраструктуры аутентификации.

Советы по проверке следов эксплуатации

• Проверьте журналы IIS как минимум с 14 июля 2026 года. Ищите нетипичные POST‑запросы к /_trust/default.aspx, в том числе единичные запросы с незнакомых адресов.
• Ищите запуск cmd.exe, powershell.exe, rundll32.exe, архиваторов и сетевых утилит дочерними процессами w3wp.exe.
• Проверьте каталоги SharePoint и IIS: не появились ли там новые или недавно измененные файлы с расширением .aspx и .dll, конфигурационные файлы и неизвестные .NET‑сборки.
• Проверьте изменения web.config, конфигурации machine keys и параметров аутентификации.
• Ищите новые веб‑шеллы, подозрительные запланированные задания, службы, учетные записи и нетипичные исходящие соединения от IIS.
• Сопоставьте события аутентификации до и после обновления: с помощью похищенных machine keys злоумышленник может сохранить доступ и к исправленному серверу.

Полезные ссылки

• Microsoft Security Update Guide: CVE‑2026‑50522 // Microsoft
• (Pwn2Own) Microsoft SharePoint Deserialization of Untrusted Data Remote Code Execution Vulnerability // Zero Day Initiative
• Critical Vulnerability CVE‑2026‑50522 in Microsoft SharePoint Server Under Exploitation // NHS England
• Critical Vulnerabilities in Microsoft SharePoint // CERT‑EU
• Widespread Exploitation of Microsoft SharePoint // Kudelski Security

Критическая уязвимость в Langflow позволяет выполнить произвольный код без аутентификации. Проблема возникает при обработке параметра exec_globals в обработчике проверки программного кода. Успешная атака дает полный контроль над сервером и доступ к настройкам потоков, базам данных, API‑ключам LLM‑провайдеров, облачным учетным данным и подключенным внутренним системам.

CVE‑2026‑0770 раскрыли еще в январе, но в июле появились новые данные об эксплуатации уязвимости. 21 июля CISA добавила ее в KEV. Все вредоносные запросы были направлены к POST /api/v1/validate/code. Среди них были проверки выполнения команд, загрузчики вредоносного ПО и попытки получить переменные окружения, учетные данные AWS и сведения из облачных служб метаданных.

Рекомендации по устранению уязвимости и снижению риска

• Обновите Langflow и отдельно убедитесь, что небезопасный обработчик проверки кода больше не доступен без аутентификации.
• Пока исправление не подтверждено, полностью закройте Langflow от прямого доступа из интернета. Оставьте подключение только через VPN, административную сеть или по строгому списку доверенных IP‑адресов.
• Если обработчик не нужен опубликованным интеграциям, заблокируйте на обратном прокси или WAF внешние запросы к /api/v1/validate/code.
• Запускайте Langflow от лица непривилегированного пользователя и с минимальными правами контейнера.
• Если эксплуатацию нельзя исключить, смените API‑ключи LLM‑провайдеров, пароли баз данных, облачные ключи, токены интеграций и другие секреты, доступные процессу Langflow.

Советы по проверке следов эксплуатации

• Проверьте журналы обратного прокси и Langflow на наличие запросов POST /api/v1/validate/code, особенно если они пришли из интернета без предшествующей аутентифицированной сессии.
• Ищите в теле запроса параметр exec_globals, фрагменты Python‑кода и обращения к функциям запуска процессов, сетевым библиотекам и файловой системе.
• Проверьте запуск шелл‑процессов, curl, wget, интерпретаторов и неизвестных скриптов дочерними процессами Python или Langflow.
• Ищите обращения к файлам с расширением .env, каталогам с облачными учетными данными и адресам служб метаданных контейнерных или облачных платформ.
• Проверьте новые cron‑задания, systemd‑сервисы, файлы в каталогах временного хранения и изменения внутри контейнера.
• Проанализируйте исходящие соединения Langflow с ранее неизвестными адресами и загрузку вторичных скриптов.

Полезные ссылки

• CVE‑2026‑0770 Detail // NIST NVD
• KEV Catalog: CVE‑2026‑0770 // CISA
• (0Day) Langflow exec_globals Inclusion of Functionality from Untrusted Control Sphere Remote Code Execution Vulnerability // Zero Day Initiative
• CVE‑2026‑0770 Exploited in the Wild: Langflow RCE Added to CISA KEV // KEVIntel
• Critical Vulnerability in Langflow // Cyber Security Agency of Singapore

В официальных Docker‑образах Gitea обнаружили опасную ошибку конфигурации. В шаблоне app.ini параметру REVERSE_PROXY_TRUSTED_PROXIES по умолчанию было задано значение *. Из‑за этого Gitea могла доверять заголовкам аутентификации от любого источника, а не только от известного обратного прокси.

Для атаки должно одновременно совпасть несколько условий: организация использует официальный Docker‑образ Gitea версии 1.26.2 или ниже, включена аутентификация через обратный прокси, а атакующий может обратиться напрямую к HTTP‑порту контейнера или передать через промежуточную инфраструктуру заголовок X‑WEBAUTH‑USER. Тогда он может без пароля и сессионного cookie выдать себя за существующего пользователя, включая администратора. Бинарные и самостоятельно собранные установки с безопасным loopback‑значением по умолчанию этой ошибке не подвержены.

Рекомендации по устранению уязвимости и снижению риска

• Обновите официальный Docker‑образ Gitea как минимум до 1.26.3, а лучше сразу до 1.26.4 или более новой поддерживаемой версии.
• Укажите в REVERSE_PROXY_TRUSTED_PROXIES IP‑адреса или подсети доверенного обратного прокси вместо *.
• Если аутентификация через обратный прокси не используется, отключите ENABLE_REVERSE_PROXY_AUTHENTICATION.
• Не публикуйте порт Gitea‑контейнера напрямую в интернет. Весь трафик должен идти через доверенный обратный прокси, а доступ к бэкенд‑порту нужно ограничить сетевыми правилами.
• Выясните, включена ли автоматическая регистрация пользователей через обратный прокси. При небезопасной конфигурации она усиливает последствия атаки.
• Если обнаружите подозрительную активность, смените персональные токены, ключи развертывания, пароли интеграций и секреты CI/CD.

Советы по проверке следов эксплуатации

• Ищите запросы с заголовками X‑WEBAUTH‑USER и другими заголовками аутентификации через обратный прокси, если они пришли не с адреса доверенного прокси.
• Проверьте прямые подключения к стандартному HTTP‑порту контейнера Gitea, в том числе те, которые обошли основной обратный прокси.
• Сопоставьте успешные пользовательские сессии с журналами SSO. Сессия Gitea без соответствующего события у провайдера аутентификации может указывать на обход прокси‑аутентификации.
• Проверьте действия от имени администраторов и других привилегированных пользователей: массовое чтение репозиториев, добавление SSH‑ключей, создание токенов, изменение вебхуков и настроек CI/CD.
• Ищите скачивание или клонирование большого числа приватных репозиториев с ранее незнакомых адресов.
• Проверьте создание новых учетных записей и изменение административных прав, особенно если была включена автоматическая регистрация через обратный прокси.
• Учтите, что заголовок может не сохраниться в стандартном журнале доступа. При необходимости сопоставьте журналы обратного прокси, контейнера и самой Gitea.

Полезные ссылки

• Gitea Security Advisory GHSA‑f75j‑4cw6‑rmx4 // GitHub
• Gitea 1.26.3 and 1.26.4 are released // Gitea
• Critical Vulnerability in Gitea Docker // Cyber Security Agency of Singapore
• Threat Actors Probe Gitea Docker Flaw CVE‑2026‑20896 13 Days After Disclosure // The Hacker News

WP2Shell — цепочка из двух уязвимостей в ядре WordPress. CVE‑2026‑60137 связана с недостаточной фильтрацией параметра author__not_in в WP_Query и при определенных условиях допускает SQL‑инъекцию. CVE‑2026‑63030 возникает из‑за разной интерпретации маршрутов в batch‑обработчике WordPress REST API. Вместе они позволяют неаутентифицированному злоумышленнику перейти от SQL‑инъекции к удаленному выполнению кода.

Цепочка находится в ядре WordPress и не требует отдельного уязвимого плагина. Полностью она работает в WordPress 6.9.0–6.9.4 и 7.0.0–7.0.1. Ветка 6.8.0–6.8.5 подвержена CVE‑2026‑60137, но не полной цепочке WP2Shell в стандартной конфигурации.

Рекомендации по устранению уязвимости и снижению риска

• Обновите WordPress:
  • ветку 7.0 — до 7.0.2 или новее;
  • ветку 6.9 — до 6.9.5 или новее;
  • ветку 6.8 — до 6.8.6 или новее.
• Не полагайтесь только на принудительное автоматическое обновление, включенное WordPress.org. Проверьте фактическую версию каждого сайта, в том числе резервные экземпляры, тестовые площадки и давно не обслуживаемые сайты.
• Если обновить WordPress сразу нельзя, временно заблокируйте на WAF и на обратном прокси обращения к /wp‑json/batch/v1 и эквивалентному маршруту через параметр rest_route.
• Не ограничивайтесь блокировкой конкретного тела запроса: публичные варианты эксплуатации могут менять синтаксис и способ передачи параметров.
• Если сайт оставался доступен из интернета в уязвимом состоянии после 17 июля, проверьте его на компрометацию и смените административные пароли, учетные данные базы и ключи интеграций.
• Проверьте весь сервер, а не только WordPress: успешная RCE дает доступ за пределами данных отдельного сайта.

Советы по проверке следов эксплуатации

• Проверьте журналы веб‑сервера и WAF на наличие POST‑запросов к /wp‑json/batch/v1 и обращений вида ?rest_route=/batch/v1.
• Ищите в телах REST‑запросов нетипичное использование author__not_in, author_exclude и других параметров выборки авторов. Само наличие параметра еще не означает атаку — учитывайте источник, структуру запроса и последующие события.
• Проверьте, не появились ли новые администраторы WordPress, не изменились ли адреса электронной почты учетных записей и не было ли сбросов паролей без обращения владельца.
• Ищите новые и недавно измененные PHP‑файлы в wp‑content/uploads, wp‑content/mu‑plugins, активной теме и каталогах плагинов.
• Проверьте изменения в wp_options, неизвестные cron‑задачи, незнакомые плагины и механизмы автоматической загрузки кода.
• Ищите запуск шелл‑процессов и системных утилит дочерними процессами PHP‑FPM, Apache или веб‑сервера.
• Проверьте исходящие соединения с неизвестными адресами, загрузку исполняемых файлов и создание файлов за пределами каталога сайта.
• Обратите внимание на аномальные записи oEmbed‑кеша и другие изменения базы данных, созданные примерно во время подозрительных REST‑запросов.
• Проверьте целостность файлов ядра WordPress по официальным контрольным суммам. Обновление поверх скомпрометированной установки не удалит веб‑шеллы из каталогов контента.

Полезные ссылки

• WordPress 7.0.2 Security Release // WordPress
• CVE‑2026‑63030 Security Advisory // GitHub
• CVE‑2026‑60137 Security Advisory // GitHub
• CVE‑2026‑63030 Detail // NIST NVD
• CVE‑2026‑60137 Detail // NIST NVD
• Critical Vulnerability Chain in WordPress Core Under Exploitation (wp2shell) // NHS England
• wp2shell: Pre Authentication RCE in WordPress Core // Searchlight Cyber
• WordPress «WP2Shell» SQLi‑to‑RCE (CVE‑2026‑63030) Under Rapid Escalation // CrowdSec

BI.ZONE EASM помогает работать с критическими уязвимостями системно. Платформа автоматически сопоставляет новые CVE с внешними активами, выявляет уязвимые сервисы, приоритизирует риски с учетом эксплуатации в реальных атаках и позволяет контролировать их устранение до полного закрытия. Это сокращает время между публикацией уязвимости и принятием управленческого решения: пропатчить, ограничить доступ, изолировать сервис или провести дополнительную проверку.

Если инцидент подтвержден, команда BI.ZONE DFIR проводит полноценное реагирование, устанавливает механизм компрометации, определяет масштаб атаки и помогает локализовать ее последствия.