eMudhra CA Compromise: HiveMQ Platform 4.56.1, 4.55.2, 4.28.31, Operator 2.3.1 and Edge 2026.15

Introduction

HiveMQ Platform 4.56.1, 4.55.2 and 4.28.31, HiveMQ Platform Operator 2.3.1, and HiveMQ Edge 2026.15 are security releases. They address the compromise of eight intermediate CA certificates of the certificate authority eMudhra. We rate it HIGH and describe it in HiveMQ security advisory: compromised eMudhra intermediate CA certificates.

The Docker images of these releases no longer trust the affected eMudhra root certificates. We recommend that all customers who run HiveMQ in Docker or on Kubernetes upgrade to a fixed version. Customers who run a ZIP distribution should update their Java runtime.

eMudhra CA Certificate Compromise

eMudhra generated the private keys of eight intermediate CA certificates in a way that lets anyone recover the keys from the public certificates. With these keys, an attacker can issue a certificate for any hostname. Any software that trusts the eMudhra root emSign ECC Root CA - G3, or the Sectigo root AAA Certificate Services through its cross-signs, accepts that certificate. Browser vendors blocked the intermediates between 17 and 22 October 2026. Java runtimes trust them until they are updated (CVE-2026-91403).

We have no reports of these certificates being used against HiveMQ or our customers.

Who is exposed

HiveMQ checks certificates against the Java default trust store in two cases:

Outbound TLS connections that use the Java default trust store. HiveMQ is the client and validates the server certificate. This applies to connections from the HiveMQ broker, HiveMQ Enterprise Extensions, and HiveMQ Edge to external services and to HiveMQ services. A connection uses the Java default trust store when no dedicated truststore is configured. Some connections have no truststore setting and always use it. To exploit this, an attacker must be able to intercept the traffic between HiveMQ and the remote server. With that position, the attacker can impersonate the remote server with a forged certificate, read or change the traffic, and capture credentials sent over the connection. If the remote server is an authentication backend, the attacker can impersonate it to HiveMQ.
TLS listeners (TCP or WebSocket) that use client authentication (REQUIRED or OPTIONAL) and have no truststore of their own. This applies to the HiveMQ broker and HiveMQ Edge. Such a listener checks client certificates against the Java default trust store and accepts a forged client certificate in the TLS handshake. Any authentication that HiveMQ requires after the handshake still applies, unless that authentication relies on a backend that HiveMQ reaches over an exposed outbound connection.

A listener with its own truststore checks client certificates against that truststore only. It is exposed only if that truststore contains one of the affected certificates.

What the releases change

The Docker images of these releases are built on an updated Eclipse Temurin base image. The affected root certificates are removed from both the operating system trust store and the Java trust store, which are separate files in the image. Java clients in these images reject TLS certificate chains that lead to emSign ECC Root CA - G3 or AAA Certificate Services. We verified the trust stores on amd64 and arm64, and checked that a TLS connection from the Java runtime to the test hosts of the public disclosure fails certificate validation.

HiveMQ Platform 4.56.1, 4.55.2 and 4.28.31: the Docker images of the HiveMQ Enterprise MQTT Broker, HiveMQ Swarm, and the HiveMQ MQTT CLI. The updated base image also includes the latest Ubuntu package updates, among them ca-certificates, openssl, and zlib1g.
HiveMQ Platform Operator 2.3.1: the Docker images of the HiveMQ Platform Operator and HiveMQ Platform Monitoring. The Operator's init image contains no CA certificates and makes no TLS connections.
HiveMQ Edge 2026.15: the HiveMQ Edge Docker images. This covers the outbound connections of HiveMQ Edge and closes the exposure of client-authentication listeners described above. For the other root CAs that the new base image no longer contains and how they affect existing connections, see HiveMQ Edge 2026.15 is Released.

Fixed versions

HiveMQ Platform, Docker image: 4.56.1, 4.55.2, 4.28.31
HiveMQ Edge, Docker image: 2026.15
HiveMQ Platform Operator for Kubernetes: 2.3.1
HiveMQ Platform and HiveMQ Edge, ZIP distribution: depends on the Java runtime you install. Update Java (step 2).

What you need to do

Upgrade to a fixed version. For Docker deployments, pull the fixed image (HiveMQ Platform 4.56.1, 4.55.2 or 4.28.31, or HiveMQ Edge 2026.15) and redeploy. If you use the HiveMQ Platform Operator for Kubernetes, upgrade the Operator to 2.3.1 and set your HiveMQ Platform image to a fixed version.
If you cannot upgrade yet, or you run the ZIP distribution, update your Java runtime to a vendor release that addresses CVE-2026-91403. The ZIP distributions of the HiveMQ Platform and HiveMQ Edge use the Java runtime that you install. If no update is available for your Java distribution, remove emSign ECC Root CA - G3 from the Java trust store, and AAA Certificate Services if your Java runtime ships it (some do, for example Azul Zulu 21).

This command finds each certificate by its SHA-256 fingerprint, so it does not depend on the alias name or the system language. It works on Java 11 and later. Run it with the keytool of the Java runtime that runs HiveMQ, as a user who can write to the Java installation:

for FP in \
  "86:A1:EC:BA:08:9C:4A:8D:3B:BE:27:34:C6:12:BA:34:1D:81:3E:04:3C:F9:E8:A8:62:CD:5C:57:A3:6B:BE:6B" \
  "D7:A7:A0:FB:5D:7E:27:31:D7:71:E9:48:4E:BC:DE:F7:1D:5F:0C:3E:0A:29:48:78:2B:C8:3E:E0:EA:69:9E:F4"; do
  ALIAS=$(keytool -J-Duser.language=en -list -v -cacerts -storepass changeit \
    | awk -v fp="$FP" '/^Alias name: /{a=substr($0,13)} index($0,fp){print a; exit}')
  if [ -n "$ALIAS" ]; then keytool -delete -cacerts -storepass changeit -noprompt -alias "$ALIAS"; fi
done
keytool -J-Duser.language=en -list -v -cacerts -storepass changeit \
  | grep -qE "86:A1:EC:BA:08:9C:4A:8D|D7:A7:A0:FB:5D:7E:27:31" \
  && echo "Certificate still present" || echo "Certificates removed"

Replace changeit if you changed the trust store password. Then restart HiveMQ.

Configure a dedicated truststore for each outbound TLS connection that supports one. A truststore that holds only the CAs you expect protects the connection from this compromise and from future CA compromises. The HiveMQ Enterprise Extensions for Google Cloud Pub/Sub, Amazon Kinesis, Data Lake and Snowflake, and the HiveMQ Enterprise Distributed Tracing Extension, have no truststore setting. For these, steps 1 and 2 close the exposure.
Give each listener that uses client authentication its own truststore, holding only the CAs that issue your client certificates. This closes the inbound exposure without an upgrade. Then check your listener truststores and any other custom truststores for the affected certificates, and remove any that you find. AAA Certificate Services also anchors other Sectigo certificate chains that are not affected. Before you remove it, confirm which CA issued your client certificates.
Update the operating system CA bundle, Java, and other runtimes on the hosts that run HiveMQ and on the systems that connect to it.

For the list of affected certificates with their fingerprints, see the HiveMQ security advisory: compromised eMudhra intermediate CA certificates.

PHP vulnerabilities (php2shell): HiveMQ products are not affected by CVE-2026-109618 and CVE-2026-109619. No HiveMQ product ships or embeds PHP.

Get Started Today

To upgrade HiveMQ from a previous version, follow the steps in the HiveMQ Upgrade Guide and review the Known Issues before you upgrade.

To learn more about all the features the HiveMQ Platform offers, explore the HiveMQ User Guide.