CVE-2026-73241 is an authentication bypass in the FreeRDP server side RDSTLS code. A client can send a capabilities message when credentials are expected, and the server reports success without checking them. The record scores it 7.5, High, and says it is fixed in 3.30.0. The advisory lists no patch, so verify.
What's affected
The record says FreeRDP before 3.30.0 is affected and that 3.30.0 fixes it. The GitHub advisory for the issue gives a different picture. It lists affected versions as 3.27.1 and the development head, and shows patched versions as none at the time we read it. A 3.30.0 release page and a commit titled to tighten state and bounds checks in the RDSTLS code exist in the sources the record cites. Treat 3.30.0 as the target, and confirm the fix in the release notes and your distribution package.
Only server side use is affected. The advisory says any FreeRDP based server or proxy that enables RDSTLS is exposed. Programs that use FreeRDP only as a client, such as a desktop remote access client, do not run this server code.
The advisory explains the mechanism. The server dispatches incoming messages by the type the client claims, without checking that it is the message the protocol requires at this step. The result code starts at zero, which happens to mean success. A capabilities message sent where credentials are expected is accepted, the code never sets the result code, and the server answers with success. The weakness class is CWE-287, improper authentication.
How to check if you're exposed
Find out whether you build or run anything that uses the FreeRDP server code.
xfreerdp --version
pkg-config --modversion freerdp3
These show the installed client and library versions. Next, find products that embed FreeRDP as a server or gateway, such as remote desktop proxies or shadow servers, and check whether they enable RDSTLS. If you do not know, ask the vendor of any remote access gateway in your environment. A scan of your container images and manifests is the quickest way to find embedded copies. The free in-browser scan at gold.safeguard.sh/scan accepts a manifest and lists known CVEs for the packages it finds.
What to do now
- Upgrade FreeRDP to 3.30.0 or later, and confirm the fix in the release notes.
- If you cannot upgrade, disable RDSTLS on any FreeRDP based server or proxy where it is configurable.
- Do not expose FreeRDP based servers directly to the internet. Put them behind a VPN or an authenticated gateway.
- Ask vendors of embedded remote access products whether they ship an affected FreeRDP build.
- Review connection logs for sessions that started without an authentication event.
- Recheck the advisory page for a patched version list, since it showed none when we read it.
Why it matters
This is a classic fail open state machine bug. The default value of a variable is the success value, and a path that skips the check leaves the default in place. The safe design starts every authentication result as failure and sets success only after the checks pass.
The sources disagree on fixes. The record points to 3.30.0, while the advisory page listed no patched version when we read it. It also lists only 3.27.1 and the head as affected, while the record says everything before 3.30.0. On severity they agree. The record says 7.5 High under CVSS 3.1 and the advisory labels it High. No source reports exploitation in the wild, and the CVE is not on the CISA KEV list.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect me if I only use a FreeRDP based client?
The advisory describes the server side RDSTLS code, so client only use is not the affected path.
Do the sources agree on the fixed version?
No. The record says 3.30.0. The advisory showed no patched version when we read it. Verify against the release notes.
Sources
Last reviewed: 18 October 2026.
