Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
9.5
CVE-2026-82180: Eclipse Arrowhead 5.0‑5.2.1 permits MQTT takeover
CVE-2026-82180 · published today
Summary
Eclipse Arrowhead versions 5.0.0 through 5.2.1 let anyone who can publish to the MQTT broker pretend to be the system administrator. The software reads a digital ID sent in the message but never checks that the ID is signed by a trusted source, so a fake ID can be accepted. Upgrade to a newer Arrowhead release or turn off certificate‑based authentication for MQTT until a fix is applied.
What to do
The CVE record does not list a fixed version. Check the vendor's site or the advisory links below - a fix may already be released.
Affected software
| Vendor | Product | Affected versions |
|---|---|---|
| eclipse foundation | eclipse arrowhead | <= 5.2.1 |
Original advisory text
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 in...
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.
Severity
9.5
Critical
Type
CWE-295Improper Certificate Validation
CWE-290Authentication Bypass by Spoofing
Timeline
Published3 Sep 2026
Updated3 Sep 2026
First seen3 Sep 2026
Monitor software like this
Free during beta