October 21, 2026
\n7-minute read
\nIf you are a software engineer, or generally work in the tech industry, there is\na good chance that you heard about the eMudhra Intermediate CA\nCompromise that was disclosed\nyesterday\n(October 20, 2026). If you don’t, you may have noticed an uptick in software\nupdates for various products that you use.
\nI won’t go through the entire background of the situation as there are plenty of\nother posts, including the now public bug\nreport from Mozilla, that\ndescribe the details of the compromise. However, I have had a number of folks\nreach out regarding the impact on IoT devices, specifically microcontroller\n(MCU) class devices. Some of them may have been motivated by the discourse\naround the compromise, such as Russ Cox’s Bluesky\npost, which included the\nfollowing sentence.
\n\nIOT boxes that can’t or don’t update are now trivially MITM’able forever.
Scott Helme’s\npost,\nwhich is at the top of Hacker News as of writing, also included a strong\nwarning.
\n\nIoT, embedded and OT devices. Cameras, routers, cars, medical devices,\nsmart appliances, payment terminals and industrial controllers phoning home\nfor commands and updates. Their bundles are frozen until 2039, which is the\n“cannot be contained” point made real.
IoT is a tricky moniker these days. If you consider a single board computer,\nlike a Raspberry Pi (or really anything running Linux), to be an IoT device,\nthen there is a good chance that the aforementioned assertions are correct. You\nhopefully have an OTA update solution for these devices, and you should update\nthem as soon as possible. On the other hand, if you have a fleet of MCUs, you\nprobably are not (directly) impacted by the compromise. In order to understand\nwhy, it is necessary to have at least a cursory understanding of public key\ninfrastructure (PKI), and specifically web PKI.
\nOn the device you are reading this post on, there is a bundle of root\ncertificate authority (CA) certificates. In fact, there are almost certainly\nmultiple CA certificate bundles because your platform (i.e. operating system)\nships a bundle, and your browser might as well. Mozilla has maintained a\ndedicated CA Certificate Program since the\ninitial launch of\nFirefox,\nand Chrome followed suit when it announced its root program in\n2022.\nThese root certificates are “trust anchors” that allow internet services that\nyou communicate with to prove that they are who they say they are. Every website\nthat you navigate to over HTTPS in your browser is verifying its identity by\npresenting one or more certificates that can be traced back to one of the CA\ncertificates in the client’s bundle. For example, when you visited this blog\npost, the server that hosts it presented your browser with the following\ncertificate chain.
\nCertificate chain\n 0 s:CN=danielmangum.com\n i:C=US, O=Let's Encrypt, CN=YR1\n a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption\n v:NotBefore: Aug 24 08:02:52 2026 GMT; NotAfter: Nov 22 08:02:51 2026 GMT\n 1 s:C=US, O=Let's Encrypt, CN=YR1\n i:C=US, O=ISRG, CN=Root YR\n a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption\n v:NotBefore: Sep 3 00:00:00 2025 GMT; NotAfter: Sep 2 23:59:59 2028 GMT\n 2 s:C=US, O=ISRG, CN=Root YR\n i:C=US, O=Internet Security Research Group, CN=ISRG Root X1\n a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption\n v:NotBefore: May 13 00:00:00 2026 GMT; NotAfter: Sep 2 23:59:59 2032 GMTYou can use openssl s_client -showcerts -verify 5 -connect danielmangum.com:443 to see it for yourself.
The first certificate (danielmangum.com) specifies that it is signed by the\nsecond (YR1), and the second by the third (Root YR). The third specifies its\nissuer as ISRG Root X1, which is the very popular Let’s Encrypt root CA\ncertificate that is present in\nevery\nmajor\ntrust\nstore.\nBecause ISRG Root X1 is present in your trust store and the server sent you\nthe necessary set of certificates to establish a chain of trust to that trusted\nroot, you can be confident that you are in fact talking to danielmangum.com.\nLet’s Encrypt has a helpful diagram\ndescribing this chain of trust.
While establishing a secure connection to this site specifically may not be\ncritical, this system is what allows us to perform sensitive operations, such as\nsending private messages, managing our bank accounts, and paying for items with\na credit card without fear of an attacker stealing the data. In the eMudhra\ncompromise, eight intermediate CA certificates, similar to Root YR and YR1\nabove, had their private keys accessible on the public internet. The private\nkeys also happened to be extremely weak, with the top 376 bits of the P-384 keys\nbeing all zeroes. One of the private keys was literally the number 4\n(00000100). This means that someone with even moderate technical capabilities\ncould easily issue themselves a leaf certificate (like danielmangum.com), then\npresent the leaf and the intermediate, and it would be trusted by every trust\nstore that included eMudhra’s root CA certificate. Unfortunately, that included\nall the same major root programs.
Some clients, namely browsers, also require that a leaf certificate be included\nin a certificate transparency (CT) log\nin order to be trusted. This has allowed for the major browsers to assert with\nrelative confidence that users of\ntheir software were not impacted, whereas other software very well may have\nbeen.
\n\nThe private keys for the intermediate certificates were incorrectly generated\nby the CA. This means that anyone can recover them from the certificates.
\nThis would have been possible since the certificates were created in April
\n
There are no entries in the certificate transparency logs for these
intermediates in that period, indicating that CT-enforcing clients like\nFirefox, Chrome, Edge and Safari could not have been attacked.
\nHowever, many clients outside of the browser ecosystem do not enforce\nCertificate Transparency. We do not know if attackers exploited the flawed key\ngeneration to target these clients.
The disclosure of this compromise led to a mad dash across programming\nlanguages,\ndeveloper tools, OS\npackages,\nand essentially any software involved with establishing a TLS\nconnection, to either\nfilter for these compromised intermediates, or reject the eMudhra root CA\ncertificate entirely. To say the issue is widespread would be an understatement.
\nSo why are MCUs unlikely to be impacted? In short, because of resource\nconstraints. While including a bundle, or multiple bundles, of\nX.509 certificates on a server, desktop\nmachine, or even a single board computer has trivial impact (what’s a few\nkilobytes among friends?), we have to be much more judicious when targeting\ndevices that often have less than, sometimes much less than, 1 MB of\nnon-volatile storage. Furthermore, rather than relying on an OS or browser\nvendor to go through the painstaking process of evaluating and monitoring\ncandidate root CA certificates, we are typically responsible for the entire\nsystem, either building bare metal applications or leveraging lightweight Real\nTime Operating Systems (RTOS).
\nFor example, the HTTP\nGET\nsample in the Zephyr RTOS\nconnects to google.com. Its trust chain looks as follows.
Certificate chain\n 0 s:CN=*.google.com\n i:C=US, O=Google Trust Services, CN=WE2\n a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA256\n v:NotBefore: Sep 28 18:38:33 2026 GMT; NotAfter: Dec 21 18:38:32 2026 GMT\n 1 s:C=US, O=Google Trust Services, CN=WE2\n i:C=US, O=Google Trust Services LLC, CN=GTS Root R4\n a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA384\n v:NotBefore: Dec 13 09:00:00 2023 GMT; NotAfter: Feb 20 14:00:00 2029 GMT\n 2 s:C=US, O=Google Trust Services LLC, CN=GTS Root R4\n i:C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA\n a:PKEY: EC, (secp384r1); sigalg: sha256WithRSAEncryption\n v:NotBefore: Nov 15 03:43:21 2023 GMT; NotAfter: Jan 28 00:00:42 2028 GMTRather than having a generic set of root CA certificates that covers the\nmajority of the internet, the sample only includes the single root CA\ncertificate\n(GlobalSign R1) that is needed to verify google.com. It is nearly 1 KB (DER\nencoded) on its own, but the size of the certificate is not the only\nconsideration. Enabling all signing algorithms, curves, and hashing algorithms\nused throughout the certificate chain can have a significant impact on code size\nas well. Additionally, buffer sizes must be configured to accommodate the full\nchain; the longer the chain, the more memory that needs to be allocated.
These constraints can lead to frustrating errors and complex debugging sessions.\nHowever, there is something to be said for building a system that is only\nfocused on accomplishing a fixed, well defined set of tasks. When situations\nlike the eMudhra compromise arise, I find myself appreciating the inherent\nlimitations of these devices and the intention that goes into building the\nfirmware that runs on them. Perhaps this event is an opportunity for us to\nevaluate whether some of that intention can be applied in other domains.
\nUnless your MCU needs to connect to a server that uses a chain of trust rooted\nin an eMudhra root CA certificate, and you included it (or the Sectigo root CA\ncertfificate used for\ncross-signing) in your\nfirmware, your devices are likely safe from this specific vulnerability. Now all\nyou have to do is make sure that you patch all of your CI environments,\ndeveloper tooling, cloud services, and productivity software.
","headings":[{"level":1,"text":"Your MCU Likely Escaped the eMudhra Intermediate CA Compromise","id":"your-mcu-likely-escaped-the-emudhra-intermediate-ca-compromise"}]}}