CVE-2026-82180: Eclipse Arrowhead vulnerability

Q: Which deployments are exposed?

Deployments running versions 5.0.0 through 5.2.1 are exposed only when the MQTT API is enabled and uses the certificate authentication policy. The HTTP CertificateFilter is not affected.

Q: What does an attacker need to exploit this issue?

The attacker needs the ability to publish messages to the MQTT broker. They can use public identity values, including the cloud name from the server TLS certificate, to construct the required self-signed certificate.

Q: What level of access can exploitation provide?

An attacker can authenticate as the cloud system operator by supplying a self-signed certificate with an appropriate Subject DN. This sets isSysOp to true and grants full management access over MQTT.

Published Sep 3, 2026

Updated

In Eclipse Arrowhead versions from 5.0.0 to 5.2.1 when the MQTT API is enabled with the certificate authentication policy, CertificateMqttFilter parses an X.509 certificate that the client sends inside the MQTT message payload (the authentication field of MqttRequestTemplate) and treats its Subject DN as the authenticated identity. The certificate is decoded with CertificateFactory.generateCertificate() but its signature is never verified and its issuer chain is never validated against any trust store. Authorisation is reduced to two string comparisons on attacker-supplied data: the DN-qualifier must equal "sy" or "op", and the cloud-name part of the CN must match the server's. Both values are public (the cloud name is in the server's own TLS certificate). An attacker who can publish to the MQTT broker can therefore mint a self-signed certificate with CN=Sysop.<cloud>.<org>.arrowhead.eu, dnQualifier=op, send it as the authentication field, and be authenticated as the cloud's system operator with isSysOp == true. This passes the downstream ManagementServiceMqttFilter (request.isSysOp() → allowed) and gives full management access over MQTT. The HTTP CertificateFilter is not affected — it reads the certificate from jakarta.servlet.request.X509Certificate, which Tomcat populates only after a successful mTLS handshake against the configured trust store.

Affected Software

1 affected component

Eclipse Arrowhead>=5.0.0<=5.2.1

Event History

Sep 3, 2026

CVE Published

via MITRE·01:20 PM

Data Sourced

via MITRE·01:20 PM

DescriptionWeakness

Frequently Asked Questions

Which deployments are exposed?

Deployments running versions 5.0.0 through 5.2.1 are exposed only when the MQTT API is enabled and uses the certificate authentication policy. The HTTP CertificateFilter is not affected.

What does an attacker need to exploit this issue?

The attacker needs the ability to publish messages to the MQTT broker. They can use public identity values, including the cloud name from the server TLS certificate, to construct the required self-signed certificate.

What level of access can exploitation provide?

An attacker can authenticate as the cloud system operator by supplying a self-signed certificate with an appropriate Subject DN. This sets isSysOp to true and grants full management access over MQTT.