PulsarApplication · Apache
CVE-2023-30428
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedIncorrect Authorization vulnerability in Apache Software Foundation Apache Pulsar Broker's Rest Producer allows authenticated user with a custom HTTP header to produce a message to any topic using the broker's admin role. This issue affects Apache Pulsar Brokers: from 2.9.0 through 2.9.5, from 2.10.0 before 2.10.4, 2.11.0. The vulnerability is exploitable when an attacker can connect directly to the Pulsar Broker. If an attacker is connecting through the Pulsar Proxy, there is no known way to exploit this authorization vulnerability. There are two known risks for affected users. First, an attacker could produce garbage messages to any topic in the cluster. Second, an attacker could produce messages to the topic level policies topic for other tenants and influence topic settings that could lead to exfiltration and/or deletion of messages for other tenants. 2.8 Pulsar Broker users and earlier are unaffected. 2.9 Pulsar Broker users should upgrade to one of the patched versions. 2.10 Pulsar Broker users should upgrade to at least 2.10.4. 2.11 Pulsar Broker users should upgrade to at least 2.11.1. 3.0 Pulsar Broker users are unaffected.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceApache Pulsar Broker contains an incorrect authorization flaw in its REST producer API where an authenticated user can send a custom HTTP header to bypass authorization checks and produce messages to any topic using the broker's admin role. This allows authenticated attackers connected directly to the broker to inject garbage messages into any topic or manipulate topic-level policies for other tenants.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data
PulsarApplication
>= 2.9.0, <= 2.9.5>= 2.10.0, < 2.10.4= 2.11.0CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- None
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify Pulsar Broker versionRun 'pulsar version' or check the Pulsar distribution in use. Alternatively, check the broker's HTTP endpoint at /admin/v2/namespaces for version information in response headers, or inspect the pulsar-common jar file metadata.Affected if The installed version falls within 2.9.0-2.9.5, 2.10.0-2.10.3, or 2.11.0.
-
Determine if clients connect directly to brokerReview your deployment architecture. Check pulsar.conf for 'brokerServicePort' and 'webServicePort' being exposed directly to clients, versus being accessible only through Pulsar Proxy. Inspect load balancer or firewall rules to confirm broker ports are accessible to authenticated users.Affected if Authenticated users can connect directly to broker ports (8080/8443 or 6650/6651) rather than being forced through Pulsar Proxy.
-
Check REST producer API authorizationSend a test authenticated request to the producer REST API (POST /admin/v2/tenants) with a custom HTTP header (e.g., X-Principal-Override or similar role-impersonation header) to see if it bypasses authorization. Compare behavior against documented expected headers.Affected if The broker accepts and honors custom HTTP headers that override or bypass the authenticated user's assigned role during REST API producer operations.
-
Review broker authorization settingsExamine pulsar.conf for authorization settings: 'authorization.enabled', 'authorization.allowMultipleMatches', and any custom authorization provider class. Check if topic-level or tenant-level authorization policies are properly enforced.Affected if Authorization is enabled but permits role bypass via custom headers, or the broker uses a default authorization provider that does not block header-based role override.
You are affected if running a vulnerable Pulsar version AND authenticated users can connect directly to the broker (not forced through proxy), allowing them to inject arbitrary messages into topics by exploiting the REST producer API authorization bypass.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped2.10.4
Upgrade Apache Pulsar Broker to patched versions (2.9.6+, 2.10.4+, 2.11.1+) or enforce client connections through Pulsar Proxy as a workaround.
2.9.x -> 2.9.6+, 2.10.x -> 2.10.4+, 2.11.0 -> 2.11.1
- Upgrade Apache Pulsar Broker to version 2.9.6 or later for the 2.9.x branch
- Upgrade Apache Pulsar Broker to version 2.10.4 or later for the 2.10.x branch
- Upgrade Apache Pulsar Broker to version 2.11.1 or later for the 2.11.0 version
- Ensure that users can only connect to Pulsar through the Pulsar Proxy rather than directly to the Broker, as the vulnerability cannot be exploited through the Proxy
- After upgrading, verify that the authorization controls properly restrict users to their designated topics
Generated from the published advisory — verify against the referenced sources before acting.
Fix this in Pulsar
Scoped from the published advisory
- Consultation3.0 h
- Implementation6.0 h
- Testing3.0 h
- Review / QA2.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $3,984.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2023-30428 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2023-30428 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data