ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ

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

Уязвимость, обозначенная как CVE-2026-20253, получила оценку 9,8 по шкале CVSS.

«В версиях Splunk Enterprise ниже 10.2.4 и 10.0.7 неавторизованный пользователь мог создавать или обрезать произвольные файлы через конечную точку службы PostgreSQL sidecar», — сообщила компания Splunk в предупреждении на этой неделе.

«Уязвимость существует из-за отсутствия средств контроля аутентификации в конечной точке службы PostgreSQL sidecar, что позволяет любому пользователю, имеющему доступ к сети, вызывать файловые операции без учетных данных».

Проблема устранена в следующих версиях:

Splunk Enterprise 10.0.0–10.0.6 — исправлено в версии 10.0.7

Splunk Enterprise 10.2.0–10.2.3 — исправлено в версии 10.2.4

Splunk Enterprise 10.4 — не затронута

Компания Splunk, входящая в состав Cisco, заявила, что уязвимость не затрагивает Splunk Cloud, поскольку в этом продукте не используются сайдкары Postgres.

В пятницу watchTowr Labs опубликовала дополнительные технические детали CVE-2026-20253, заявив, что она может быть использована для удаленного выполнения кода без предварительной аутентификации на уязвимых системах через конечные точки «/v1/postgres/recovery/backup» и «/v1/postgres/recovery/restore».

Цепочка атаки работает следующим образом:

Подключиться к базе данных, контролируемой злоумышленником, и скопировать ее содержимое в произвольный файл, используя конечную точку /backup

Загрузите дамп базы данных, контролируемой злоумышленником, в локальный экземпляр PostgreSQL с использованием конечной точки /restore, включив аргумент «passfile», который указывает путь к файлу «.pgpass» («/opt/splunk/var/packages/data/postgres/.pgpass»), содержащий пароль пользователя «postgres_admin»

SQL-запросы, определенные в дампе базы данных, будут выполняться экземпляром PostgreSQL в Splunk

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

«На этом этапе мы можем пройти аутентификацию, восстановить SQL-код, контролируемый злоумышленником, и взаимодействовать с локальной базой данных», — заявили исследователи в области безопасности Петр Базидло и Йордан Ганчев. «Как только нам удалось восстановить SQL-код, контролируемый злоумышленником, в локальном экземпляре PostgreSQL, мы быстро создали шаблон дампа базы данных, который обеспечил нам контролируемую запись файлов».

Вооружившись примитивом произвольной записи файлов в файловой системе Splunk, злоумышленник мог бы перейти к удаленному выполнению кода, перезаписав скрипт Python, который Splunk часто выполняет (например, «/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py»), чтобы включить в него вредоносную полезную нагрузку.

Полная последовательность действий приведена ниже —

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

Используйте конечную точку /backup, чтобы загрузить дамп удаленной базы данных в файловую систему Splunk

Используйте конечную точку /restore для загрузки вредоносного дампа базы данных, запуска выполнения вредоносной функции во время процесса восстановления и записи контролируемого злоумышленником скрипта на Python в файловую систему Splunk

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