Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process. The following link provides references to all essential vulnerability management information. If something is wrong or missing, please contact a member of PSIRT. https://spaces.redhat.com/display/PRODSEC/Vulnerability+Management+-+Essential+Documents+for+Engineering+Teams
FEDORA-2025-dce2ac8ea0 (mbedtls-3.6.5-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-dce2ac8ea0
Peter proposed the EPEL bug - https://bugzilla.redhat.com/show_bug.cgi?id=2405237 - as a blocker. Transferring the nomination here. Justification: mbedtls 3.6.5 is a security release. It has a number of CVEs, there's one rated HIGH [1] (Red Hat doesn't rate ones not shipped in RHEL). It affects the following packages in Worksttion: ffmpeg-free gnome-classic-session gstreamer1-plugin-libav localsearch nautilus papers-nautilus [1] https://cve.akaoma.com/cve-2025-54764
Poking through the deps, it seems the key thing that really uses mbedtls is librist. librist in turn is required by libavformat-free , localsearch requires libavformat-free , and localsearch triggers the gnome-classic-session , nautilus , and papers-nautilus deps. ffmpeg-free and gstreamer1-plugin-libav depend on libavformat-free directly. So, librist is the key. As best as I can tell, librist is using mbedtls to support https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol within https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol , which I guess is a thing you can do with media streams? (librist itself implements https://www.rist.tv/ , which is a media-focused streaming protocol thing). Going by the guide at https://mbed-tls.readthedocs.io/en/latest/security-advisories/mbedtls-security-advisory-2025-10-ssbleed-mstep/ , it doesn't look to me like librist uses any of the affected functions. The librist source has a copy of the mbedtls source in it, so if you just grep for them you get tons of hits, but if I wipe the contrib/mbedtls/ directory then grep, I find no use of affected functions. It looks to me like librist never uses RSA, only AES. https://www.rist.tv/articles-and-deep-dives/2022/5/24/how-does-rist-ensure-cyber-security tends to confirm this theory - it says: "RIST specification provides two Packet encryption methods (both DTLS and PSK): AES 128: “relatively” secure, usually no legal constraints for use in different parts of the world. AES 256: more secure than AES 128, but not allowed in some parts of the world." i.e. RIST seems to require the use of AES. So since this CVE is specific to RSA, I think we're probably OK from the perspective of what's in the Workstation images at release time.
I checked KDE too, it's much the same. librist is the only thing that actually uses mbedtls, libavformat-free is there and depends on librist, various other things require libavformat-free.