CVE-2026-64621
Double Free: Is CVE-2026-64621 real, exploitable, or a false positive? Here's the community verdict.
signals
public sources
Moderate signals. Triage by your actual exposure and reachability.
baseline read
auto · not a community verdict
Low signal — verdict needed
Few public signals point to active risk. Whether a scanner hit here is a true or false positive depends on your version and config — community verdicts decide.
Based on CVSS
Confirm or dispute →CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:H/A:H
FreeRDP before 3.28.0 (affected 3.x through 3.27.1) contains a double-free vulnerability in freerdp_client_rdp_file_apply_to_settings() (client/common/file.c) when parsing the selectedmonitors field of a .rdp connection file. The MonitorIds array is allocated through the settings object, and a raw non-owning pointer to it is freed on the strtoul error path without clearing settings->MonitorIds, leaving it dangling; at teardown freerdp_settings_free() frees the same buffer again. An attacker who convinces a victim to open a crafted .rdp file with oversized monitor tokens can trigger a size-controlled double-free in any FreeRDP CLI client (xfreerdp/sdl-freerdp/wlfreerdp) in the default configuration.
References
Published
Embed this verdict
[](https://www.truepositive.app/cve/CVE-2026-64621)<a href="https://www.truepositive.app/cve/CVE-2026-64621"><img src="https://www.truepositive.app/cve/CVE-2026-64621/badge.svg" alt="TruePositive verdict for CVE-2026-64621"></a>Live badge that updates automatically as the community verdict changes.
Community ground truth
Be the first practitioner to weigh in
So far this is only TruePositive's editorial baseline from public sources. Add your real-world verdict below — it becomes the signal the next person triaging this relies on.
🥇 The first 50 practitioners to contribute earn a Founding Contributor badge.
In your experience, is this finding real and exploitable?
awaiting field verdictsNo account needed. Anonymous verdicts post as an unverified signal. Log in to make yours verified and earn reputation.
Field notes & remediation
Verdicts are the quick signal. Notes are the evidence and fixes behind them.
No notes yet. Be the first to share what you saw, or a fix that worked.
Add a field note or remediationoptional
Related CVEs
Same weakness: CWE-415 · Double Free.
- CVE-2026-23918HIGH 8.8EPSS 46%
Double Free and possible RCE vulnerability in Apache HTTP Server with the HTTP/2 protocol. This issue affects Apache HTTP Server: 2.4.66. Users are recommended to upgrade to version 2.4.67, which fixes the issue.
- CVE-2024-30097HIGH 8.8Real · low riskEPSS 2%
Microsoft Speech Application Programming Interface (SAPI) Remote Code Execution Vulnerability
- CVE-2026-33811HIGH 7.5Real · low riskEPSS 1%
When using LookupCNAME with the cgo DNS resolver, a very long CNAME response can trigger a double-free of C memory and a crash.
- CVE-2026-50685HIGH 7.5Real · low riskEPSS 1%
Double free in Windows DHCP Server allows an authorized attacker to execute code over a network.
- CVE-2026-25556HIGH 7.5Real · low riskEPSS 0%
MuPDF versions 1.23.0 through 1.27.0 contain a double-free vulnerability in fz_fill_pixmap_from_display_list() when an exception occurs during display list rendering. The function accepts a caller-owned fz_pixmap pointer but incorrectly drops the pixmap in its error handling path before rethrowing the exception. Callers (including the barcode decoding path in fz_decode_barcode_from_display_list) also drop the same pixmap in cleanup, resulting in a double-free that can corrupt the heap and crash the process. This issue affects applications that enable and use MuPDF barcode decoding and can be triggered by processing crafted input that causes a rendering-time error while decoding barcodes.
- CVE-2026-52993CRIT 9.8Real · low riskEPSS 0%
In the Linux kernel, the following vulnerability has been resolved: tipc: fix double-free in tipc_buf_append() tipc_msg_validate() can potentially reallocate the skb it is validating, freeing the old one. In tipc_buf_append(), it was being called with a pointer to a local variable which was a copy of the caller's skb pointer. If the skb was reallocated and validation subsequently failed, the error handling path would free the original skb pointer, which had already been freed, leading to double-free. Fix this by checking if head now points to a newly allocated reassembled skb. If it does, reassign *headbuf for later freeing operations.