There are packages installed that are affected by multiple vulnerabilities referenced in the following CVEs:

  - FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.27.1, FreeRDP clients launched
    with the non-default /cache:codec:rfx option pass desktop stride and height to RemoteFX decoding for Cache
    Bitmap V3 data while allocating bitmap->data only for the smaller DstWidth and DstHeight in
    gdi_Bitmap_Decompress, allowing a malicious RDP server to trigger a heap out-of-bounds write with
    attacker-controlled offset and content. This issue is fixed in version 3.27.1. (CVE-2026-55827)

  - FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.27.0, FreeRDP clients that
    negotiate RDPGFX AVC444 with an H.264 decoder backend calculate the intermediate YUV444 allocation size in
    libfreerdp/codec/h264.c with 32-bit multiplication in avc444_ensure_buffer. A malicious RDP server can
    supply surface dimensions for which piDstStride multiplied by padDstHeight wraps to a small nonzero value,
    causing winpr_aligned_recalloc to allocate an undersized buffer before YUV420CombineToYUV444 writes using
    the actual stride and rectangle dimensions. This can cause a client crash and may permit code execution
    through attacker-influenced heap corruption. This issue is fixed in version 3.27.0. (CVE-2026-55191)

  - FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.27.0, FreeRDP H.264 decoder
    backends can return YUV planes sized from the bitstream without comparing the decoded width and height to
    the RDPGFX surface dimensions used to validate region rectangles. A malicious RDP server can provide an
    AVC420 or AVC444 bitstream whose decoded frame is smaller than the negotiated surface, causing
    yuv420_context_decode and the YUV-to-RGB conversion paths to read beyond the decoder-owned planes in
    libfreerdp/codec/h264.c and the selected H.264 backend. This can disclose client memory or crash the
    client. This issue is fixed in version 3.27.0. (CVE-2026-55192)

  - FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.27.0, FreeRDP clients using TS
    Gateway accept a server-controlled max_xmit_frag value in libfreerdp/core/gateway/rpc_bind.c without
    bounding it to the 4088-byte ReceiveFragment allocation. A malicious gateway can advertise 65535 and then
    send a response fragment of the same length, causing rpc_channel_read in libfreerdp/core/gateway/rpc.c to
    write up to 65535 bytes into the smaller ReceiveFragment buffer. This can crash the client and may permit
    code execution through attacker-controlled heap corruption. This issue is fixed in version 3.27.0.
    (CVE-2026-55193)

  - FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.27.0, rpc_client_recv_fragment
    in libfreerdp/core/gateway/rpc_client.c ensures the response reassembly stream capacity using only the
    server-declared alloc_hint rather than the actual StubLength about to be written. A malicious TS Gateway
    can send a PTYPE_RESPONSE with a small alloc_hint and a much larger frag_length, causing Stream_Write to
    copy attacker-controlled stub data beyond the 4096-byte pdu->s buffer. This can crash the client and may
    permit code execution through heap corruption. This issue is fixed in version 3.27.0. (CVE-2026-55194)

The remote Fedora 43 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2026-78a12ffec8 advisory.

    Update to 3.27.1

    It fixes CVE-2026-55191, CVE-2026-55192, CVE-2026-55193, CVE-2026-55194,     CVE-2026-55648 and CVE-2026-55827.

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

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

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 remote Fedora 44 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2026-9c6082d92d advisory.

    Update to 3.27.1

    It fixes CVE-2026-55191, CVE-2026-55192, CVE-2026-55193, CVE-2026-55194,     CVE-2026-55648 and CVE-2026-55827.

Tenable has extracted the preceding description block directly from the Fedora 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,     freerdp_image_copy_from_icon_data in libfreerdp/codec/color.c calculates nWidth multiplied by nHeight     multiplied by FreeRDPGetBytesPerPixel(format) in 32-bit arithmetic. A malicious RDP server can send a RAIL     TS_ICON_INFO update with dimensions such as 32768 by 32768 and 32 bits per pixel so the required-size     calculation wraps, bypassing the cbBitsColor source bounds check before freerdp_image_copy_no_overlap     reads attacker-controlled icon data. This affects RemoteApp clients using the vulnerable library path,     while xfreerdp has a caller-side mitigation. This issue is fixed in version 3.27.0. (CVE-2026-55648)

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	Name	Product	Family	Published	Updated	Severity
444102	Alpine: multiple freerdp packages: security update to 3.27.1-r0	Tenable Cloud Security	Alpine Linux Local Security Checks	6/29/2026	9/25/2026	high
444102	Alpine: multiple freerdp packages: security update to 3.27.1-r0	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	6/29/2026	9/25/2026	high
325081	Fedora 43 : freerdp (2026-78a12ffec8)	Nessus	Fedora Local Security Checks	7/4/2026	9/25/2026	high
331994	Amazon Linux 2023 : freerdp, freerdp-devel, freerdp-libs (ALAS2023-2026-2012)	Nessus	Amazon Linux Local Security Checks	8/4/2026	9/25/2026	high
321878	Fedora 44 : freerdp (2026-9c6082d92d)	Nessus	Fedora Local Security Checks	6/21/2026	9/29/2026	high
325535	Linux Distros Unpatched Vulnerability : CVE-2026-55648	Nessus	Misc.	7/7/2026	9/25/2026	medium
332057	Amazon Linux 2 : freerdp, --advisory ALAS2-2026-3840 (ALAS-2026-3840)	Nessus	Amazon Linux Local Security Checks	8/4/2026	9/25/2026	high

Detections

Analytics

Plugins Search

high

high

high

high

high

medium

high