We’ve released NXLog Agent 6.16.2 and NXLog Platform 1.15.1 in response to the compromise of eight eMudhra certificate authorities (CVE-2026-111943). If you use NXLog Agent to send data to cloud services over TLS, we recommend upgrading as soon as you can and making sure your operating system’s certificate bundle is up to date. We’re making this recommendation out of an abundance of caution. At this time, we’re not aware of this issue being exploited in the wild.

Summary

Attackers compromised the private keys of eight eMudhra certificate authorities, allowing them to forge trusted TLS certificates for any website. Browsers and operating systems have blocked these CAs, but software that carries its own list of trusted CAs needs an update. NXLog Agent 6.16.2 fixes the modules that bundle their own certificates, and NXLog Platform 1.15.1 applies the same fix to its own outgoing connections.

What to do:

  • Patch hard-to-update hosts first, such as appliances and air-gapped or legacy systems.

  • Upgrade your NXLog Agent instances to 6.16.2. Upgrading NXLog Platform alone doesn’t fix them.

  • Upgrade NXLog Platform On-Premises to 1.15.1.

  • Update the certificate bundle on every agent host’s operating system. This protects all other modules that use the operating system’s trust store. On Windows, install the latest updates. On Linux, update the ca-certificates package. On macOS, follow Apple’s guidance for /etc/ssl/cert.pem.

Here’s the background and what it means for your NXLog deployment.

What happened

On October 17, 2026, a security researcher showed that the private keys of eight intermediate certificate authorities (CAs) operated by eMudhra could be recovered from their public certificates. The keys had been generated with too little randomness in April 2025. Six of these CAs issue TLS certificates; the other two issue code-signing certificates.

A CA’s private key is what makes its certificates trustworthy. With these keys, anyone can issue a certificate for any hostname, and any client that still trusts the eMudhra chain will accept it. That opens the door to man-in-the-middle attacks on outbound TLS connections: an attacker who can intercept traffic can impersonate the server your software is connecting to. The researcher also demonstrated forged certificates that were never published to Certificate Transparency logs, so this kind of interception could leave no public trace.

How it affected NXLog Agent

NXLog Agent verifies TLS certificates in one of two ways, depending on the module.

Modules that use the operating system’s trust store

Most modules, including the HTTP, TCP/SSL, and Elasticsearch output modules, rely on the operating system to decide which CAs to trust. They’re protected as soon as the host’s certificate bundle no longer trusts the compromised CAs. These modules don’t need an NXLog Agent upgrade, but the host’s certificate bundle must be current.

Modules that bundle their own trusted certificates

Several Rust-based integration modules, such as Azure Monitor, Microsoft 365, OpenTelemetry, and the Google Cloud modules, ship with a built-in list of trusted CAs. An OS update doesn’t change that list, and in our testing, these modules accepted forged certificates from the compromised chains.

NXLog Agent 6.16.2 fixes these modules. We moved them to an updated TLS stack that includes fixes from RUSTSEC-2026-0382 and RUSTSEC-2026-0381 as part of our response to CVE-2026-111943. CVE-2026-111943 was first published for the Go programming language’s fix for this incident, and the two Rust advisories, which link to the same CVE, cover the matching fixes in the Rust TLS libraries our modules use. We verified the fixed build against the researcher’s test servers: it rejects every forged chain, including the ones that were never logged to Certificate Transparency, and still connects to servers with valid certificates.

How it affected NXLog Platform

NXLog Platform makes its own outgoing TLS connections to external services, and it verifies them with the same kind of Rust TLS library. NXLog Platform 1.15.1 updates that library to rustls-webpki 0.103.16, so NXLog Platform instances now reject certificates from the compromised CAs. This protects connections from your NXLog Platform instance to external services against man-in-the-middle attacks.

Upgrading NXLog Platform alone doesn’t fix your NXLog Agent instances. Each NXLog Agent instance makes its own TLS connections to its destinations, so you still need to upgrade every instance to 6.16.2.

What you should do

  1. Prioritize hosts that are hard to update. Appliances, air-gapped systems, and hosts that rarely get patched are the most likely to still trust the compromised CAs. If those hosts send data over the internet, update them first.

  2. Upgrade NXLog Agent to 6.16.2. This is the only way to fix the modules that bundle their own certificates. See the NXLog Agent release notes for details.

    PowerPC and SPARC: There’s no 6.16.2 package for these platforms, and you don’t need one. The NXLog Agent builds for PowerPC and SPARC don’t include the affected Rust modules, so updating the operating system’s certificate bundle is all you need to do.

  3. Upgrade NXLog Platform On-Premises to 1.15.1. Follow the upgrade guide. See the NXLog Platform release notes for details.

  4. Update the certificate bundle on every agent host. This covers all modules that use the operating system’s trust store.

    • Windows: Install the latest Windows updates, including Microsoft’s out-of-band update from October 26.

    • Linux: Update the ca-certificates package with your distribution’s package manager. For example, run sudo apt install --only-upgrade ca-certificates on Debian and Ubuntu, or sudo dnf update ca-certificates on RHEL-based systems. Distributions ship this update on their own schedules, so check that yours has released it.

    • macOS: Apple’s block applies to Safari, Mail, and apps that use Apple’s networking frameworks, but not to the /etc/ssl/cert.pem file that OpenSSL-based software reads. Until Apple ships a macOS update that changes this file, follow Apple’s instructions to remove the affected root, or point the CA file settings in your NXLog Agent configuration at an up-to-date certificate bundle. A macOS update can replace /etc/ssl/cert.pem, so check it again after updating.

If your NXLog Agent instances only trust your own private CA, they don’t accept a forged eMudhra certificate. We still recommend upgrading.

Check a host (optional)

The researcher runs a test server that presents a certificate from a compromised CA. From the agent host, run:

$ curl -v https://dv-g3b-emudhra.we-have-a-problem.com/

A certificate error means the host’s trust store no longer trusts the compromised CAs. A successful connection means it still does, and you should update the certificate bundle. This checks the operating system’s trust store; only upgrading NXLog Agent fixes the modules with bundled certificates.

References

If you have questions about your deployment, our support team is happy to help.

NXLog Platform is an on-premises solution for centralized log management with
versatile processing forming the backbone of security monitoring.

With our industry-leading expertise in log collection and agent management, we comprehensively
address your security log-related tasks, including collection, parsing, processing, enrichment, storage, management, and analytics.

Start free Contact us
Share
Related Posts