CVE-2023-51437: High Timing Flaw in Apache Pulsar SASL Auth

CVE-2023-51437 is a timing side channel in the SASL Authentication Provider of Apache Pulsar, rated High (7.4). An attacker may be able to forge a SASL role token that passes signature verification. Upgrade to 2.11.3, 3.0.2 or 3.1.1, and consider replacing the signing secret.

What's affected

The Apache announcement on oss-security lists these affected versions:

• Apache Pulsar through 2.10.5
• Apache Pulsar 2.11.0 through 2.11.2
• Apache Pulsar 3.0.0 through 3.0.1
• Apache Pulsar 3.1.0

Any component running the SASL Authentication Provider is affected. That includes the Pulsar Broker, Proxy, Websocket Proxy and Function Worker. If you do not enable SASL authentication, the vulnerable code path is not in use, although you should still plan the upgrade.

Fixed versions are 2.11.3, 3.0.2 and 3.1.1. The announcement also says users of Pulsar 2.8, 2.9, 2.10 and earlier should move to one of those patched releases.

The record gives a CVSS score of 7.4 (High), vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N. The record's CISA KEV flag is false. The announcement credits the finders by name and does not claim exploitation.

How to check if you're exposed

Start by finding out whether SASL is on. Look in the broker, proxy, websocket proxy and function worker configuration for the SASL authentication provider and for the saslJaasServerRoleTokenSignerSecretPath setting named in the announcement.

grep -rn "saslJaasServerRoleTokenSignerSecretPath\|SaslAuthenticationProvider" conf/

Then check the running version of each component:

bin/pulsar version

Compare the result with the affected list. Remember that brokers, proxies and function workers can run different versions, so check each one. If you deploy with Helm or an operator, check the image tags in your manifests as well. You can also scan a dependency manifest at gold.safeguard.sh/scan to see whether Pulsar client or server artifacts appear in your builds.

What to do now

1. Identify every Pulsar component that uses the SASL Authentication Provider.
2. Upgrade each one to 2.11.3, 3.0.2 or 3.1.1, whichever matches your release line. Older lines should move to one of those releases.
3. Replace the secret stored in the file referenced by saslJaasServerRoleTokenSignerSecretPath, as the announcement suggests you consider. Tokens signed with the old secret stop working after the change, so plan a rollout window.
4. Restrict network access to broker and proxy ports to the clients that need them.
5. Review authentication logs for unusual role tokens or unexpected roles during the period before you upgraded.

Why it matters

The weakness is CWE-203 (Observable Discrepancy). When code compares a supplied signature with the expected one using a method whose running time depends on how many leading bytes match, a patient attacker who can send many requests and measure response time can learn the correct signature piece by piece. The announcement points to a well known write up on timing attacks for background.

The result is a forged role token that the server accepts as genuine. That undermines authorization for whatever role the attacker chooses to claim, which is why confidentiality and integrity are both rated high. Attack complexity is rated high because timing measurements over a network are noisy, but noise is a hurdle and not a barrier. The remedy for this class is a constant time comparison, which is what upgrading provides, and rotating the secret limits the value of anything learned earlier.

Quick check

Sources

• Apache Pulsar announcement on oss-security (fetched)
• Apache mailing list thread (listed in the NVD record, page did not render)
• Gold page for CVE-2023-51437

Last reviewed: 19 October 2026.