CVE-2026-82180 in Arrowhead
요약
\~에 의해 VulDB • 2026. 09. 03.
Eclipse Arrowhead의 5.0.0부터 5.2.1 버전까지에서 MQTT API가 인증서 기반 인증 정책으로 활성화된 경우, CertificateMqttFilter는 클라이언트가 MQTT 메시지 페이로드(MqttRequestTemplate의 인증 필드)에 포함하여 전송하는 X.509 인증서를 파싱하고 해당 Subject DN을 인증된 ID로 처리합니다. 이 인증서는 CertificateFactory.generateCertificate()를 사용하여 디코딩되지만 서명은 검증되지 않으며, 발급자 체인은 신뢰 저장소(trust store)와 비교되어 유효성이 확인되지 않습니다. 권한 부여(attorisation)는 공격자가 제공한 데이터에 대한 두 개의 문자열 비교로 축소됩니다: DN-qualifier가 "sy" 또는 "op"과 일치해야 하며, CN의 cloud-name 부분은 서버의 것과 일치해야 합니다. 이 두 값은 모두 공개되어 있습니다(클라우드 이름은 서버 자체의 TLS 인증서에 포함됨). 따라서 MQTT 브로커에 게시할 수 있는 공격자는 CN=Sysop.<cloud>.<org>.arrowhead.eu 및 dnQualifier=op인 자기 서명(self-signed) 인증서를 생성하여 이를 인증 필드로 전송함으로써 클라우드의 시스템 운영자(isSysOp == true)로서 인증될 수 있습니다. 이는 하류 ManagementServiceMqttFilter를 통과(request.isSysOp() → 허용됨)하고 MQTT에 대한 전체 관리 접근 권한을 제공합니다. HTTP CertificateFilter는 영향을 받지 않습니다—이 필터는 jakarta.servlet.request.X509Certificate에서 인증서를 읽으며, Tomcat은 구성된 신뢰 저장소(trust store)와의 성공적인 mTLS 핸드셰이크 후에만 이를 채웁니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.