#45: Know Your CVEs: The ESP-IDF Security Dashboard
There’s a question you should be able to answer about your shipping product at any moment: what known vulnerabilities are baked into the firmware running in the field right now? If you can’t answer that quickly, you have a problem.
The good news is that for ESP-IDF, Espressif has made answering that question almost effortless. Enter the ESP-IDF Security Dashboard.
What is the Security Dashboard
The dashboard is a daily-updated, automated scan of ESP-IDF’s stable releases and release branches for known vulnerabilities. Under the hood it runs esp-idf-sbom, which generates a Software Bill of Materials for a given IDF version and then cross-references every third-party component against the National Vulnerability Database (NVD), the US government’s public catalog of known CVEs.
That last part is the bit people miss. ESP-IDF isn’t just Espressif’s code. It bundles a pile of well-known third-party libraries: MbedTLS, the TF-PSA-Crypto stack, the TCP/IP stack, and more. A CVE in any of them is a CVE in your firmware, whether you wrote a single line touching that component or not. If you use the component, you inherit it’s CVE’s. The dashboard lets you filter by severity, by version, and export the results as JSON if you want.
It’s worth pairing the dashboard with the official ESP-IDF Vulnerabilities Guide, which documents the CVEs Espressif has explicitly assessed for the silicon and stack.
Let’s look at a real one
Let’s pull a real finding off the dashboard and actually understand it.
If you filter to v5.4 you’ll find CVE-2025-47917. Here’s how it shows up:
| Field | Value |
|---|---|
| CVE | CVE-2025-47917 |
| Component | mbed_tls 3.6.2 |
| Severity | High (CVSS 8.9) |
| Affects | MbedTLS before 3.6.4 (IDF v5.2 / v5.3 / v5.4) |
The short version: mbedtls_x509_string_to_names() takes a head argument that the documentation describes as an output. The docs give no hint that the function frees it. But internally the function calls mbedtls_asn1_free_named_data_list() on that argument, which does a deep free. So application code that follows the documented contract is left holding pointers to memory that’s already been freed — a textbook use-after-free, with a double-free close behind. MbedTLS’s own x509/cert_write and x509/cert_req example programs are affected when a SAN string contains more than one DN.
To be fair, it’s unlikely you would use this function directly but a) you could and b) you’re hoping that, internally, MbedTLS always uses it properly.
Real consequences
Use-after-free is one of the nastier memory-safety bugs because of where it leads. Freed memory gets reused; a dangling pointer then reads or writes something that now means something else. Ultimately, this can lead to a “random” crash that is hard to debug in your project.
The detail that makes this one sting is that you didn’t do anything wrong. You read the documentation, you treated head as an output parameter like it said, and you held onto your pointers. The bug is the gap between what the function documents and what it does. You would not find this by code-reviewing your own application, because your application is correct against the spec. The only realistic way you learn about it is a tool like the Security Dashboard.
Removing CVEs from your project
The dashboard doesn’t just tell you there’s a problem, it shows you what forward versions of IDF resolve each particular CVE so you have a clear upgrade path to resolve them. I specifically like that it doesn’t just say “Update to the latest.” I’ve cautioned before about trying to do to big of a version jump without knowing all the side effects. The dashboard will give you every fixed IDF version between your current version and the latest.
CVE-2025-47917 is fixed in MbedTLS 3.6.4. On an ESP32 you don’t pull MbedTLS yourself; you get whatever version your ESP-IDF release bundles. So the mitigation is concrete and visible right on the dashboard: move to an IDF release that ships a patched MbedTLS. Switch the version filter from v5.4 to v5.5 (which carries MbedTLS 3.6.5) or to v6.0 (MbedTLS 4.0.0), and see that the CVE is gone.
Disclaimer
This is something I learned going through the dashboard for my projects. A finding showing up on the dashboard does not automatically mean your firmware is vulnerable. Some CVEs come with trigger conditions that don’t apply to how ESP-IDF actually builds and runs.
On the dashboard, you can do a text search for CVE-2025-66442. In the mbed_tls 4.0.0 component, a timing side channel attack is possible in RSA and CBC/ECB decryption. That sounds really bad but if we keep reading we see that it “only occurs with LLVM’s select-optimize feature”
LLVM is a compiler, but not the compiler IDF uses to compile your firmware. ESP-IDF bundles GCC as the compiler so the condition this CVE requires to exist isn’t present in how your ESP32 firmware is actually compiled.
I wanted to call that out as a warning to not just blindly accept what the Security Dashboard tells you. Make sure you read the CVE’s and understand whether they truly affect you or not. Your IDF version could also have CVEs that don’t apply to your firmware because you are not using the affected components. Always review and confirm the findings.
Production Pointers
A few things you can do today:
- Bookmark the dashboard and actually look at it for the IDF versions you ship. Filter by your version, sort by severity and see what CVEs may currently be lurking in your deployed firmware.
- Review your CVEs. Based on your version of IDF, see what CVEs may apply and verify if they affect your firmware. If so, create a plan to address them.
- Treat the IDF version as a security control. A surprising number of findings clear simply by moving to a release with patched dependencies. The dashboard makes that mapping obvious.
Security as an afterthought is the most expensive way to do it. A bookmark and a quick review is one of the cheapest insurance policies you’ll ever buy on a production fleet.