Impact
CVE-2021-44732 is a double-free issue in Mbed TLS that can occur in a session-handling error path when allocation fails, including the mbedtls_ssl_set_session() failure case described by the project advisory [S1]. Depending on how an application links and exercises Mbed TLS, that class of memory corruption can create denial-of-service risk and may have more serious impact in some deployments [S1][S2][S3].
The vendor advisory treats this as a high-severity issue, while NVD and GitHub Advisory Database publish critical CVSS scoring [S1][S2][S3]. For FixVibe scan results, repository evidence supports a high-severity version-based advisory rather than a confirmed live exploit.
Affected versions
The original NVD record describes Mbed TLS releases before 3.0.1 as affected [S2]. The Mbed TLS project advisory and release announcement are more useful for remediation because they identify fixed releases across maintained branches: 2.16.12, 2.28.0, and 3.1.0 [S1][S4].
That means teams should check the branch they actually vendor or link. Older 2.16.x, 2.17.x through 2.27.x, and 3.0.x version evidence should be reviewed unless the downstream package has a documented backport [S1][S4].
Concrete fixes
Upgrade Mbed TLS to the fixed release for the branch you use: 2.16.12, 2.28.0, 3.1.0, or a later supported release [S1][S4]. If the project vendors Mbed TLS source directly, update the vendored tree, rebuild the application, and make sure the compiled binary no longer references the vulnerable branch version.
If a Linux distribution, embedded SDK, or product vendor backported the fix without changing the visible upstream version string, keep the vendor advisory or package changelog with the repository evidence so the finding can be triaged accurately.
Covered by FixVibe
Covered by FixVibe. Authorized GitHub repo scans can report source and build metadata that identify Mbed TLS versions affected by CVE-2021-44732. The scanner treats this as a version-based advisory and reports the evidence file, detected version, confidence, source quality, and branch-aware fixed release guidance.
FixVibe does not run the project, force out-of-memory behavior, call Mbed TLS session-copy APIs, trigger a double free, prove denial of service, prove code execution, or confirm which Mbed TLS build is deployed in production. Runtime exposure and downstream backports still need owner review.
Verification checklist
Confirm where Mbed TLS comes from in the project, including vendored source, submodules, package-manager metadata, CMake files, Makefiles, and generated build configuration. After upgrading, rebuild the application and verify the repository no longer exposes an affected Mbed TLS version in the tracked source or build metadata.
For safety-sensitive products, also review the vendor or distribution changelog for backports, run the project's normal TLS regression tests, and use memory-safety tooling in your own test environment to catch allocator misuse without turning the public report into an exploit recipe.