Splunk CVE-2026-20253: Неавторизований RCE через PostgreSQL Sidecar

Будь-який platform-інженер, який колись розміщував Splunk за внутрішнім балансувальником навантаження, щойно втратив вихідні. CVE-2026-20253 — це тип розкриття вразливості, який перетворює п'ятничний стендап на екстрений тікет зі змінами. PostgreSQL sidecar поставлявся без автентифікації, двох REST-ендпоінтів та чистого шляху від неавторизованого мережевого доступу до віддаленого виконання коду від імені користувача Splunk.

Splunk, нині частина Cisco, випустила виправлення цього тижня. watchTowr Labs у п'ятницю опублікувала повний ланцюжок експлойту. Активного використання вразливості в реальних атаках поки не зафіксовано, але технічний опис настільки детальний, що опортуністичне сканування — справа днів, а не місяців.

Що сталося

Splunk випустила оновлення безпеки для критичної вразливості в Splunk Enterprise, що відстежується як CVE-2026-20253 з оцінкою 9.8 за CVSS. Як повідомляє The Hacker News, помилка дозволяє неавторизованим користувачам виконувати файлові операції та віддалене виконання коду через ендпоінт PostgreSQL sidecar-сервісу без контролю автентифікації.

За словами самого Splunk, «неавторизований користувач може створювати або усікати довільні файли через ендпоінт PostgreSQL sidecar-сервісу» у версіях нижче 10.2.4 та 10.0.7. Splunk Enterprise від 10.0.0 до 10.0.6 виправлено у версії 10.0.7. Версії від 10.2.0 до 10.2.3 виправлено у версії 10.2.4. Версія 10.4 не є вразливою. Splunk Cloud також поза зоною ризику, оскільки PostgreSQL sidecar у цьому продукті не використовується.

Технічні деталі надали дослідники watchTowr Labs — Пьотр Базидло та Йордан Ганчев — які опублікували ланцюжок у п'ятницю. Два вразливих ендпоінти — /v1/postgres/recovery/backup та /v1/postgres/recovery/restore — відкриті без автентифікаційних даних. Далі зловмисник підключає резервний ендпоінт до контрольованої ним бази даних, завантажує дамп на файлову систему Splunk і відтворює його через restore. Крок відновлення приймає аргумент passfile, що вказує на /opt/splunk/var/packages/data/postgres/.pgpass, де зберігається пароль для користувача postgres_admin.

Це надає можливість виконувати SQL-запити всередині локального PostgreSQL-екземпляра. Далі зловмисник використовує lo_export для запису контенту, що ним контролюється, у будь-яке місце на диску. Фінальний перехід до RCE є тривіальним: перезаписати Python-скрипт, який Splunk виконує регулярно — у proof of concept це файл /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py — і просто чекати. Жодних облікових даних. Жодних дій від користувача. Жодного ланцюжка CVE не потрібно.

Технічна анатомія

Структура цієї вразливості до болю знайома. Команда створює мікросервіс із чистим HTTP API для внутрішньої оркестрації, вважає мережевий периметр межею автентифікації й відправляє в продакшн. PostgreSQL sidecar у Splunk Enterprise — це саме такий патерн. Ендпоінти резервного копіювання та відновлення, розроблені для внутрішніх workflows відновлення, відкриті на порту, доступному для будь-якого хосту, який може зв'язатися з вузлом Splunk.

Перший крок ланцюжка: зловмисник розгортає PostgreSQL-екземпляр, налаштований для автентифікації без пароля, з правами, достатніми для виклику lo_export. Другий крок: звертається до /v1/postgres/recovery/backup на цільовому хості, вказуючи його на базу даних зловмисника. Sidecar Splunk охоче завантажує вміст віддаленої БД на локальну файлову систему. Третій крок: звертається до /v1/postgres/recovery/restore з аргументом passfile, що вказує на локальний .pgpass, завдяки чому процес відновлення отримує пароль для postgres_admin на локальному екземплярі.

Під час відновлення SQL з цього дампу виконується проти локального PostgreSQL. Дослідники сформували дамп, який визначає функцію, що викликає lo_export: вона витягує великий бінарний об'єкт і записує його як файл. Це надає примітив довільного запису файлу з привілеями PostgreSQL-процесу Splunk. Як відзначають Базидло та Ганчев: «Щойно ми змогли відновити контрольований зловмисником SQL у локальний PostgreSQL-екземпляр, ми швидко зібрали шаблон дампа бази даних, що надав нам контрольований запис файлу».

Ескалація до RCE — найпростіша частина. Splunk Secure Gateway виконує Python-скрипти за власним розкладом. Перепишіть ssg_enable_modular_input.py, дочекайтеся наступного виклику — і ваш payload запуститься в контексті Splunk. Весь ланцюжок є механічним. Жодного пошкодження пам'яті, жодних race conditions, жодних екзотичних примітивів. Це саме той тип експлойту, який перетворюється на модуль Metasploit протягом тижня. Відстежуйте запис у базі MITRE CVE для отримання подальших рекомендацій.

Хто постраждає найбільше

Splunk Enterprise знаходиться в центрі detection pipeline банків, бірж, iGaming-операторів, рекламних мереж та більшості SOC-команд зі списку Fortune 500. У цьому й полягає болісна суть. Система, якій ви довіряєте повідомляти про інциденти, сама є вразливою ціллю. За моїм досвідом виробничих інцидентів: коли падає стек логування або observability, blue team втрачає видимість саме в той момент, коли вона потрібна найбільше. Зловмисники знають це. Pre-auth RCE у Splunk — це не ціль для крадіжки облікових даних; це ціль «засліпити захисників».

Оцінка 9.8 за CVSS — не маркетинг. Вона відповідає мережевому вектору атаки, відсутності привілеїв, відсутності взаємодії з користувачем і повному впливу на конфіденційність, цілісність і доступність. Для регульованого iGaming-оператора, що використовує Splunk як систему обліку активності гравців, ця оцінка означає аварійне навчання щодо відповідності вимогам. Аудитори захочуть знати терміни встановлення патчів, мережеву доступність уражених портів і чи відбувалися несподівані записи файлів у дереві /opt/splunk/etc/apps/.

Команди, що використовують Splunk Cloud, тут можуть не хвилюватись. PostgreSQL sidecar у цьому продукті не використовується. Усі, хто на self-hosted Enterprise від 10.0.0 до 10.0.6 або від 10.2.0 до 10.2.3, мають роботу. Версія 10.4 не є вразливою до цього CVE.

Моя думка: найбільше постраждають оператори, які вважають Splunk «внутрішньою» інфраструктурою і ніколи не розміщували його за справжнім auth-проксі або політикою мережевої сегментації. Команди, з якими я працював, регулярно залишають порти індексера та управління доступними через плоскі VLAN, бо «це за файрволом». Саме це припущення і карає даний CVE. Якщо ваш вузол Splunk доступний з ноутбука розробника — він доступний і з ноутбука зламаного розробника.

План дій для команд безпеки

Спочатку патч, потім розслідування, потім рефакторинг. Невтішна правда: якщо ви досі використовуєте 10.0.x або 10.2.x з відкритим вразливим sidecar, вважайте, що термін опортуністичного сканування — дні, а не тижні. Опис watchTowr достатньо детальний, щоб робота над експлойтом була фактично завершена.

Дії на цей тиждень:

• Негайно оновіть Splunk Enterprise до 10.0.7, 10.2.4 або 10.4. Для виробничих індексерів жодного вікна staging довше 48 годин.
• Перевірте мережеву доступність ендпоінтів PostgreSQL sidecar. Два шляхи для пошуку в логах файрволу та WAF: /v1/postgres/recovery/backup та /v1/postgres/recovery/restore.
• Хешуйте та відстежуйте вміст /opt/splunk/etc/apps/splunk_secure_gateway/bin/ та суміжних директорій додатків. Будь-яка несподівана зміна ssg_enable_modular_input.py є індикатором компрометації.
• Перевірте наявність несподіваних файлів, записаних у шляхах, доступних користувачу Splunk. Вразливість надає довільний запис файлів, а не лише один скрипт, що є ціллю в PoC.
• Щодня звіряйтеся з каталогом CISA KEV для отримання оновлень щодо статусу активної експлуатації.

На наступні 90 днів структурним рішенням є сегментація. Індексери та пошукові вузли Splunk не повинні бути доступними на management-портах із загальних корпоративних мереж. Розмістіть їх за bastion-хостом або service mesh, що забезпечує mTLS. Вважайте кожен внутрішній sidecar публічним ендпоінтом за замовчуванням — саме так приземлиться наступна подібна вразливість.

Ключові висновки

• CVE-2026-20253 — це pre-auth RCE з оцінкою 9.8 CVSS у PostgreSQL sidecar Splunk Enterprise. Оновіться до 10.0.7, 10.2.4 або 10.4.
• Ланцюжок експлойту використовує /v1/postgres/recovery/backup та /v1/postgres/recovery/restore разом із lo_export для довільного запису файлів, після чого перезаписує запланований Python-скрипт для виконання коду.
• Splunk Cloud не є вразливим. Постраждали self-hosted Enterprise-користувачі у відповідних діапазонах версій.
• Активної експлуатації в реальних атаках поки не зафіксовано, але публічні технічні деталі watchTowr роблять опортуністичне сканування ймовірним протягом найближчих днів.
• Вважайте внутрішні sidecar-сервіси ненадійними за замовчуванням. Мережева позиція — це не автентифікація, і цей CVE є тому доказом.