したがって、ALAS2023-2026-2012 のアドバイザリに記載されている複数の脆弱性の影響を受けます。

    AVC444 YUV バッファ割り当てのヒープバッファオーバーフロー書き込み

    libfreerdp/codec/h264.c では、avc444_ensure_buffer() が UINT32 演算を用いて、AVC444 YUV444 中間バッファのサイズを piDstSize[x] = piDstStride[x] * padDstHeight として計算します。実際の積が UINT32_MAX を超えると、値はゼロ以外の小さな整数にラップされます。唯一のガードは if (piDstSize[x] == 0) return FALSE であるため、ゼロ以外のラップは通過してしまいます。その後、winpr_aligned_recalloc() が著しく小さいバッファを割り当て、yuv444_context_decode() → YUV420CombineToYUV444() が実際のストライドと矩形の寸法を使用して書き込みを行うため、ヒープバッファオーバーフローによる書き込みが発生します。

    498-499 行での再割り当てトリガーは、1ull * piMainStride[0] * padDstHeight (64 ビット) との比較が正しく行われていますが、504 行目の割り当てでは依然として 32 ビットの乗算が使用されています。(CVE-2026-55191)

    H.264 YUV から RGB への変換における、デコーダー/サーフェス寸法の不一致による領域外読み取り

    h264->subsystem->Decompress() が返された後、すべての主要な H.264 バックエンドは、H.264->pYUVData および h264->iStride を、H.264 ビットストリーム SPS によりサイズされたデコーダー内部 YUV バッファで上書きします。これらの寸法は、h264->width / h264->height に格納されている RDPGFX サーフェスの寸法とは一切比較されません。

    areRectsValid() は、avc420_decompress() / avc444_decompress() に渡されたサーフェスの幅/高さに対して、領域の矩形が有効かどうかを検証します。その後の YUV-RGB 変換 (yuv420_context_decode - avc420_yuv_to_rgb または avc444_yuv_to_rgb) では、これらのサーフェスサイズの矩形が、より小さいデコーダーサイズの YUV プレーンに対して適用されるため、両軸で領域外読み取りが発生します。

    clamp() は、srcHeight が h264->height (FFmpeg/OpenH264/MediaCodec パスのサーフェスの高さ) である場合に、MIN (context->height、srcHeight) を使用して rect.top/rect.bottom のみを制限します。rect.left/rect.right に対してはクランプしません。
    check_rect() は、AVC420/AVC444 RGB 変換パスではなく、YUV444 結合パスでのみ呼び出されます。
    (CVE-2026-55192)

    TS Gateway の RPC フラグメント受信における、bind_ack の max_xmit_frag に上限がないことに起因するヒープバッファオーバーフロー書き込み

    TS Gateway 接続では、rpc->max_recv_frag は 0x0FF8 (4088) に初期化され、ReceiveFragment はそのサイズに割り当てられます。rpc_bind.c では、クライアントはサーバーから上限なしで rpc->max_recv_frag = header.bind_ack.max_xmit_frag を割り当てます。悪意のあるゲートウェイは max_xmit_frag = 0xFFFF に設定できますが、ReceiveFragment のサイズ変更は一切行われません。

    その後、rpc_client.c は if (header.frag_length > rpc->max_recv_frag) を持つフラグメントを拒否します。両方の値が 65535 の場合、このチェックに合格します (65535 > 65535 は false)。次に、受信ループが rpc_channel_read() - BIO_read() を固定された 4088 バイトの ReceiveFragment に呼び出し、最大 65535 バイトを書き込み、最大 61447 バイトの攻撃者制御バイトをオーバーフローします。(CVE-2026-55193)

    alloc_hint の容量不一致による TS Gateway RPC RESPONSE 再アセンブリでのヒープバッファオーバーフロー書き込み

    rpc_client_recv_fragment() では、PTYPE_RESPONSE PDU を再アセンブリするとき、クライアントはサーバーが宣言した alloc_hint のみを使用して、Stream_EnsureCapacity(pdu->s, response->alloc_hint) を呼び出します。
    Stream_EnsureCapacity() は、現在の書き込みオフセットやコピーしようとしている実際のスタブ長を考慮せずに、既存の容量がすでに >= alloc_hint である場合に成功を返します。

    悪意のあるゲートウェイが、大きなフラグメント (frag_length = 6000、StubLength [?] 5968 を生成) を送信しながら、小さな alloc_hint (たとえば 100) を設定する可能性があります。4096 バイトの再アセンブリバッファは拡張されず、Stream_Write(pdu->s, ..., StubLength) は、ヒープ割り当ての終端を超えて、攻撃者が制御するスタブデータをコピーします。デフォルトのビルドでは、これは WINPR_ASSERT によって中止される場合があります。一方、リリースビルド (NDEBUG) では、アサートが省略され、オーバーフローは悪用可能なヒープ書き込みになります。

    これは、別の ReceiveFragment / bind_ack max_xmit_frag の問題 (同じゲートウェイモジュール内で異なるバッファとコードパス) とは異なります。(CVE-2026-55194)

    細工されたグリフフラグメントを介した glyph_cache_get の領域外読み取り

    悪意のある RDP サーバーが、グリフキャッシュを介して FreeRDP クライアントで領域外ヒープ読み取りを引き起こす可能性があります。
    glyph_cache_get() は、インデックスの境界チェックで「>」を使用していますが、本来は「>=」を使用すべきです。一方、関連する関数である glyph_cache_put() では、すでに正しく処理されています。キャッシュのエントリ配列は正確に番号ポインターを保持するため、index が number に等しい場合、このチェックをすり抜け、末尾の 1 スロット先を読み取ります。そして、呼び出し元はこの領域をグリフとして逆参照します。これは CVE-2020-11098 の読み取り側の脆弱性であり (書き込み側は 2.1.2 で修正済みですが、読み取り側は修正されていません)、3.25.0 および master ブランチにも依然として存在しています。(CVE-2026-55564)

    freerdp_image_copy_from_icon_data の整数オーバーフローが境界チェックをバイパス (CVE-2026-55648)

    FreeRDP RemoteFX (RFX) キャッシュのビットマップ V3 デコードのヒープ領域外書き込み - 悪意のある RDP サーバーが、接続しているクライアントで制御された「$pc」を達成 (CVE-2026-55827)

    3.22.0 より前の FreeRDP には、channel_callback アクセスの同期が不適切なため、dvcman_channel_close および dvcman_call_on_receive にメモリ解放後使用 (use-after-free) の脆弱性があります。悪意のある RDP サーバーが DYNVC_DATA メッセージと DYNVC_CLOSE メッセージを同時に送信することで競合状態をトリガーし、drdynvc クライアントスレッドで heap-use-after-free を引き起こし、リモートコード実行やサービス拒否を引き起こす可能性があります。(CVE-2026-56297)

    終端されていない DeviceName / VirtualChannelName (CVE-2026-57157) による、カメラデバイス列挙サーバー (rdpecam) における領域外読み取り

    planar_decompress_plane_rle_only: ヒープ OOB 読み取り -- CVE-2026-23530 の不完全な修正

    CVE-2026-23530 (GHSA-r4hv-852m-fq7p) の修正は、freerdp_bitmap_decompress_planar のエントリポイントにディメンションガードを正しく追加しますが、その適用範囲は不完全です。planar_decompress_plane_rle_only は、
    srcp が SrcSize の範囲内にあることを検証する前に、*srcp を逆参照しています。悪意のあるサーバーが、RDPGFX_CMDID_WIRETOSURFACE_1 の切り捨てられた RLE 平面ペイロードを介して、このパスに到達する可能性があります。(CVE-2026-57158)

Tenable は、前述の記述ブロックをテスト済み製品のセキュリティアドバイザリから直接抽出しています。

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

リモートホストにインストールされている freerdp のバージョンは、2.11.7-1 より前です。したがって、ALAS2-2026-3840 のアドバイザリに記載されている複数の脆弱性の影響を受けます。

    制限されていないbind_ack max_xmit_fragによるフラグメント受信RPC TS ゲートウェイのヒープバッファオーバーフロー書き込み

    TS ゲートウェイ接続で、rpc->max_recv_frag は 0x0FF8 (4088) に初期化され、ReceiveFragment はそのサイズに割り当てられます。rpc_bind.c では、クライアントはサーバーから上限なしで rpc->max_recv_frag = header.bind_ack.max_xmit_frag を割り当てます。悪意のあるゲートウェイが、ReceiveFragment のサイズが決して変更されないのに max_xmit_frag = 0xFFFF を設定する可能性があります。

    後に、rpc_client.c は if (header.frag_length > rpc->max_recv_frag) を持つフラグメントを拒否します。両方の値が 65535 の場合、チェックに合格します (65535 > 65535 は偽)。次に、受信ループが rpc_channel_read() - BIO_read() を固定された 4088 バイトの ReceiveFragment に呼び出し、最大 65535 バイトを書き込み、最大 61447 バイトの攻撃者制御バイトをオーバーフローします。(CVE-2026-55193)

    容量の不一致による TS ゲートウェイRPC RESPONSE 再アセンブリでのヒープバッファオーバーフロー書き込みalloc_hint

    rpc_client_recv_fragment()では、PTYPE_RESPONSE PDUを再組み立てするとき、クライアントはサーバーが宣言したalloc_hintのみを使用してStream_EnsureCapacity(pdu->s, response->alloc_hint)を呼び出します。
    Stream_EnsureCapacity() は、現在の書き込みオフセットやコピーしようとしている実際のスタブ長を考慮せずに、既存の容量がすでに >= alloc_hint である場合に成功を返します。

    悪意のあるゲートウェイが、大きなフラグメント(frag_length = 6000、StubLength [?] 5968 を生成)を送信しながら、小さなalloc_hint(たとえば 100)を設定する可能性があります。4096 バイトの再アセンブリバッファは拡張されず、Stream_Write(pdu->s, ..., StubLength) は、ヒープ割り当ての終端を超えて攻撃者が制御するスタブデータをコピーします。デフォルトのビルドでは、これは WINPR_ASSERT によって中止される場合があります。Release ビルド(NDEBUG)では、アサートは省略され、オーバーフローは悪用可能なヒープ書き込みになります。

    これは、別の ReceiveFragment / bind_ack max_xmit_frag の問題(同じゲートウェイモジュール内で異なるバッファとコードパス)とは異なります。(CVE-2026-55194)

    細工されたグリフフラグメントを介した glyph_cache_get の領域外読み取り

    悪意のあるRDPサーバーが、グリフキャッシュを介してFreeRDPクライアントで領域外ヒープ読み取りを引き起こす可能性があります。
    glyph_cache_get() は、>= を使用する必要がある > でインデックスを境界チェックします -- 兄弟の glyph_cache_put() はすでに適切に処理しています。キャッシュのエントリ配列は正確に番号ポインターを保持するため、数値に等しいインデックスはチェックを通過して末尾を1スロット超えて読み取り、呼び出し元はこれをグリフとして逆参照します。これは CVE-2020-11098 の読み取り側の双子であり (書き込み側は 2.1.2 年に修正されましたが、読み取り側は修正されませんでした)、 3.25.0 とマスターにまだ存在します。(CVE-2026-55564)

    freerdp_image_copy_from_icon_data の整数オーバーフローが境界チェックをバイパスします(CVE-2026-55648)

    終端されていない DeviceName/VirtualChannelName(CVE-2026-57157)による、カメラデバイス列挙サーバー(rdpecam)における領域外読み取り

    planar_decompress_plane_rle_only:ヒープ OOB 読み取り -- に対する不完全な修正 CVE-2026-23530

    CVE-2026-23530(GHSA-r4hv-852m-fq7p)の修正は、freerdp_bitmap_decompress_planar のエントリポイントに Dimension guardsat を正しく追加しますが、scope.planar_decompress_plane_rle_onlyデリファレンスでは不完全です
    thatsrcp が SrcSize 内であることを検証する前の *srcp です。悪意のあるサーバーが、RDPGFX_CMDID_WIRETOSURFACE_1 の切り捨てられた RLE 平面ペイロードを介して、このパスに到達する可能性があります。(CVE-2026-57158)

Tenable は、前述の記述ブロックをテスト済み製品のセキュリティアドバイザリから直接抽出しています。

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - FreeRDP はリモートデスクトッププロトコルの無料実装です。3.27.0より前に、libfreerdp/cache/glyph.cのglyph_cache_get関数は、インデックスがcache->number以上ではなく、cache-numberより大きいかどうかをチェックします。悪意のあるRDPサーバーが、update_process_glyph_fragmentsのGLYPH_FRAGMENT_USEリプレイを使用して、cache->number が 254 の場合に、デフォルトのキャッシュ受信インデックスを 254 にし、エントリ配列の向こうにある 1 つのポインターを読み取り、それをグリフとして逆参照する可能性があります。これはクライアントをクラッシュさせ、隣接するヒープデータを漏洩させる可能性があります。この問題はバージョン 3.27.0 で修正されています。(CVE-2026-55564)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

ID	名前	製品	ファミリー	公開日	更新日	深刻度
331994	Amazon Linux 2023 : freerdp、freerdp-devel、freerdp-libs (ALAS2023-2026-2012)	Nessus	Amazon Linux Local Security Checks	2026/8/4	2026/8/21	high
332057	Amazon Linux 2 : freerdp、--advisory ALAS2-2026-3840 (ALAS-2026-3840)	Nessus	Amazon Linux Local Security Checks	2026/8/4	2026/8/21	high
325536	Linux Distros のパッチ未適用の脆弱性: CVE-2026-55564	Nessus	Misc.	2026/7/7	2026/8/26	medium

検出

プラグインの検索

high

high

medium