---

If you use Apache Pulsar with OAuth2. authentication—especially with the C++ or Python client—this long read is for you. In 2022, a major security flaw (CVE-2022-33684) was discovered, which could let attackers intercept or change sensitive authentication data sent between your clients and authentication servers. In this post, we’ll break down what happened, why it’s dangerous, show code illustrating the issue, and tell you exactly what you need to do to stay safe.

What is CVE-2022-33684?

This vulnerability affects how Apache Pulsar’s C++ client library, and the Python client that wraps it, handle TLS (Transport Layer Security) verification when authenticating using OAuth2.’s Client Credentials Flow. Basically, even if you config the client to require secure TLS connections, the library doesn't actually check the server’s TLS certificates when requesting tokens. That’s a big deal.

2.6.4 and earlier

*Versions 2.7.5, 2.8.4, 2.9.3, and 2.10.2 are patched. Python Client 3. will be patched upon release. C++ 3. is safe.*

Why Does This Matter?

When you connect to a Pulsar cluster with OAuth2, your client library needs to fetch a token from an OAuth2 server. This is done using HTTPS, and you expect that the library is actually verifying the server it’s talking to.

But with CVE-2022-33684, it wasn’t. This means that if an attacker can control the network between you and the OAuth2 server (like via public WiFi or compromised local networks), they can perform a classic man-in-the-middle (MITM) attack and:

Use those tokens or secrets to impersonate you and access protected Pulsar clusters

This is not a theoretical attack—it’s a seriously exploitable configuration slip.

Let’s imagine you have a C++ client connecting like this

pulsar::ClientConfiguration conf;

// Supposedly disable insecure connections
conf.setTlsAllowInsecureConnection(false);
conf.setAuth(pulsar::AuthOAuth2::create(
    "{"
    "  \"type\": \"client_credentials\","
    "  \"issuerUrl\": \"https://auth-server.example.com\",";
    "  \"clientId\": \"my_id\","
    "  \"clientSecret\": \"super_secret\""
    "}"
));

// ...set up the client and connect
pulsar::Client client("pulsar+ssl://cluster-broker.example.com:6651", conf);
// ...

With vulnerable versions, even though you’ve set setTlsAllowInsecureConnection(false), the Pulsar client doesn’t actually check the TLS certificate of auth-server.example.com when making that HTTPS token request. An attacker on your network could use a tool like mitmproxy or Bettercap to hijack the connection and serve you a fake OAuth2 token endpoint that snoops your credentials:

Example of an attacker using mitmproxy

# The attacker runs mitmproxy to capture outbound OAuth2 requests:
mitmproxy -p 808 --mode transparent

# The client (your Pulsar code) thinks it's talking to auth-server.example.com, but it's not.

If you check the vulnerable lines in the Pulsar C++ client code, you’ll see that certificate validation was simply missing in their requests reference.

Victim connects to hotel or airport WiFi, tries to use their Pulsar client (C++ or Python).

2. Attacker runs MITM proxy, reroutes all HTTPS connections meant for the real OAuth2 server to their own fake server.
3. Victim's Pulsar client sends a GET or POST (depending on config) to the attacker's server, revealing both client_id and client_secret.
4. Attacker uses harvested secrets with the real OAuth2 server to mint their own valid Pulsar tokens.

Attacker now has access to whatever Pulsar resources the client did.

It’s stealthy. Victims often won’t notice. By the time you realize, your Pulsar cluster could have been compromised.

2. Rotate Credentials

Immediately rotate any OAuth2. credentials (client_id, client_secret) used with affected clients. You must assume they *could* have been compromised if they were ever sent over a vulnerable network.

3. Check Server Logs

Look for suspicious OAuth2 token requests in your providers' logs—especially spikes in authentication from unexpected IPs.

4. Be Wary of Rolling Your Own

If your code wraps, forks, or modifies the original Pulsar Python/C++ client, you may have inherited the vulnerability.

- Apache Pulsar Security Advisory: CVE-2022-33684
- GitHub Pulsar Pull Request for the Fix
- NVD CVE Record: CVE-2022-33684
- OAuth2. Client Credentials Flow Documentation

Final Thoughts

CVE-2022-33684 is a classic example of why “secure by default” should be taken seriously, especially in libraries used for authentication. Even if your config files say “be secure,” always double check client library changelogs and advisories. If you use C++ or Python with Apache Pulsar and OAuth2., upgrade your clients and rotate your secrets now.

Stay safe on the wire!

*If you found this post useful, please share it with other Pulsar users or developers. Security only works when everyone updates.*

Timeline

Published on: 11/04/2022 12:15:00 UTC
Last modified on: 01/26/2023 20:07:00 UTC