On October 21, 2026, Node.js released a security update addressing CVE-2026-111497, a remote code execution vulnerability in its bundled Brotli decoder. The same release updated its root certificates and added checks for blocked public keys following the compromise of eight eMudhra intermediate certificate authorities.
The incidents are unrelated. Node2Shell involves memory corruption, while eMudhra involves CA private keys recoverable from public certificates. But both sit within components that applications trust without controlling: a decoder that handles external data, and a certificate authority that vouches for who is on the other end. One is about what happens when untrusted data reaches a vulnerable component. The other is about whether that data came from the service the application meant to contact.
Node2Shell: from compressed data to code execution
Node2Shell, as Imperva named the vulnerability, affects the Brotli decoder used by Node.js to decompress HTTP traffic. When the decoder encounters an invalid block transition, it continues processing instead of rejecting the data, writing beyond the allocated buffer.
Imperva demonstrated remote code execution on the official Node.js 24.22.0 Linux arm64 image using malicious Brotli data in HTTP request bodies and responses processed by fetch(). The researchers needed several attempts to achieve code execution.
Not every Node.js application is exposed. A basic HTTP server doesn’t automatically decompress Brotli requests, but Express applications with compatible body parsers can. The built-in fetch() API also decompresses Brotli responses, creating another entry point.
Node.js fixed the vulnerability in versions 22.23.4, 24.22.1 and 26.12.1.
Exploitation has already moved beyond laboratory demonstrations
On October 27, CISA added CVE-2026-111497 to its Known Exploited Vulnerabilities catalog. Researchers have observed exploitation attempts against vulnerable Node.js installations, although the publicly analyzed attempts have not established successful compromise.
The bigger issue is that Brotli isn’t specific to Node.js. The underlying bug is in Google’s Brotli library, which is used by other applications and runtimes, so other software bundling affected versions needs to be checked separately. Whether a particular application is exposed depends on how the library is integrated and whether untrusted data reaches the vulnerable decoder.
eMudhra: When a trusted CA key isn’t secret
Four days earlier, on October 17, a researcher reported that eight eMudhra intermediate CAs had private keys recoverable from their public certificates. Although the keys used P-384, their private values were smaller than 256, making recovery a matter of checking at most 256 possibilities. That wasn’t an elliptic-curve weakness.
According to eMudhra’s preliminary explanation, a mistake during an April 2025 key-generation ceremony led to a weaker set of keys being used. The keys remained recoverable for roughly 18 months. There is no confirmed exploitation, but they could have been used to issue forged certificates. Six intermediates were for TLS and two for code signing, and eMudhra says none issued end-entity certificates.
Chrome blocked the affected TLS keys on October 17, followed by Firefox. Google found no TLS certificates from the affected intermediates in Certificate Transparency logs before the block. That protected browsers, but many applications don’t receive browser blocklists.
Sectigo had also cross-signed all eight intermediates, creating alternative certificate chains involving the same compromised keys. It revoked those certificates on October 19, but clients without updated trust or revocation information could still accept an affected chain.
Google removed the emSign ECC Root CA - G3 from the Chrome Root Store, with distribution scheduled for October 27. This also affects legitimate certificates under that root. On October 22, eMudhra announced that it was leaving the global TLS certificate business, so organizations using its publicly trusted TLS certificates need a replacement plan.
Apple's response shows why updating trust isn't always straightforward. Apple began blocking the compromised TLS intermediates on October 19 and the affected root on October 23. Safari, Mail, and applications using Apple's security frameworks receive these protections automatically. But some macOS command-line tools, including curl and git, can still accept the affected certificates because they use a separate certificate bundle. Apple says a future software update will address this gap.
One release, both fixes
That brings us back to Node.js. Version 24.22.1 included the Brotli fix, TLS hostname-verification fixes, updated NSS root certificates removing trust in the emSign ECC Root CA - G3, and checks for blocked public keys.
Shipping a fix is only half the job. Trigger.dev updated its Node.js runtimes and removed trust in the compromised eMudhra CAs in v4.7.7, but existing deployments still need to be redeployed. The same applies to containers: patching the host doesn’t update an old Node.js binary or CA bundle inside an image.
What this means for machine identities
The two problems threaten credentials in different ways. Successful Node2Shell exploitation grants an attacker code execution inside the application process, putting credentials accessible to that process at risk.
With eMudhra, an attacker who can redirect a connection and present a forged certificate accepted by the client could impersonate a trusted service. This could expose authentication tokens sent to that service. But the same trusted connection could also be used to deliver malicious content to the application.
For example, the attacker could return a Brotli-compressed response to a vulnerable Node.js application. If the application processes it through the affected decoder, the certificate compromise could provide a delivery path for Node2Shell.
There's no public evidence that the eMudhra keys were exploited or that this combined attack has occurred.
What's next?
In the next blog of this series, we will look at whether the two vulnerabilities can be combined into a working attack chain. Can a forged certificate be used to deliver a malicious Brotli response to a vulnerable Node.js application? What conditions would make that possible, and where would the attack fail?
We'll also investigate the broader impact of the Brotli vulnerability. Node.js is one affected implementation, but the underlying library is used elsewhere. The question is which other applications expose the vulnerable decoder to untrusted data, and whether the impact goes beyond what Imperva demonstrated.
Our next blog will focus on what happens after a successful compromise, particularly the risks to application credentials, service accounts, and other machine identities.
