Skip to main content
VulnerabilityPublished Updated

CVE-2022-33682: Apache Pulsar · Improper Certificate Validation

Affects Apache PulsarSource CVE Database V5

0

Not known to be exploited · CVSS 5.9 Medium · fixed in 2.9.3 : update Apache Pulsar when convenient.

Data as of 26 Oct 2026, 17:16 UTC

CVSS 3.1 base score
5.9Medium
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.7% chance of exploitation in 30 days – higher than 53% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 2.9.3, 2.8.4, 2.7.5
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 23 Sep 2022

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade org.apache.pulsar/pulsar to 2.9.3, 2.8.4 or 2.7.5.

Affected software

ProductAffectedFixed in
Mavenorg.apache.pulsar/pulsarpkg:maven/org.apache.pulsar/pulsarOther threatsAffected
  • 2.7.0 <2.7.5 – 2.10.0
  • <=2.6
4 affected builds
Fixed in
  • 2.7.5
  • 2.8.4
  • 2.9.3

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

European organizations should immediately assess their Apache Pulsar deployments to identify affected versions (2.6 and earlier, 2.7.0-2.7.4, 2.8.0-2.8.3, 2.9.0-2.9.2, and 2.10.0). They should upgrade to the latest patched versions where TLS hostname verification is properly enforced. If immediate upgrading is not feasible, organizations should implement network-level mitigations such as strict network segmentation to limit the possibility of MITM attacks within intra-cluster and geo-replication communication paths. Deploying mutual TLS authentication with strict hostname verification policies at the network or application layer can help mitigate risks. Additionally, organizations should monitor network traffic for anomalies indicative of MITM activity and audit logs for suspicious access patterns. Employing network encryption monitoring tools and intrusion detection systems that can detect certificate anomalies or unexpected TLS handshakes is recommended. Finally, organizations should review and update their incident response plans to include scenarios involving intra-cluster communication interception.

Description

TLS hostname verification cannot be enabled in the Pulsar Broker's Java Client, the Pulsar Broker's Java Admin Client, the Pulsar WebSocket Proxy's Java Client, and the Pulsar Proxy's Admin Client leaving intra-cluster connections and geo-replication connections vulnerable to man in the middle attacks, which could leak credentials, configuration data, message data, and any other data sent by these clients. The vulnerability is for both the pulsar+ssl protocol and HTTPS. 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 by providing the client with a cryptographically valid certificate for an unrelated host. This issue affects Apache Pulsar Broker, Proxy, and WebSocket 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.

References

Community reviews

Loading reviews…