CVE-2026-82180

KrytyczneCVSS 9.5

Opublikowano: 03/09/2026(UTC)Zaktualizowano: 03/09/2026(UTC)Przetłumaczono: 03/09/2026(UTC)NVD NIST

Streszczenie

W Eclipse Arrowhead w wersjach od 5.0.0 do 5.2.1, gdy API MQTT jest włączone z polityką uwierzytelniania certyfikatów, CertificateMqttFilter parsuje certyfikat X.509 wysyłany przez klienta w ładunku wiadomości MQTT i traktuje jego Subject DN jako uwierzytelnioną tożsamość. Podpis certyfikatu nie jest weryfikowany, a łańcuch wystawcy nie jest sprawdzany względem żadnego magazynu zaufania. Atakujący, który może publikować do brokera MQTT, może wygenerować samopodpisany certyfikat z CN=Sysop.<cloud>.<org>.arrowhead.eu i dnQualifier=op, aby uzyskać pełny dostęp zarządczy przez MQTT.

Ocena ryzyka

Ryzyko obejmuje nieautoryzowany dostęp do funkcji zarządzania systemem przez MQTT, co może prowadzić do pełnej kompromitacji chmury Arrowhead.

Rekomendacja

Zaleca się wyłączenie API MQTT z polityką certyfikatów lub wdrożenie weryfikacji podpisu i łańcucha certyfikatów względem zaufanego magazynu.

Inne podatności w Eclipse Arrowhead

CVE-2026-80515Wysokie
W Eclipse Arrowhead w wersjach od 5.0.0 do 5.2.1 brama zarządzania chroniąca punkty końcowe /…/mgmt/… sprawdza, czy ścieżka zawiera "/mgmt/" za pomocą request.getRequestURL().toString().contains("/mgmt/"). Tomcat zwraca getRequestURL() bez dekodowania, a Spring MVC routuje na ścieżce zdekodowanej. Żądanie /serviceregistry/%6Dgmt/systems (%6D == m) omija sprawdzenie, ale jest dekodowane do /serviceregistry/mgmt/systems i przekazywane do kontrolera zarządzania. Każdy uwierzytelniony system może wykonywać operacje zarządzania, w tym tworzyć konta sysop, co prowadzi do pełnego przejęcia chmury.

Oryginalny opis (angielski, źródło NVD)

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.