Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - FreeRDP 是遠端桌面通訊協定 (RDP) 的免費實作。在之前 3.27.0，libfreerdp/cache/glyph.c 中的 glyph_cache_get 函式會檢查索引是否大於 cache->number，而不是大於或等於它。當 cache->number 為 254 時，惡意RDP伺服器可在 update_process_glyph_fragments 中使用 GLYPH_FRAGMENT_USE 重播，讓預設快取接收索引 254，讀取 entries 陣列之外的一個指標，並將其解除參照為字形。這可能會使用戶端當機，並可能洩漏相鄰的堆積資料。3.27.0 版已修正此問題。(CVE-2026-55564)

請注意，Nessus 依賴供應商報告的套件存在。

因此，它會受到 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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - FreeRDP 是远程桌面协议的免费实现。在 3.27.0之前，libfreerdp/cache/glyph.c 中的 glyph_cache_get 函数会检查索引是否大于 cache->number，而不是大于或等于该数字。恶意 RDP 服务器可在 update_process_glyph_fragments 中使用GLYPH_FRAGMENT_USE重放当 cache->number 为 254 时使默认缓存接收索引 254，从而读取超出条目数组的指针并将其取消引用为字形。这可导致客户端崩溃并可能泄露相邻的堆数据。此问题已在 3.27.0 版本中修复。(CVE-2026-55564)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

远程主机上安装的 freerdp 版本低于 2.11.7-1。因此，该软件受到 ALAS2-2026-3840 公告中提及的多个漏洞影响。

    由于未限制bind_ack max_xmit_frag，TS 网关 RPC 片段接收中发生堆缓冲区溢出写入

    在 TS 网关连接上，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（） 会返回成功。

    恶意网关可设置小alloc_hint（比如 100）同时发送大片段（frag_length = 6000，生成 StubLength [？] 5968）。4096 字节重组缓冲区未增长，Stream_Write（pdu->s， ...， StubLength） 将攻击者控制的 stub 数据复制到堆分配末尾后的位置。在默认版本中，这可能会通过 WINPR_ASSERT 中止;在发布版本 （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，读取端从未固定过），并且它仍然存在于 和 master 中 3.25.0 。（CVE-2026-55564）

    freerdp_image_copy_from_icon_data 绕过边界检查 （CVE-2026-55648） 中的整数溢出

    相机设备枚举器服务器 （rdpecam） 中通过未终结的 DeviceName / VirtualChannelName （CVE-2026-57157） 造成的越界读取

    planar_decompress_plane_rle_only：堆 OOB 读取 -- 针对以下漏洞的修复不完整 CVE-2026-23530

    （GHSA-r4hv-852m-fq7p） 的 CVE-2026-23530 补丁正确地在 freerdp_bitmap_decompress_planar 的入口点添加了维度保护，但在scope.planar_decompress_plane_rle_only取消引用中不完整
    *srcp 在验证 thatsrcp 在 SrcSize 中之前。恶意服务器可通过 truncatedRLE 平面负载在 RDPGFX_CMDID_WIRETOSURFACE_1 到达此路径。（CVE-2026-57158）

Tenable 已直接从测试产品的安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

因此，该软件受到 ALAS2023-2026-2012 公告中提及的多个漏洞影响。

    AVC444 YUV 缓冲区分配中存在堆缓冲区溢出写入

    在 libfreerdp/codec/h264.c 中，avc444_ensure_buffer() 使用 UINT32 算术计算 AVC444 YUV444 中间缓冲区大小的计算为：piDstSize[x] = piDstStride[x] * padDstHeight。当真乘积超过 UINT32_MAX 时，该值将换行为非零小整数。唯一的保护措施是如果 (piDstSize[x] == 0) 返回 FALSE，则非零封装传递。然后，winpr_aligned_recallo() 会分配一个过小的缓冲区，而 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 位流 SPS 调整大小的解码器内部 YUV 缓冲区覆盖 h264->pYUVData 和 h264->iStride。这些尺寸永远不会与存储在 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)

    由于未限制 bind_ack max_xmit_frag，TS 网关 RPC 片段接收中发生堆缓冲区溢出写入

    在 TS 网关连接上，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 网关 RPC RESPONSE 重组中存在堆缓冲区溢出写入

    在 rpc_client_recv_fragment() 中，当重组 PTYPE_RESPONSE PDU 时，客户端仅使用服务器声明的 alloc_hint 调用 Stream_EnsureCapacity(pdu->s, response->alloc_hint)。
    如果现有容量已经 >= alloc_hint，而不考虑当前写入偏移量或即将复制的实际存根长度，则 Stream_EnsureCapacity() 会返回成功。

    恶意网关可设置小 alloc_hint（比如 100）同时发送大片段（frag_length = 6000，生成 StubLength [?] 5968）。4096 字节重组缓冲区未增长，Stream_Write(pdu->s, ..., StubLength) 将攻击者控制的 stub 数据复制到堆分配末尾后的位置。在默认版本中，这可能会通过 WINPR_ASSERT 中止；在发布版本 (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) 缓存位图 V3 解码中的堆越界写入 - 恶意 RDP 服务器在连接的客户端中实现受控的“$pc”(CVE-2026-55827)

    由于未正确同步 channel_callback 访问，3.22.0 之前的 FreeRDP 在 dvcman_channel_close 和 dvcman_call_on_receive 中包含释放后使用漏洞。恶意的 RDP 服务器可通过同时发送 DYNVC_DATA 和 DYNVC_CLOSE 消息触发争用条件，导致 drdynvc 客户端线程中发生堆释放后使用，进而可能造成远程代码执行或拒绝服务。(CVE-2026-56297)

    相机设备枚举器服务器 (rdpecam) 中通过未终结的 DeviceName / VirtualChannelName 造成的越界读取 (CVE-2026-57157)

    planar_decompress_plane_rle_only：堆 OOB 读取 - 针对 CVE-2026-23530 的修复不完整 

    CVE-2026-23530 (GHSA-r4hv-852m-fq7p) 的补丁正确地在 freerdp_bitmap_decompress_planar 的入口点添加了维度保护，但在 scope.planar_decompress_plane_rle_only 取消引用中不完整
    * 在验证 srcp 是否在 SrcSize 范围内之前，先执行 srcp。恶意服务器可通过 truncatedRLE 平面负载在 RDPGFX_CMDID_WIRETOSURFACE_1 到达此路径。(CVE-2026-57158)

Tenable 已直接从测试产品的安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

遠端主機上安裝的 freerdp 版本比 2.11.7-1 舊。因此，它會受到 ALAS2-2026-3840 公告中所提及的多個弱點影響。

    由於無上限的 bind_ack max_xmit_frag，TS 閘道RPC片段接收中的堆積緩衝區溢位寫入

    在 TS 閘道連線上，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 為假）。然後，接收迴圈會呼叫 rpc_channel_read（） - BIO_read（） 到固定的 4088 位元組 ReceiveFragment 中，寫入最多 65535 個位元組，並溢位最多 61447 個攻擊者控制的位元組。（CVE-2026-55193）

    由於alloc_hint容量不相符，TS 閘道RPC RESPONSE 重組中的堆積緩衝區溢位寫入

    在 rpc_client_recv_fragment（） 中，重組 PTYPE_RESPONSE PDU 時，用戶端僅使用伺服器宣告的 alloc_hint 呼叫 Stream_EnsureCapacity（pdu->s， response->alloc_hint）。
    如果現有容量已為 >= alloc_hint，則 Stream_EnsureCapacity（） 會傳回成功，而不考慮目前的寫入偏移量或即將複製的實際存根長度。

    惡意閘道可以在傳送大片段 （frag_length = 6000，產生 StubLength [？] 5968） 時設定小alloc_hint （例如 100） 。4096 位元組重組緩衝區不會成長，而且 Stream_Write （pdu->s， ...， StubLength） 會複製攻擊者控制的 stub 資料，超過堆積配置的結尾。在預設組建上，這可能會透過WINPR_ASSERT中止;在發行組建 （NDEBUG） 上，判斷提示會被省略，而且溢位會變成可利用的堆積寫入。

    這與單獨的 ReceiveFragment / bind_ack max_xmit_frag 問題（同一閘道模組中的不同緩衝區和程式碼路徑）不同。（CVE-2026-55194）

    透過特製的字形片段在glyph_cache_get中越界讀取

    惡意 RDP 伺服器可透過字形快取在 FreeRDP 用戶端中觸發越界堆積讀取。
    glyph_cache_get（） 使用應該使用 >= 的>對索引進行邊界檢查 -- 同級 glyph_cache_put（） 已經正確了。由於快取的 entries 陣列完全包含數字指標，因此等於數字的索引會滑過檢查，並讀取超出結尾的一個插槽，然後呼叫端將其解除參照為字形。它是 的 CVE-2020-11098 讀取端孿生（寫入端已修復回 2.1.2，讀取端從未固定過），並且它仍然存在於 和 master 中 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

    （GHSA-r4hv-852m-fq7p） 的 CVE-2026-23530 修正已正確在freerdp_bitmap_decompress_planar的進入點新增維度保護，但在scope.planar_decompress_plane_rle_only取消參照中不完整
    *srcp 在驗證 srcp 是否在 SrcSize 內之前。惡意伺服器可透過 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 は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

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

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2026-2012 advisory.

    Heap-buffer-overflow write in AVC444 YUV buffer allocation

    In libfreerdp/codec/h264.c, avc444_ensure_buffer() computes the AVC444 YUV444 intermediate buffer size as     piDstSize[x] = piDstStride[x] * padDstHeight using UINT32 arithmetic. When the true product exceeds     UINT32_MAX, the value wraps to a small non-zero integer. The only guard is if (piDstSize[x] == 0) return     FALSE, so non-zero wraps pass. winpr_aligned_recalloc() then allocates a buffer far too small, and     yuv444_context_decode() - YUV420CombineToYUV444() writes using the real stride and rectangle dimensions,     causing a heap-buffer-overflow write.

    The reallocation trigger at lines 498-499 correctly compares against 1ull * piMainStride[0] * padDstHeight     (64-bit), but the allocation at line 504 still uses 32-bit multiply. (CVE-2026-55191)

    Out-of-bounds read in H.264 YUV-to-RGB conversion due to decoder/surface dimension mismatch

    After h264->subsystem->Decompress() returns, all major H.264 backends overwrite h264->pYUVData and     h264->iStride with decoder-internal YUV buffers sized by the H.264 bitstream SPS. These dimensions are     never compared against the RDPGFX surface dimensions stored in h264->width / h264->height.

    areRectsValid() validates region rectangles against the surface width/height passed into     avc420_decompress() / avc444_decompress(). Subsequent YUV-RGB conversion (yuv420_context_decode -     avc420_yuv_to_rgb or avc444_yuv_to_rgb) consumes those surface-sized rectangles against the smaller     decoder-sized YUV planes, causing out-of-bounds reads on both axes.

    clamp() only limits rect.top/rect.bottom using MIN(context->height, srcHeight) where srcHeight is     h264->height (surface height on FFmpeg/OpenH264/MediaCodec paths). It does not clamp rect.left/rect.right.
    check_rect() is only invoked on the YUV444 combine path, not on the AVC420/AVC444 RGB conversion paths.
    (CVE-2026-55192)

    Heap-buffer-overflow write in TS Gateway RPC fragment receive due to uncapped bind_ack max_xmit_frag

    On TS Gateway connections, rpc->max_recv_frag is initialized to 0x0FF8 (4088) and ReceiveFragment is     allocated to that size. In rpc_bind.c, the client assigns rpc->max_recv_frag =     header.bind_ack.max_xmit_frag from the server without an upper bound. A malicious gateway can set     max_xmit_frag = 0xFFFF while ReceiveFragment is never resized.

    Later, rpc_client.c rejects fragments with if (header.frag_length > rpc->max_recv_frag). When both values     are 65535, the check passes (65535 > 65535 is false). The receive loop then calls rpc_channel_read() -     BIO_read() into the fixed 4088-byte ReceiveFragment, writing up to 65535 bytes and overflowing by up to     61447 attacker-controlled bytes. (CVE-2026-55193)

    Heap-buffer-overflow write in TS Gateway RPC RESPONSE reassembly due to alloc_hint capacity mismatch

    In rpc_client_recv_fragment(), when reassembling a PTYPE_RESPONSE PDU, the client calls     Stream_EnsureCapacity(pdu->s, response->alloc_hint) using only the server-declared alloc_hint.
    Stream_EnsureCapacity() returns success if the existing capacity is already >= alloc_hint, without     considering the current write offset or the actual stub length about to be copied.

    A malicious gateway can set a small alloc_hint (e.g. 100) while sending a large fragment (frag_length =     6000, yielding StubLength [?] 5968). The 4096-byte reassembly buffer is not grown, and     Stream_Write(pdu->s, ..., StubLength) copies attacker-controlled stub data past the end of the heap     allocation. On default builds this may abort via WINPR_ASSERT; on Release builds (NDEBUG) the assert is     elided and the overflow becomes an exploitable heap write.

    This is distinct from the separate ReceiveFragment / bind_ack max_xmit_frag issue (different buffer and     code path in the same gateway module). (CVE-2026-55194)

    Out-of-bounds read in glyph_cache_get via crafted glyph fragments

    A malicious RDP server can trigger an out-of-bounds heap read in a FreeRDP client through the glyph cache.
    glyph_cache_get() bounds-checks the index with > where it should use >= -- the sibling glyph_cache_put()     already gets it right. Since the cache's entries array holds exactly number pointers, an index equal to     number slips past the check and reads one slot past the end, which the caller then dereferences as a     glyph. It's the read-side twin of CVE-2020-11098 (the write side was fixed back in 2.1.2; the read side     never was), and it's still present in 3.25.0 and master. (CVE-2026-55564)

    Integer Overflow in freerdp_image_copy_from_icon_data Bypasses Bounds Check (CVE-2026-55648)

    Heap out-of-bounds write in FreeRDP RemoteFX (RFX) Cache Bitmap V3 decode - malicious RDP server achieves     controlled `$pc` in a connecting client (CVE-2026-55827)

    FreeRDP before 3.22.0 contains a use-after-free vulnerability in dvcman_channel_close and     dvcman_call_on_receive due to improper synchronization of channel_callback access. A malicious RDP server     can trigger a race condition by sending DYNVC_DATA and DYNVC_CLOSE messages concurrently, causing heap-     use-after-free in the drdynvc client thread and potentially enabling remote code execution or denial of     service. (CVE-2026-56297)

    Out-of-bounds read in the camera device enumerator server (rdpecam) via unterminated DeviceName /     VirtualChannelName (CVE-2026-57157)

    planar_decompress_plane_rle_only: heap OOB read -- incomplete fix for CVE-2026-23530

    The fix for CVE-2026-23530 (GHSA-r4hv-852m-fq7p) correctly adds dimension guardsat the entry point of     freerdp_bitmap_decompress_planar but is incomplete in scope.planar_decompress_plane_rle_only dereferences
    *srcp before validating thatsrcp is within SrcSize. A malicious server can reach this path via a     truncatedRLE planar payload in RDPGFX_CMDID_WIRETOSURFACE_1. (CVE-2026-57158)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.27.0, the glyph_cache_get     function in libfreerdp/cache/glyph.c checks whether index is greater than cache->number instead of greater     than or equal to it. A malicious RDP server can use GLYPH_FRAGMENT_USE replay in     update_process_glyph_fragments to make the default cache receive index 254 when cache->number is 254,     reading one pointer beyond the entries array and dereferencing it as a glyph. This can crash the client     and may disclose adjacent heap data. This issue is fixed in version 3.27.0. (CVE-2026-55564)

Note that Nessus relies on the presence of the package as reported by the vendor.

The version of freerdp installed on the remote host is prior to 2.11.7-1. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2-2026-3840 advisory.

    Heap-buffer-overflow write in TS Gateway RPC fragment receive due to uncapped bind_ack max_xmit_frag

    On TS Gateway connections, rpc->max_recv_frag is initialized to 0x0FF8 (4088) and ReceiveFragment is     allocated to that size. In rpc_bind.c, the client assigns rpc->max_recv_frag =     header.bind_ack.max_xmit_frag from the server without an upper bound. A malicious gateway can set     max_xmit_frag = 0xFFFF while ReceiveFragment is never resized.

    Later, rpc_client.c rejects fragments with if (header.frag_length > rpc->max_recv_frag). When both values     are 65535, the check passes (65535 > 65535 is false). The receive loop then calls rpc_channel_read() -     BIO_read() into the fixed 4088-byte ReceiveFragment, writing up to 65535 bytes and overflowing by up to     61447 attacker-controlled bytes. (CVE-2026-55193)

    Heap-buffer-overflow write in TS Gateway RPC RESPONSE reassembly due to alloc_hint capacity mismatch

    In rpc_client_recv_fragment(), when reassembling a PTYPE_RESPONSE PDU, the client calls     Stream_EnsureCapacity(pdu->s, response->alloc_hint) using only the server-declared alloc_hint.
    Stream_EnsureCapacity() returns success if the existing capacity is already >= alloc_hint, without     considering the current write offset or the actual stub length about to be copied.

    A malicious gateway can set a small alloc_hint (e.g. 100) while sending a large fragment (frag_length =     6000, yielding StubLength [?] 5968). The 4096-byte reassembly buffer is not grown, and     Stream_Write(pdu->s, ..., StubLength) copies attacker-controlled stub data past the end of the heap     allocation. On default builds this may abort via WINPR_ASSERT; on Release builds (NDEBUG) the assert is     elided and the overflow becomes an exploitable heap write.

    This is distinct from the separate ReceiveFragment / bind_ack max_xmit_frag issue (different buffer and     code path in the same gateway module). (CVE-2026-55194)

    Out-of-bounds read in glyph_cache_get via crafted glyph fragments

    A malicious RDP server can trigger an out-of-bounds heap read in a FreeRDP client through the glyph cache.
    glyph_cache_get() bounds-checks the index with > where it should use >= -- the sibling glyph_cache_put()     already gets it right. Since the cache's entries array holds exactly number pointers, an index equal to     number slips past the check and reads one slot past the end, which the caller then dereferences as a     glyph. It's the read-side twin of CVE-2020-11098 (the write side was fixed back in 2.1.2; the read side     never was), and it's still present in 3.25.0 and master. (CVE-2026-55564)

    Integer Overflow in freerdp_image_copy_from_icon_data Bypasses Bounds Check (CVE-2026-55648)

    Out-of-bounds read in the camera device enumerator server (rdpecam) via unterminated DeviceName /     VirtualChannelName (CVE-2026-57157)

    planar_decompress_plane_rle_only: heap OOB read -- incomplete fix for CVE-2026-23530

    The fix for CVE-2026-23530 (GHSA-r4hv-852m-fq7p) correctly adds dimension guardsat the entry point of     freerdp_bitmap_decompress_planar but is incomplete in scope.planar_decompress_plane_rle_only dereferences
    *srcp before validating thatsrcp is within SrcSize. A malicious server can reach this path via a     truncatedRLE planar payload in RDPGFX_CMDID_WIRETOSURFACE_1. (CVE-2026-57158)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
325536	Linux Distros 未修補弱點：CVE-2026-55564	Nessus	Misc.	2026/7/7	2026/8/26	medium
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
325536	Linux Distros 未修补的漏洞：CVE-2026-55564	Nessus	Misc.	2026/7/7	2026/8/26	medium
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
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
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
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
325536	Linux Distros Unpatched Vulnerability : CVE-2026-55564	Nessus	Misc.	2026/7/7	2026/8/26	medium
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

检测

插件搜索

medium

high

medium

high

high

high

medium

high

high

high

medium

high