CVE

CVE-2025-5777 | CitrixBleed 2

Сегодня поговорим о CVE-2025-5777 (https://nvd.nist.gov/vuln/detail/CVE-2025-5777) — новой критической уязвимости в Citrix NetScaler, которая позволяет атакующему вытащить чувствительные данные прямо из памяти устройства без аутентификации на ресурсе.

Дата выхода: 20 мая 2026Время прочтения статьи: ~4 минуты

Вступление

Осенью 2023 года мир кибербезопасности столкнулся с новой утечкой, которую быстро окрестили Citrix Bleed — зловещее название, навеянное воспоминаниями о Heartbleed (легендарной уязвимости 2014 года). Вновь — публичный endpoint, ничем не защищённый доступ, и память сервера, “кровоточащая” чувствительными данными прямо в ответ на запросы злоумышленника.

Уязвимость была зарегистрирована как CVE-2023-4966 и затронула популярные решения Citrix NetScaler ADC и Gateway, используемые тысячами компаний по всему миру.

Всё, что требовалось атакующему — отправить особым образом сформированный POST-запрос, и получить в ответе фрагменты сырой памяти сервера.

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

CVE-2025-5777

В 2025 году в мир информационной безопасности явилась CVE-2025-5777, получившее название CitrixBleed 2.

Исследователи обнаружили, что в последних версиях Citrix NetScaler (ADC и Gateway) сохраняется возможность утечки памяти — только теперь через другой путь. Уязвимость кроется в обработке POST-запросов к маршруту

/p/u/doAuthentication.do

И в ответ на эти запросы Citrix вновь отдает фрагменты памяти.

Уязвимости подвержены:

NetScaler ADC and NetScaler Gateway 14.1 до 14.1-43.56
NetScaler ADC and NetScaler Gateway 13.1 до 13.1-58.32
NetScaler ADC 13.1-FIPS and NDcPP до 13.1-37.235-FIPS и NDcPP
NetScaler ADC 12.1-FIPS до 12.1-55.328-FIPS

Технический анализ

Эндпоинт принимает следующий набор параметров:

login=metascan&passwd=metascan&savecredentials=false&nsg-x1-logon-button=Log+On&StateContext=bG9qazxzY2hlbWE9ZGVmYXVsdA%3D%3D

При этом в ответе от сервера в поле InitialValue кроется юзернейм, с которым проходила попытка авторизации:

Код бекенда, занимающийся обработкой этого эндпоинта выглядит приблизительно следующим образом:

void FUN_00150df0 (long param_1, byte *param_2) {
<...>
    // указатель на строку login, *param – длина login
    // структура param_2 ограничивает логин в 127 символов
    // с использованием null-terminator
	param_2 (ulong) *param. 2 + 0x48] = 0;

	const char *postBack = (param_2[0x44] == 8 && (param_2[6] & 4)) ? 
		"/nf/auth/doAuthentication.do";
		"/p/u/doAuthentication.do";
    // ответ сервера собирается в формате XML
	uVar4 = FUN_11cdfa32 ( LVar7, 
		"«?xml version=\"1.0\"?><AuthenticateResponse><Status>success</Status>"
		"<Result>more-info</Result><StateContext>base64==</StateContext>"
		"«AuthenticationRequirements><PostBack>%s</PostBack><CancelPostBack>%s</CancelPostBack>"
		"«CancelButtonText>Cancel</CancelButtonText><Requirements>", 
		postBack, cancelBack);
    // в ответ сервера подставляется username
	iVar5 = FUN_11cdfa32 ((ulong) uVar4 + 1Var7, 
		"‹Requirement»«Credential><ID>login</ID><Type>username</Type></Credential»"
		"<Input><Text><InitialValue>%.*s</InitialValue></Text></Input></Requirement>", 
		*param_2, param_2 + 0x48);
<...>

Уязвимость возникает на этом этапе:

param_2 (ulong) *param_2 + 0x48] = 0;

Сервер получает POST-запрос, в котором должен быть передан параметр login. Далее:

Пытается распарсить этот параметр — то есть найти ключ login в форме.
Если ключ найден, даже без значения, код считает это успешным разбором формы.
После этого создаётся структура param_2, которая должна содержать данные, связанные с login.
Но если значение login отсутствует, вместо валидных данных структура начинает ссылаться на неинициализированную (или “соседнюю”) область памяти.
Буфер под это значение аллоцируется (от слова “allocation” — выделение ресурса, в данном случае оперативной памяти), и в него проставляется null-терминатор (это специальный байт со значением 0x00, который обозначает конец строки).
Как результат — вызывающий код считает, что это валидная строка, и возвращает до 127 байт случайного содержимого из памяти по этому адресу.

Влияние

Важно понимать, что в многопоточной среде веб-сервера содержимое этой неинициализированной памяти может разниться от запроса к запросу.

Это происходит потому, что выделение памяти (аллокация) обычно производится из общего пула памяти, и одна и та же область может быть повторно использована различными частями приложения между запросами.

В зависимости от предшествующих операций в процессе, утечка может содержать:

фрагменты HTTP-сессий пользователей:

данные POST/GET-параметров предыдущих запросов,

служебную информацию, хранящуюся в структуре TLS-сессии.

Таким образом, повторная отправка запроса к уязвимой конечной точке может привести к получению различного содержимого, что делает атаку недетерминированной, но крайне опасной.

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

Устранение

Для защиты от уязвимости Citrix Bleed (CVE-2025-5777) рекомендуется обновить программное обеспечение Citrix NetScaler (ADC) до последних версий, выпущенных производителем. В обновлениях была исправлена логика обработки параметров входящих запросов:

Добавлен строгий контроль и валидация параметров POST-запросов, чтобы исключить обработку пустых или некорректных значений.
Исправлена инициализация внутренних структур данных, что исключает использование неинициализированной памяти и предотвращает утечки.
Усилен общий контроль памяти и управление буферами для предотвращения чтения произвольных областей памяти.

Обновления доступны на официальном сайте Citrix и являются единственным надёжным способом предотвращения атаки. Самостоятельное исправление подобных глубоких проблем в проприетарных решениях практически невозможно и несет высокий риск нестабильности.

Заключение

Данная уязвимость показывает важность своевременного обновления программного обеспечения и тщательной проверки всех компонентов системы на предмет уязвимостей.

Для проверки уязвимости можно использовать следующие proof-of-concepts:

Шаблон и proof-of-concept для подтверждения уязвимости уже используются в Metascan, что, при своевременной реакции разработчиков, позволяет минимизировать шанс ее эксплуатации со стороны потенциального злоумышленника:

CVE-2025-5777 — наглядный пример того, как даже небольшие недочеты в обработке входящих данных могут привести к серьезным последствиям для безопасности.