In August 2020, the maintainers of the widely embedded Mbed TLS library released version 2.24.0 to fix a certificate validation flaw that could allow an attacker to impersonate any domain name by obtaining a digital certificate for a carefully chosen IP address. The vulnerability, tracked as CVE-2020-36477, arose because the library’s hostname verification routine failed to distinguish between different types of Subject Alternative Name entries, treating a raw IP address in a certificate as if it were a DNS hostname. The result: under specific conditions, a TLS client could be tricked into trusting a server that holds a certificate for an IP address, even when connecting to a completely unrelated domain.

The Bug: Type‑Blind SAN Comparison

X.509 certificates use the Subject Alternative Name (SAN) extension to list all the identities a certificate covers—DNS names, IP addresses, email addresses, and other identifiers. Standards like RFC 6125 require implementations to handle each SAN type differently. A DNS name is matched using DNS‑specific rules (case‑insensitive, with wildcard support), while an IP address SAN holds a binary representation that must be compared octet‑by‑octet against the expected IP address. Mbed TLS versions before 2.24.0, however, skipped the type check entirely. When the library was asked to verify a hostname, it simply compared the raw bytes of the expected name against the contents of every SAN entry, regardless of whether that entry was a dNSName, iPAddress, or any other type.

The flaw can be demonstrated with an IP address like 97.46.112.108. Those four octets—97, 46, 112, 108—correspond to the ASCII characters ‘a’, ‘.’, ‘p’, and ‘l’, which together spell the domain a.pl. An attacker who controls that IP address and obtains a certificate containing an iPAddress SAN for 97.46.112.108 could present that certificate to a vulnerable Mbed TLS client attempting to connect to a.pl. Because the library compared bytes without checking types, the client would see a match and accept the certificate, even though it never extended to the domain a.pl in a standards‑compliant sense.

This is not a theoretical curiosity. While the exploit path requires several preconditions—the attacker must control a specific IP address whose octets form a meaningful hostname, and a certificate authority must be willing to issue a certificate for that IP—the bug undermines the fundamental correctness of TLS hostname verification. Mbed TLS is embedded in countless IoT devices, network appliances, and firmware images, many of which perform TLS client authentication and rely on the library’s verification function. The maintainers corrected the issue by adding an explicit SAN type check: the library now compares DNS names only against dNSName entries and IP addresses only against iPAddress entries. The patch also includes unit tests that explicitly verify that a DNS name no longer matches an IP SAN.

Why It Matters for Your Devices and Code

The practical impact varies by audience. For the average home user, the risk is indirect. You are unlikely to encounter an attacker who controls a conveniently byte‑aligned IP address and can divert your traffic to it. However, if you use older IoT devices—routers, smart cameras, industrial sensors—that rely on Mbed TLS for outbound connections to cloud services, the vulnerability might still exist in those devices’ firmware. A compromise could allow an attacker to masquerade as the cloud endpoint and intercept data or inject malicious commands.

IT administrators should pay closer attention. Many enterprise environments use embedded Linux devices or appliances that statically link Mbed TLS. If your asset inventory includes devices shipped before 2021 that have never received a firmware update, they could still be running a vulnerable version. The bug is particularly dangerous on internal networks where private certificate authorities issue IP‑address certificates with minimal vetting. In such a setting, an insider with control over an IP address that maps to a useful hostname (like a short internal service name) could impersonate that service to any vulnerable client.

For developers, the takeaway is clear: if you build software that bundles Mbed TLS, check your dependency version immediately. The fix is available in release 2.24.0 and has been backported to the 2.7 and 2.16 LTS branches. If you call mbedtls_x509_crt_verify or a similar API to validate hostnames, your code is directly affected. The library’s own documentation now clarifies that the cn parameter expects a DNS name only when verifying DNS identities; passing an IP address as a string is not supported and will not produce correct results.

How the Flaw Went Undetected

Mbed TLS started as PolarSSL, a lightweight TLS library targeting embedded systems. Its X.509 verification logic was written to be small and efficient, but the initial implementation of SAN matching overlooked the type field. For years, the code simply iterated over all SAN entries and performed a raw byte comparison against the passed‑in name. The omission persisted because the common case—comparing a DNS name against a dNSName SAN—worked perfectly. Only when a certificate includes non‑DNS SAN types and the expected name happens to collide byte‑for‑byte with one of those values does the bug manifest.

The issue was reported through the library’s issue tracker in early 2020. A fix was authored and merged in August 2020, just before the 2.24.0 release. The patch not only added the type‑aware comparison but also introduced a battery of test vectors that deliberately mix SAN types to ensure regressions are caught. Downstream distributions reacted quickly: Debian issued DSA‑4760, Ubuntu updated their mbedtls package, and Gentoo published GLSA 202009‑02, all directing users to upgrade. Microsoft, which includes Mbed TLS in some Azure Sphere components, also issued an advisory via the Microsoft Security Response Center, linking to the official CVE entry.

Despite the prompt upstream fix, the vulnerability’s lifecycle is a textbook example of the embedded security update problem. Many devices that shipped with Mbed TLS 2.16 or 2.7 LTS will never receive an over‑the‑air update. The fix exists, but its deployment into millions of resource‑constrained endpoints is far from guaranteed. This gap between availability and adoption is the real operational headache.

What to Do Right Now

Start by finding every product or internal tool that embeds Mbed TLS. If you maintain a Linux distribution, package manager queries can surface the installed version. For bespoke firmware, examine build logs, vendor documentation, or use binary scanning tools to identify the library version. Once you know what you have, follow these steps:

  • Upgrade to Mbed TLS 2.24.0 or later. This is the simplest path. If you are on an LTS branch (2.7 or 2.16), apply the backported patch released by ARM Mbed. For many applications, rebuilding against the updated library and redeploying is sufficient.
  • Apply the patch manually if you cannot move to a new release. The commit that fixes the bug is publicly available. It modifies the x509_crt_check_san function to compare type_id values before calling memcmp. Integrate it into your source tree and recompile.
  • Implement workarounds when upgrading is impossible in the short term. Configure your TLS client to reject certificates that contain iPAddress SANs when connecting by DNS hostname. This can be done in application code by inspecting the certificate chain before passing it to the verification function. While not foolproof—other SAN types could also trigger false matches—it raises the bar significantly.
  • Audit your certificate issuance policies. If you operate a private CA, restrict the issuance of IP address certificates to cases where they are absolutely necessary, and never sign them for IPs that could collide with sensitive hostnames. Monitor Certificate Transparency logs for suspicious IP‑certificate registrations that mirror your service names.
  • Add regression tests. For developers, the most durable defense is to write unit tests that validate correct SAN type handling. Ensure that your code never accepts a certificate for a DNS name when the SAN entry is an iPAddress, URI, or other unexpected type. The Mbed TLS project’s own test suite is a good model.

A Wake‑Up Call for Embedded Security

CVE-2020-36477 will not be the last vulnerability of its kind. As IoT deployments soar, the cryptographic libraries that secure them remain a juicy target. The Mbed TLS team moved fast to fix a bug that had lain dormant for years, but the real challenge is bridging the gap between a patch’s release and its installation on every device. For users, the immediate action is to verify that any Mbed TLS–powered gear in your home or office has been updated. For the industry, this incident reinforces a hard truth: certificate validation must be implemented with pedantic fidelity to standards. Type information is not incidental; it is the bedrock of identity. When that bedrock cracks, even cleverly constrained attacks can become real.

Watch for firmware bulletins from device vendors and continue to pressure them for timely updates. The fix is free and proven; the remaining work is getting it into the hands of every user who needs it.