CVE-2026-82180

CriticalCVSS 9.5

Published: 03/09/2026(UTC)Updated: 03/09/2026(UTC)Translated: 03/09/2026(UTC)NVD NIST

Summary

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 and treats its Subject DN as the authenticated identity. The certificate is decoded but its signature is never verified and its issuer chain is never validated against any trust store. An attacker who can publish to the MQTT broker can mint a self-signed certificate with CN=Sysop.<cloud>.<org>.arrowhead.eu and dnQualifier=op to gain full management access over MQTT.

Risk Assessment

The risk includes unauthorized access to system management functions via MQTT, potentially leading to full compromise of the Arrowhead cloud.

Recommendation

It is recommended to disable the MQTT API with certificate policy or implement signature and certificate chain verification against a trusted store.

Other vulnerabilities in Eclipse Arrowhead

CVE-2026-80515High
In Eclipse Arrowhead versions from 5.0.0 to 5.2.1, the management-authorization gate protecting every /…/mgmt/… REST endpoint decides whether to apply its check by calling request.getRequestURL().toString().contains("/mgmt/"). Tomcat returns getRequestURL() un-decoded, while Spring MVC's DispatcherServlet routes on the decoded path. Requesting /serviceregistry/%6Dgmt/systems (%6D == m) fails the substring check but is decoded to /serviceregistry/mgmt/systems and dispatched to the management controller. Any authenticated system can reach every management operation, including creating sysop accounts, leading to full administrative takeover of the local cloud.

Original NVD description (English source)

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.