In Eclipse Arrowhead versions from 5.0.0 to 5.2.1 when the MQTT API is enabled with the certificate authentication policy, CertificateMqttF…

published 2026-09-03 2 mo ago modified 2026-09-03 2 mo ago also EUVD-2026-70467

cvss: 9.5; version 4.0, CNA
cisa kev: Not listed; not in CISA's catalog
epss: 0.3%; EPSS 0.3% chance of exploitation in 30 days, percentile 27%
public exploits: 0; none known

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.

CISA SSVC

Exploitation: none
Automatable: no
Technical impact: total
Assessed: 2 mo ago (2026-09-03)

Exploit prediction

0.34% chance of exploitation in the next 30 days, higher than 27% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by	version	score	vector
CNA	4.0	9.5	CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:H
CNA	4.0	9.5	CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Affected products

Eclipse Foundation Eclipse Arrowhead

Classification

Weakness

CWE-295 Improper Certificate Validation
CWE-290 Authentication Bypass by Spoofing

References

gitlab.eclipse.org /security/vulnerability-reports/-/work_items/812

Sources

CVE List CVE-2026-82180
NVD CVE-2026-82180

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.

Summary