FreeRDP: критическая уязвимость с опубликованным эксплойтом

БДУ ФСТЭК добавила запись BDU:2026-18435 о критической уязвимости RDP-клиента FreeRDP. Ошибка записи за границы буфера при обработке набора возможностей кэша растровых изображений позволяет удалённому атакующему повлиять на конфиденциальность и целостность данных или вызвать отказ в обслуживании. По данным БДУ, эксплойт уже опубликован, поэтому обновлять нужно сам RDP-клиент на рабочих местах, в Linux- и Windows-сборках и во встроенных компонентах, а не только ограничивать сетевой доступ.

Что известно об уязвимости

FreeRDP - свободная реализация протокола RDP. Клиент используют в Linux, Windows и встроенных сборках. БДУ ФСТЭК добавила запись BDU:2026-18435 11 ноября 2026 года. Уязвимость получила CVE-2026-121952 и GHSA-xc85-4mqc-xgcx. Оценка по CVSS 3.1 - 9,8, по CVSS 4.0 - 9,3. БДУ относит её к критическому уровню опасности.

Речь идёт об ошибке записи за границы буфера в функции rdp_read_bitmap_cache_v2_capability_set(). Она срабатывает при разборе специально сформированного набора возможностей bitmap cache. Производитель подтвердил проблему и выпустил исправление в версии 3.32.2. Затронуты версии FreeRDP до 3.32.1 включительно.

Отдельно в записи отмечен публичный эксплойт. Это меняет приоритет: проблему можно воспроизвести по открытым материалам, а не искать редкий сценарий. Поэтому обновление клиента становится задачей не только для лабораторий и тестовых стендов.

Где ошибка

Функция читает данные capability set, то есть набора параметров, которым стороны RDP обмениваются при установке сессии. В этом наборе описываются параметры кэша растровых изображений. При определённом сочетании полей клиент вычисляет размер или смещение в буфере и выполняет запись за его пределами.

Запись за границы буфера - это не просто чтение лишних данных. Программа меняет память, которая ей не принадлежит. Что именно будет перезаписано, зависит от раскладки памяти в конкретном процессе. Последствия могут проявиться как утечка данных, повреждение информации или аварийное завершение клиента. БДУ перечисляет именно эти три класса последствий: конфиденциальность, целостность и отказ в обслуживании.

Важно, что ошибка находится в клиентской части. Она не требует, чтобы на машине пользователя работал RDP-сервер. Достаточно, чтобы клиент обработал данные в рамках подключения. Это отличает ситуацию от привычного сценария, когда администраторы закрывают входящий порт RDP на периметре.

Условия эксплуатации

По записи БДУ, атака удалённая, а способ эксплуатации - манипулирование структурами данных. Атакующему нужно передать клиенту специально сформированный набор возможностей bitmap cache. На практике это означает, что данные приходят в клиент в рамках RDP-сессии, которую инициирует пользователь. В источнике не описаны требования к учётной записи и действиям пользователя. Для срабатывания не нужен локальный доступ к машине и права администратора: ошибка возникает на этапе разбора сетевых данных.

Сценарий особенно неприятен для рабочих станций, которые подключаются к внешним и недоверенным RDP-серверам. Если сотрудник использует FreeRDP для администрирования чужих систем, его клиент становится точкой обработки потенциально опасных данных. При этом защита только на стороне RDP-сервера не закрывает ошибку в клиенте.

Что получает атакующий

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

Выполнение кода в записи не заявлено. Это не отменяет опасности: ошибки записи за границы буфера часто относят к классу, который может привести к более серьёзным последствиям при удачном для атакующего раскладе. Но при планировании защиты нужно опираться на подтверждённые последствия, а не на предположения. Публичный эксплойт повышает вероятность попыток эксплуатации.

Затронутые версии и исправление

Уязвимы версии FreeRDP до 3.32.1 включительно. Исправление вышло в 3.32.2. Производитель подтвердил уязвимость и закрыл её обновлением. Обновляться нужно до 3.32.2 или более новой версии.

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

В Linux-системах имеет смысл проверить версию через пакетный менеджер и отдельно - через файлы, которые реально использует приложение. В Windows-сборках проверка зависит от способа поставки: иногда FreeRDP приходит вместе с программой и не отображается как отдельный компонент. В таких случаях ориентироваться нужно на версию самого приложения и уведомление поставщика.

Кого затрагивает в первую очередь

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

Отдельно нужно посмотреть тонкие клиенты и прикладные сборки. В них FreeRDP может поставляться вместе с программой и обновляться не через системный пакетный менеджер. Также стоит проверить автоматические сценарии, где клиент используется без участия человека: там сложнее заметить аварийное завершение или странное поведение.

Если обновиться нельзя

Полноценной замены патчу нет. Временная мера - ограничить подключения к недоверенным RDP-серверам и снизить число систем, где FreeRDP используется для внешних сессий. Для критичных сегментов можно временно запретить исходящие RDP-подключения через этот клиент или запускать его в изолированной среде. Эти меры уменьшают поверхность атаки, но не исправляют ошибку разбора данных.

Сетевые ограничения на стороне RDP-сервера сами по себе не помогут. Проблема находится в клиенте, поэтому обновлять нужно именно его. Если в организации есть собственные сборки, стоит проверить зависимости и пересобрать приложения с исправленной версией библиотеки. После обновления полезно провести проверку на тестовом стенде: подключиться к обычному RDP-серверу и убедиться, что клиент работает стабильно.