CVE-2022-33683 in Pulsar
Summary
by MITRE • 09/23/2022
Apache Pulsar Brokers and Proxies create an internal Pulsar Admin Client that does not verify peer TLS certificates, even when tlsAllowInsecureConnection is disabled via configuration. The Pulsar Admin Client's intra-cluster and geo-replication HTTPS connections are vulnerable to man in the middle attacks, which could leak authentication data, configuration data, and any other data sent by these clients. An attacker can only take advantage of this vulnerability by taking control of a machine 'between' the client and the server. The attacker must then actively manipulate traffic to perform the attack. This issue affects Apache Pulsar Broker and Proxy versions 2.7.0 to 2.7.4; 2.8.0 to 2.8.3; 2.9.0 to 2.9.2; 2.10.0; 2.6.4 and earlier.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 05/23/2025
The vulnerability described in CVE-2022-33683 represents a critical security flaw in Apache Pulsar broker and proxy implementations that undermines the integrity of internal communications. This issue manifests when Pulsar brokers and proxies establish internal Pulsar Admin Client connections for intra-cluster operations and geo-replication activities. The flaw occurs because these internal clients fail to properly validate TLS peer certificates even when the system is explicitly configured to disable insecure connections through the tlsAllowInsecureConnection parameter. This misconfiguration creates a dangerous gap in the security posture where the system appears to enforce secure communication protocols while simultaneously allowing for man-in-the-middle attacks to occur.
The technical implementation of this vulnerability stems from the improper handling of TLS certificate validation within the internal Pulsar Admin Client component. When the system is configured with tlsAllowInsecureConnection disabled, the expectation is that all HTTPS connections will undergo proper peer certificate verification to ensure authenticity and prevent unauthorized interception. However, the internal Pulsar Admin Client bypasses this validation process, creating an attack surface where malicious actors can intercept and manipulate traffic between cluster components. This flaw operates under the principle that the system's security configuration should be consistently applied across all communication channels, including internal ones that are often considered trusted but remain vulnerable due to this implementation oversight.
The operational impact of this vulnerability extends beyond simple data interception, encompassing serious risks to system integrity and confidentiality. Attackers who gain control of network infrastructure between communicating Pulsar components can exploit this weakness to capture authentication credentials, sensitive configuration data, and any other information transmitted through these internal HTTPS connections. The vulnerability affects multiple versions of Apache Pulsar across several release lines including 2.7.0 through 2.7.4, 2.8.0 through 2.8.3, 2.9.0 through 2.9.2, 2.10.0, and 2.6.4 and earlier versions. This widespread impact means that organizations running any of these vulnerable versions face potential exposure to credential theft and data leakage that could compromise entire distributed messaging systems. The attack requires an active network position rather than passive monitoring, making it more difficult to detect but no less dangerous in its potential consequences.
From a cybersecurity perspective, this vulnerability aligns with CWE-295, which addresses improper certificate validation, and maps to ATT&CK technique T1566 for credential harvesting through man-in-the-middle attacks. The issue represents a classic case of insufficient validation in security-critical components where the system's defense-in-depth approach fails due to a single point of weakness in the certificate verification process. Organizations should immediately upgrade to patched versions of Apache Pulsar to address this vulnerability, as the risk of exploitation increases with the complexity and scale of distributed systems. Network segmentation and monitoring should be implemented to detect unusual traffic patterns that might indicate active exploitation attempts, while also ensuring that all internal communications maintain consistent security policies regardless of their perceived trust level within the system architecture.