CVE-2026-82180

Eclipse Arrowhead's CertificateMqttFilter (versions 5.0.0 through 5.2.1, when the MQTT API runs with the certificate authentication policy) accepts an X.509 certificate supplied inside the MQTT message payload and treats its Subject DN as the authenticated identity without verifying the certificate's signature or validating its chain against a trust store. An attacker who can publish messages to the MQTT broker can therefore mint a self-signed certificate with CN=Sysop.<cloud>.<org>.arrowhead.eu and dnQualifier=op, since the only checks are two string comparisons on attacker-controlled values whose expected contents are publicly known. This grants authentication as the cloud's system operator (isSysOp == true), passing the downstream ManagementServiceMqttFilter and yielding full management access over MQTT. Only deployments that enable the MQTT API with certificate authentication are affected; the HTTP CertificateFilter is not impacted because it uses the certificate from the Tomcat mTLS handshake, which is validated against a trust store. No public proof-of-concept, KEV listing, or in-the-wild exploitation is known, and EPSS puts 30-day exploitation probability at roughly 0.2%.

What to do: Upgrade to an Eclipse Arrowhead release newer than 5.2.1 once a fixed version is published per the Eclipse security advisory ([email protected] CNA). As mitigations, restrict publish access on the MQTT broker with broker-level authentication and ACLs so only trusted clients can publish, or disable the MQTT API / switch its authentication away from the certificate policy until patched. When reviewing deployments, check whether the MQTT API is enabled with certificate authentication and whether the broker is reachable by untrusted clients; the HTTP (mTLS) path does not require action.