Уязвимость в Delta Sql 1.8.2 попала в список приоритетных задач для security operations из-за простой и опасной цепочки: загрузка файлов без аутентификации, которая может привести к удалённому выполнению кода.
Что изменилось#
NVD указывает CVE-2018-25412 как Critical с оценкой CVSS 9.8. В записи назван затронутый продукт: Delta Sql 1.8.2.
Суть уязвимости — произвольная загрузка файлов в docs_upload.php. По описанию NVD, неаутентифицированный атакующий может отправлять специально подготовленные multipart form data в POST-запросах, загружать PHP-файлы с произвольным содержимым в каталог загрузки и выполнять эти файлы на сервере.
Эта цепочка важна, потому что проблема не заканчивается на уровне «приложение приняло плохой файл». Если загруженный PHP-файл доступен и выполняется веб-сервером, баг превращается в RCE. На практике сервер становится площадкой для выполнения кода атакующего, а не просто местом, куда попали лишние файлы.
Сама запись NVD не доказывает, что все установки Delta Sql уязвимы одинаково. Реальная экспозиция зависит от того, используется ли уязвимая версия, доступен ли docs_upload.php, как настроен каталог загрузки и разрешено ли там выполнение PHP. Это нужно проверять в инфраструктуре, а не принимать на веру.
Почему это важно для эксплуатации и реагирования#
Такой CVE стоит быстро триажить: условия со стороны атакующего, описанные NVD, слабые. Атакующему не нужна аутентификация. Путь запроса конкретный. Тип файла опасен для PHP-приложения. Последствие — удалённое выполнение кода.
Эта комбинация поднимает проблему выше обычного шума в бэклоге. Многие CVE требуют локального доступа, действий пользователя, редкой конфигурации или хрупкой цепочки эксплуатации. Здесь описание ближе к хорошо знакомому риску для веб-приложений: загрузить скрипт, обратиться к нему, выполнить код.
Риск для приватности вытекает из того же факта. RCE может поставить под угрозу данные приложения, учётные данные базы, локальные файлы, логи и подключённые сервисы. Короткое описание NVD не перечисляет сценарии утечки данных, поэтому нельзя утверждать конкретный факт компрометации только по этой записи. Но если произвольное выполнение серверного кода правдоподобно, конфиденциальность и целостность нужно учитывать при планировании реакции.
Для безопасности open source полезный вывод не в том, что «старое ПО опасно». Он уже и практичнее: пакет может выглядеть тихим, пока конкретный уязвимый endpoint не превращает его в кандидата на инцидент. Инвентаризация версий и проверка доступных endpoint важнее расплывчатой уверенности, что небольшой инструмент, скорее всего, безвреден.
Что проверить до действий по CVE#
Начните с доказательства наличия. Не тратьте время на спор о серьёзности, пока не понятно, есть ли Delta Sql 1.8.2 в вашей среде.
Проверки должны быть конкретными:
- Найдите Delta Sql в инвентарях приложений, container images, VM-сборках и старых веб-каталогах.
- Подтвердите, что развёрнутая версия — 1.8.2.
- Проверьте, существует ли
docs_upload.phpи доступен ли он из недоверенных сетей. - Посмотрите правила веб-сервера для каталога загрузки. В каталоге для загруженных файлов выполнение PHP должно быть запрещено.
- Найдите неожиданные PHP-файлы или недавно изменённые файлы в upload path.
- Проверьте web access logs на POST-запросы к
docs_upload.php, особенно попытки multipart upload. - Если продукт доступен извне, ограничьте доступ на время установки исправления или удаления уязвимого развёртывания.
Если есть поддерживаемое исправление, самый чистый путь — обновление. Если быстро обновиться нельзя, сначала снижайте экспозицию: заблокируйте публичный доступ к затронутому endpoint, поместите приложение за аутентификацию или сетевые ограничения, отключите выполнение скриптов в каталогах загрузки. Эти меры не заменяют исправление, но уменьшают поверхность атаки, пока владелец выбирает правильную ремедиацию.
Командам также стоит использовать этот случай как проверку собственного процесса работы с CVE. Critical CVSS полезен, но это не готовый операционный план. Практичный вопрос звучит так: может ли команда перейти от CVE-алерта к сопоставлению с активами, проверке экспозиции, просмотру логов и mitigation без ручной археологии?
Материалы GigaTap по теме: апрельский сигнал OpenSSF: артефакты безопасности должны работать в операциях, 100% package test coverage — цель, а не лозунг и безопасности open source нужно больше, чем код.
Чего не стоит утверждать#
Текст NVD подтверждает серьёзный риск эксплуатации. Но он не подтверждает все заявления, которые люди часто прикрепляют к Critical CVE.
Не утверждайте активную эксплуатацию, если нет отдельного источника. Не называйте конкретную версию с исправлением без информации от вендора или проекта. Не заявляйте, что все установки Delta Sql доступны из интернета. Не выводите факт кражи данных только из описания CVE.
Достаточно сильного и точного вывода: CVE-2018-25412 описывает неаутентифицированную произвольную загрузку PHP-файлов в Delta Sql 1.8.2 с путём к RCE. Этого хватает, чтобы быстро проверить экспозицию, изучить логи и исправить или изолировать затронутые системы.
Слабая реакция — переслать оценку CVSS и считать задачу закрытой. Полезная реакция — ответить на четыре вопроса: используем ли мы это, доступен ли уязвимый endpoint, может ли загруженный PHP выполняться, и есть ли в логах подозрительные попытки загрузки?