Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach Arrowhead MQTT broker
-
DeliveryRead public cloud name from server TLS cert
-
ExploitMint self-signed cert CN=Sysop.<cloud>, dnQualifier=op
-
ExecutionPublish cert in MqttRequestTemplate authentication field
-
PersistCertificateMqttFilter trusts unverified DN, sets isSysOp
-
ImpactGain full cloud management access
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V12 - Secure Communication Certificate validation
|
| Exploitation Conditions | Requires the Eclipse Arrowhead MQTT API to be enabled AND configured with the certificate authentication policy - this is the specific non-default deployment condition without which the vulnerable CertificateMqttFilter is never invoked. The attacker must be able to publish to the Arrowhead MQTT broker (network reachability to the broker plus any broker-level publish access). No prior Arrowhead authentication, credentials, or valid certificate is needed, and no user interaction is required; the only 'secret' inputs (cloud name, dnQualifier values) are public. Deployments using only the HTTP interface, or MQTT without the certificate authentication policy, are not exploitable via this path. |
| Impact | The provided CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:H, score 9.5) aligns well with the described impact: network-reachable, low-complexity, unauthenticated, yielding both confidentiality and integrity compromise plus a scope change into the managed systems. The AT:P (attack requirement present) metric correctly captures that this is not a default state - the MQTT API must be enabled AND set to the certificate authentication policy; deployments using only the HTTP interface are unaffected. There is no EPSS or CISA KEV data supplied, so exploitation status is 'no public exploit identified at time of analysis' - but the advisory documents a fully working forgery recipe, so weaponization difficulty is trivial for anyone who reads it. Because a successful bypass grants full sysop-level management over the local cloud, any organization running an exposed MQTT-enabled Arrowhead cloud should treat this as urgent rather than theoretical. The one genuine limiter is broker reachability and the non-default configuration; where those hold, this is a real priority, not a high-CVSS-but-low-real-risk finding. |
| Exploit ScenarioDerived | An attacker with network access to the Arrowhead MQTT broker reads the target cloud's public name from its TLS certificate, then generates a self-signed X.509 certificate with CN=Sysop.<cloud>.<org>.arrowhead.eu and dnQualifier=op. They embed this certificate in the authentication field of an MqttRequestTemplate and publish a management request; CertificateMqttFilter accepts the unverified certificate, sets isSysOp==true, and the downstream ManagementServiceMqttFilter grants full management control over the local cloud. No proof-of-concept is publicly identified, but the advisory describes each step precisely. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 03, 2026
Authentication bypass in Eclipse Arrowhead 5.0.0 through 5.2.1 lets an unauthenticated attacker who can publish to the MQTT broker impersonate the cloud's system operator. When the MQTT API runs with the certificate authentication policy, CertificateMqttFilter reads an X.509 certificate straight from the MQTT message payload and trusts its Subject DN without ever verifying the signature or issuer chain, reducing authorization to two string comparisons on public, attacker-controlled values. By minting a self-signed certificate with CN=Sysop.<cloud>.<org>.arrowhead.eu and dnQualifier=op, the attacker gains isSysOp==true and full management access. No public exploit is identified at time of analysis, but the technique is described in full detail in the advisory.
RemediationAI
Upgrade to a fixed Arrowhead release above 5.2.1 once published; the referenced Eclipse advisory (https://gitlab.eclipse.org/security/vulnerability-reports/-/work_items/812) is the authoritative source for the patched version, which is not independently confirmed in the input data, so treat this as 'Patch available per vendor advisory' and verify the exact tag with Eclipse before deploying. Until patched, the most effective compensating control is to disable the MQTT certificate authentication policy (or the MQTT API entirely) and rely on the unaffected HTTP mTLS interface, accepting the trade-off of losing MQTT-based system/operator access. If MQTT must remain enabled, restrict broker access at the network layer so only trusted, authenticated systems can publish to the Arrowhead topics (e.g. firewall/ACL the broker port and require broker-level authentication), understanding this does not fix the underlying certificate-validation flaw and only reduces who can reach the vulnerable filter. Do not rely on obscuring the cloud name - it is exposed in the server's TLS certificate and cannot serve as a secret.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Eclipse Arrowhead is an open-source service-oriented framework for industrial IoT / Industry 4.0 local automation clouds, governed by the Eclipse Foundation (CPE: cpe:2.3:a:eclipse_foundation:eclipse_arrowhead). The flaw is a textbook CWE-295 (Improper Certificate Validation): the MQTT authentication path decodes the client certificate with CertificateFactory.generateCertificate(), which only parses DER/PEM structure and performs no cryptographic trust checks. Because the certificate arrives inside the MqttRequestTemplate authentication field rather than through a TLS handshake, there is no trust-store validation. Identity is derived purely from the certificate's Subject DN, and privilege is granted when the DN-qualifier equals 'sy' or 'op' and the CN's cloud-name segment matches the server - both values are publicly discoverable (the cloud name appears in the server's own TLS certificate). Notably, the parallel HTTP CertificateFilter is NOT vulnerable because it reads jakarta.servlet.request.X509Certificate, which Tomcat only populates after a successful mTLS handshake against the configured trust store.
Know when Eclipse Arrowhead gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
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
Network-reachable, low-complexity, unauthenticated certificate forgery (PR:N) yields sysop management (C:H/I:H) over managed systems (S:C); no availability impact (A:N); config-dependent condition captured as AT:P in 4.0 rather than AC:H.
Primary rating from Vendor (eclipse).
CVSS VectorVendor: eclipse
DescriptionCVE.org
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.
Articles & Coverage 1
Executive ViewAI
Eclipse Arrowhead versions 5.0.0 through 5.2.1 contain a critical certificate validation bypass in the MQTT API that allows attackers with access to the message broker to impersonate the system operator and gain complete cloud management access. This immediately threatens organizations using Arrowhead for infrastructure orchestration and IoT management by enabling attackers to compromise operational systems and sensitive data.
No vendor-released patch identified at time of analysis. Interim mitigations include: restricting MQTT broker network access to only authorized internal systems using firewall rules; implementing network segmentation to isolate Arrowhead infrastructure from untrusted networks; disabling the MQTT API if not operationally required; and deploying network-level monitoring with alerting for MQTT messages containing certificate Subject DNs that do not match expected patterns for legitimate system operators.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
EUVD-2026-70467
GHSA-268c-4cfr-fmcj
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB