因此，它會受到 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 行的重新配置觸發條件正確地與 64 位元的 1ull * piMainStride[0] * padDstHeight 進行比較，但第 504 行的記憶體配置仍使用 32 位元乘法。(CVE-2026-55191)

    由於解碼器與表面尺寸不相符，導致在 H.264 YUV 轉 RGB 轉換時發生超出邊界讀取。

    在 h264->subsystem->Decompress() 返回後，所有主要的 H.264 後端都會將 h264->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() 僅使用 MIN(context->height, srcHeight) 來限制 rect.top 與 rect.bottom，其中 srcHeight 為 h264->height (即 FFmpeg/OpenH264/MediaCodec 路徑上的表面高度)。它不會對 rect.left 與 rect.right 進行邊界限制。
    check_rect() 僅在 YUV444 合併路徑上調用，而未在 AVC420/AVC444 RGB 轉換路徑上調用。
    (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)

    在 TS Gateway RPC RESPONSE 重組過程中，由於 alloc_hint 容量不相符，導致堆緩衝區溢位寫入。

    在 rpc_client_recv_fragment() 中重組 PTYPE_RESPONSE PDU 時，客戶端僅會根據伺服端宣告的 alloc_hint 來呼叫 Stream_EnsureCapacity(pdu->s, response->alloc_hint)。
    若現有容量已大於等於 alloc_hint，Stream_EnsureCapacity() 便會回傳成功，完全未考量目前的寫入偏移量或即將複製的實際 stub 長度。

    惡意閘道器可以設定較小的 alloc_hint（例如 100），同時傳送較大的片段 (frag_length = 6000，產生約 5968 的 StubLength)。4096 位元組的重組緩衝區並未被擴增，且 Stream_Write(pdu->s, ..., StubLength) 會將由攻擊者控制的 stub 資料複製超越堆配置的末端。在預設建置版本中，這可能會透過 WINPR_ASSERT 中止執行；而在 Release 建置版本 (NDEBUG) 中，該斷言會被省略，使得此溢位演變成可刺探利用的堆積寫入。

    這與另一個獨立的 ReceiveFragment / bind_ack max_xmit_frag 問題不同 (屬於同一個閘道模組中的不同緩衝區與程式碼路徑)。(CVE-2026-55194)

    透過特製的字形片段在 glyph_cache_get 中超出邊界讀取

    惡意 RDP 伺服器可透過字形快取，引發 FreeRDP 客戶端發生超出邊界堆積讀取。
    glyph_cache_get() 使用 > 來檢查邊界索引，但實際上應該使用 >= -- 其同級的 glyph_cache_put() 處理方式才正確。由於快取的條目陣列持有的指標數量恰好為某數量，因此當索引等於某數量時會跳過檢查，進而讀取超出陣列末端一個位置的內容，隨後呼叫端便會將該資料當作字形進行提領。這是 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) Cache Bitmap V3 解碼過程存在堆積溢位寫入 - 惡意 RDP 伺服器可在連線的用戶端實現受控的 `$pc` (CVE-2026-55827)

    3.22.0 版本之前的 FreeRDP 存在釋放後使用弱點，原因在於 dvcman_channel_close 與 dvcman_call_on_receive 中未適當同步處理對 channel_callback 的存取。惡意 RDP 伺服器可透過同時傳送 DYNVC_DATA 和 DYNVC_CLOSE 訊息來觸發競爭條件，導致 drdynvc 用戶端執行緒發生堆積釋放後使用，並可能引發遠端程式碼執行或拒絕服務。(CVE-2026-56297)

    透過未終止的 DeviceName / VirtualChannelName，相機裝置列舉程式伺服器 (rdpecam) 存在超出邊界讀取漏洞 (CVE-2026-57157)

    planar_decompress_plane_rle_only：堆積超出邊界讀取 -- CVE-2026-23530 的修復不完整

    freerdp_bitmap_decompress_planar 進入點對 CVE-2026-23530 (GHSA-r4hv-852m-fq7p) 的修復雖然正確加入了尺寸保護檢查，但其範疇並不完整。planar_decompress_plane_rle_only
    在驗證 srcp 是否落於 SrcSize 範圍內之前，便提領 *srcp。惡意伺服器可透過 RDPGFX_CMDID_WIRETOSURFACE_1 中的 truncatedRLE 平面承載觸發此路徑。(CVE-2026-57158)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

偵測

Amazon Linux 2023：freerdp、freerdp-devel、freerdp-libs (ALAS2023-2026-2012)

high Nessus Plugin ID 331994

版本 1.5