Як CVE-2026-20253 у Splunk Enterprise веде до pre-auth RCE

Splunk випустив екстрені оновлення безпеки для усунення критичної вразливості CVE-2026-20253 з оцінкою CVSS 9.8 у продукті Splunk Enterprise. Вразливість дозволяє неавтентифікованому зловмиснику створювати й усікати довільні файли через незахищений ендпоінт PostgreSQL sidecar, що, за даними дослідників із watchTowr Labs, може бути розвинено до повноцінного віддаленого виконання коду (RCE) без попередньої автентифікації. Уражені версії 10.0.0–10.0.6 і 10.2.0–10.2.3; виправлення доступні у версіях 10.0.7 і 10.2.4. Splunk Cloud не вразливий до цієї вразливості. З огляду на публікацію технічних деталей експлуатації, оновлення слід розглядати як першочергове завдання.

Суть вразливості

Відповідно до офіційного бюлетеня Splunk, коренева причина проблеми — повна відсутність автентифікації на ендпоінті PostgreSQL sidecar. Будь-який користувач, який має мережевий доступ до вразливого екземпляра Splunk Enterprise, може викликати файлові операції без надання облікових даних. Вендор формулює це так: неавтентифікований користувач може створювати або усікати довільні файли через сервісний ендпоінт 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 Cloud — не вразливий (PostgreSQL sidecar не використовується в хмарному продукті)

Ланцюжок експлуатації: від запису файлів до RCE

Дослідники Пьотр Бази́дло та Йордан Ганчев із watchTowr Labs опублікували детальний технічний аналіз, що описує шлях від примітива запису файлів до повноцінного виконання довільного коду. Важливо зазначити: вендорський бюлетень підтверджує можливість неавтентифікованих файлових операцій, тоді як повний ланцюжок RCE описаний дослідниками й поки що не підтверджений незалежно.

За даними дослідників, атака використовує два ендпоінти:

• /v1/postgres/recovery/backup — для підключення до контрольованої зловмисником бази даних і скидання її вмісту в довільний файл у файловій системі Splunk
• /v1/postgres/recovery/restore — для завантаження шкідливого дампа в локальний екземпляр PostgreSQL з використанням параметра passfile, що вказує на файл /opt/splunk/var/packages/data/postgres/.pgpass, який містить пароль користувача postgres_admin

Ключовий елемент атаки — SQL-запити, вбудовані в дамп бази даних, виконуються екземпляром PostgreSQL у процесі відновлення. Це дає змогу зловмиснику визначити користувацьку функцію, що використовує lo_export — штатний механізм PostgreSQL для експорту великих об’єктів (BLOB) у файли на диску. Через цю функцію зловмисник отримує примітив контрольованого запису довільного вмісту у файлову систему.

Для ескалації до виконання коду, за даними watchTowr Labs, достатньо перезаписати Python-скрипт, який Splunk регулярно виконує — наприклад, /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py. Після перезапису шкідливий код виконується в контексті процесу Splunk.

Повна послідовність атаки

1. Зловмисник створює зовнішню базу даних PostgreSQL з конфігурацією, що допускає автентифікацію без пароля, і надає достатні привілеї для виклику функцій на кшталт CREATE FUNCTION та lo_export
2. Через ендпоінт /backup дамп цієї бази розміщується у файловій системі Splunk
3. Через ендпоінт /restore шкідливий дамп завантажується в локальний PostgreSQL, під час відновлення спрацьовує шкідлива функція, що записує контрольований зловмисником Python-скрипт на диск

Оцінка впливу

Splunk Enterprise — одна з найпоширеніших SIEM-платформ, яка використовується для агрегації та аналізу журналів безпеки в організаціях будь-якого масштабу. Компрометація SIEM-системи становить особливу загрозу: зловмисник отримує не лише контроль над сервером, а й потенційний доступ до журналів безпеки всієї інфраструктури, що може бути використано для планування подальших атак і приховування слідів.

Оцінка CVSS 9.8 відображає критичність: атака не вимагає автентифікації, може бути проведена віддалено й призводить до повної компрометації конфіденційності, цілісності та доступності. Найбільшому ризику піддаються організації, чиї екземпляри Splunk Enterprise доступні з недовірених мережевих сегментів.

На момент публікації підтверджених випадків експлуатації в реальних атаках не зафіксовано, а вразливість не внесена до каталогу CISA KEV. Водночас публікація детального технічного опису ланцюжка експлуатації суттєво підвищує ймовірність опортуністичних атак у найближчі дні.

Рекомендації

• Негайно оновіть Splunk Enterprise до версій 10.0.7 або 10.2.4 залежно від використовуваної гілки
• Обмежте мережевий доступ до ендпоінтів /v1/postgres/recovery/backup і /v1/postgres/recovery/restore засобами мережевого сегментування та міжмережевих екранів — як тимчасовий захід до оновлення
• Перевірте цілісність Python-скриптів у каталозі /opt/splunk/etc/apps/, зокрема файла ssg_enable_modular_input.py, на предмет несанкціонованих змін
• Проаналізуйте журнали доступу до PostgreSQL sidecar на наявність звернень до зазначених ендпоінтів від неавторизованих джерел
• Якщо використовується Splunk Enterprise версії 10.4 або Splunk Cloud — оновлення не потрібне, ці продукти не вразливі

Поєднання максимальної критичності (CVSS 9.8), відсутності потреби в автентифікації та публічно доступного опису повного ланцюжка експлуатації робить CVE-2026-20253 однією з пріоритетних вразливостей для негайного усунення. Організаціям, які використовують уражені версії Splunk Enterprise, слід застосувати оновлення в межах екстреного циклу патчування, не чекаючи планового вікна обслуговування, а до моменту оновлення — ізолювати PostgreSQL sidecar від недовірених мереж.