SolidLab — Практическая кибербезопасность

⚠️ Две критические уязвимости в PHP: CVE-2026-109618 и CVE-2026-109619

21 октября раскрыта информация о двух критических уязвимостях PHP, получивших оценку 9,2 по CVSS 4.0.

Учитывая распространённость PHP, под угрозой могут оказаться практически любые веб-приложения — от корпоративных порталов до публичных сервисов.

Что известно об уязвимостях?
Обе проблемы относятся к классу Use-After-Free (UAF) и связаны с механизмом session.upload_progress.
Суть UAF в том, что приложение продолжает обращаться к области памяти после её освобождения. При определённых условиях атакующий может повлиять на её содержимое и добиться выполнения произвольного кода.
В открытом доступе уже появились технические разборы и PoC, позволяющие воспроизводить сценарии эксплуатации.

Что мы предлагаем со стороны SolidLab?

Наши специалисты уже подготовили защиту от распространённых сценариев эксплуатации

🛡 SolidWall WAF отсекает вредоносные запросы еще до того, как они дойдут до уязвимого приложения. Для защиты от CVE-2026-109618/619 выпущено правило для модуля сигнатурного анализа, которое ловит типовые варианты атаки по характерным признакам в теле запроса. Это значительно снижает риски успешных атак по распространенным в открытом доступе пейлоадам, однако из-за application specific стека PHP нестандартная доставка полезной нагрузки или другие кастомные вариации пейлоадов могут быть пропущены этим специфическим правилом. В случаях попыток эксплуатации данной уязвимости при помощи PHP Object Injection (Deser) и LFI SolidWall WAF имеет защиту в виде правил, идущих в стандартной поставке. После релиза официального патча работа над улучшениями защиты посредством специфических правил под данную уязвимость будет продолжена.

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

🔎 Для нашего сканера уязвимостей также готовим обновление, позволяющее выявлять потенциально уязвимые системы.

Что рекомендуем сделать?
1. Обновление PHP: установить исправленную версию сразу после выхода релиза и перезапустить PHP-FPM / веб-сервер.
2. Временная мера: рассмотреть возможность отключения е session.upload_progress.enable (но не считать её полноценной защитой).
3. Неподдерживаемые версии: запланировать переход на поддерживаемую ветку; до перехода ограничить доступ к ресурсу (VPN, allowlist).
4. Мониторинг: отслеживать нетипичные дочерние процессы PHP-FPM / веб-сервера и новые файлы в web root.

Важно: WAF помогает снизить вероятность успешной эксплуатации известных сценариев атак, но не устраняет саму уязвимость. Поэтому установка исправлений остаётся приоритетной задачей.

@channel_solidlab

🦆 Миграция сервисов: что происходит с защищённостью внешнего периметра?

Мы изучили, как происходит перенос сервисов из собственной (on-premise) инфраструктуры в облако и из зарубежных аналогов в российские, и вот что можем рассказать:

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

Мы замечаем открытые служебные порты, ошибки конфигурации, восстановление из бэкапов устаревших версий системного и прикладного ПО и т.п.

Как проверить защищённость инфраструктуры после переноса?
В SolidLab предлагаем два формата проверки:

🔎 Разовое сканирование SolidLab VMS
В основе — автоматизированное сканирование инфраструктуры, веб-приложений и API на уязвимости, проверка открытых портов и небезопасных конфигураций.
При этом мы не ограничиваемся техническим отчётом, а проводим дополнительный ручной триаж выявленных уязвимостей, чтобы определить реальные риски и приоритеты их устранения.
Сканирование возможно как по заданному перечню активов (скоупу), так и с предварительной разведкой внешней поверхности атаки модулем EASM (External Attack Surface Management).

🔬 Чекап внешнего периметра
Это не просто инструментальное сканирование с ручным триажем, здесь в основе — экспертный ручной анализ защищённости силами SolidLab RedTeam с фокусом на критичные риски.
В рамках чекапа мы анализируем возможные сценарии атак со стороны внешнего нарушителя и проверяем возможность эксплуатации выявленных уязвимостей.
По результатам предоставляется отчёт с подтверждёнными сценариями атак, оценкой рисков и рекомендациями по устранению проблем.
Чекап проводится в согласованных границах и занимает 2–3 недели. При этом о критических уязвимостях сообщаем сразу, не дожидаясь итогового отчёта.

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

Обсудить состав проверяемых активов и подходящий формат можно через форму на сайте - https://solidlab.ru/#contact или по почте info@solidlab.ru

@channel_solidlab

🛡 SolidWall 2.20: научили WAF разбираться в gRPC

Вышла новая версия SolidWall WAF, и вот главные вещи, на которые стоит обратить внимание:

Теперь SolidWall анализирует gRPC-трафик.
WAF может разбирать запросы и ответы внутри бинарных gRPC-пакетов и искать там SQL-инъекции, XSS и другие попытки эксплуатации.
Особенно актуально для микросервисных приложений и инфраструктуры в Kubernetes, где gRPC всё чаще используется для общения сервисов между собой.

Добавили CSP-заголовки.
SolidWall может добавлять Content Security Policy к ответам приложения — ещё один слой защиты от внедрения и выполнения нежелательного кода в браузере.

Появилась поддержка Yandex SmartCaptcha.
Теперь подозрительный запрос не обязательно сразу блокировать: пользователя можно дополнительно проверить с помощью CAPTCHA.

Плюс в релизе: поддержка Astra Linux 1.8, улучшения стабильности, метрик и обработки аномалий.

Подробнее - https://solidlab.ru/news/solidwall-2-20.html

@channel_solidlab

🔐 PAM-система должна контролировать привилегированный доступ к инфраструктуре.
Но что будет, если уязвимость найдётся в ней самой?

Наш эксперт Сергей Герасимов обнаружил критическую уязвимость в open-source платформе JumpServer PAM.
Пользователь с минимальными правами мог получить токены подключения других пользователей.
А дальше — потенциально доступ к системам, которые организация публикует через JumpServer.

Получается неприятная цепочка:
обычный пользователь →
чужой токен →
привилегированный доступ →
другие активы инфраструктуры

Уязвимость получила CVSS 9.6 и идентификатор CVE-2025-62712.
После передачи информации разработчикам исправление вышло уже на следующий день.
И хороший повод напомнить: средства защиты — тоже часть поверхности атаки.

И проверять их иногда нужно не меньше, чем системы, которые они защищают.

Подробнее - https://solidlab.ru/news/ekspert-solidlab-obnaruzhil-seriyu-kritichnyh-uyazvimostey-v-jumpserver-pam.html

@channel_solidlab

🔎 Самая опасная часть периметра — та, о которой забыли

На практике встречали такое - когда-то команда подняла тестовый сервис на отдельном поддомене. Проект закончился, люди сменились, а test.company.ru остался жить.

Основной сайт защищён. WAF настроен. Сканирования идут регулярно.
А старый сервис всё ещё доступен из интернета — со старой админкой, уязвимой версией ПО или забытым аккаунтом.

Для атакующего цепочка может быть очень короткой:
забытый актив → уязвимость → первоначальный доступ → движение дальше

Поэтому безопасность внешнего периметра начинается с простого вопроса:
«Мы точно знаем всё, что доступно от нашего имени из интернета?»

Домены, поддомены, IP, облака, тестовые стенды, VPN, панели управления, сервисы подрядчиков — всё это часть поверхности атаки.
Сначала актив нужно найти.
Потом понять, чей он.
И только потом — оценивать его риск ✅

@channel_solidlab