CVE-2025-47917 is a high severity use after free flaw (CVSS 8.9) in Mbed TLS versions up to 3.6.3. The function mbedtls_x509_string_to_names() frees memory its documentation does not say it frees. Upgrade to Mbed TLS 3.6.4 or later, or pass a pointer to NULL as the head argument.
What's affected
The Mbed TLS security advisory 2025-06-7 says all versions of Mbed TLS up to 3.6.3 are affected. Mbed TLS 3.6.4 and later 3.6 releases are not affected, and neither are the upcoming 4.x versions. The advisory is dated 30 June 2025 and rates the severity High.
The advisory also says that applications that do not call mbedtls_x509_string_to_names() directly are not affected, since internal uses of the function do not lead to memory management errors. The two sample programs in the library, x509/cert_write and x509/cert_req, were affected. Debian published long term support announcements for the issue, and the record lists them, so check your distribution's own updates too.
The record does not mark it as exploited in the wild, and it is not in the CISA Known Exploited Vulnerabilities catalog.
How to check if you're exposed
First find the library version your software uses:
grep -rn "MBEDTLS_VERSION_STRING " /usr/include/mbedtls/build_info.h 2>/dev/null
dpkg -l | grep -i mbedtls
Adjust the commands for your system. Software that bundles its own copy of Mbed TLS, which is common in firmware and embedded projects, needs a look at its own source tree.
Then search your own code for calls to the function:
grep -rn "mbedtls_x509_string_to_names" .
If nothing calls it, the advisory says you are not affected. If something does, check what is passed as the first argument. The advisory says passing a pointer to NULL avoids the problem.
What to do now
- Inventory the products and firmware in your estate that include Mbed TLS, including copies bundled in other software.
- Search your own code for calls to mbedtls_x509_string_to_names.
- Upgrade to Mbed TLS 3.6.4 or later, or install your distribution's fixed package.
- Where you cannot upgrade yet, make every call pass a pointer to NULL as the head argument.
- Review the code after each call so it does not keep using memory that the function freed.
- Ask vendors of embedded devices for their status, since firmware updates can lag.
If you want a quick look at what your own projects pull in, the free in-browser dependency scan at https://gold.safeguard.sh/scan needs no setup. The Gold directory lets you look up other CVEs by id.
Why it matters
The record classifies this as CWE-416, use after free. A use after free happens when a program keeps a pointer to memory after it was released. If the memory is later reused, the old pointer can read or overwrite data that belongs to something else. A double free is a close relative, where the same block is released twice.
What is unusual here is that the bug starts with documentation. The function takes an output argument and its documentation does not say it will free the list it is given, yet it does. Code written exactly as documented ends up holding stale pointers. Version 3.6.4 now makes the function return an error if it is passed anything other than a pointer to NULL, so the misleading behavior is blocked.
The advisory notes that depending on the allocator, the result is likely to be arbitrary code execution. Whether that is reachable in your product depends on how the function is used.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which Mbed TLS version fixes CVE-2025-47917?
Mbed TLS 3.6.4 and later 3.6 releases are not affected, per the project's advisory.
Am I affected if I never call mbedtls_x509_string_to_names?
The advisory says applications that do not call the function directly are not affected.
Sources
Last reviewed: 18 October 2026.
