EUVD-2026-107475
GHSA-376p-82ph-3q76
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as tenant admin in own tenant
-
DeliveryCreate/update topic with PULSAR.SHADOW_SOURCE to foreign tenant
-
ExploitBroker skips source-topic authorization check
-
ExecutionConsume shadow topic for retained messages
-
ImpactTrigger retention/deletion destroying source ledgers
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires an authenticated principal holding the tenant admin role (under the default authorization provider) with rights to create topics or update topic properties in any single tenant; no permission on the source topic, its namespace, or its tenant is needed. The attacker sets the reserved topic property PULSAR.SHADOW_SOURCE to a persistent topic in another tenant via the admin REST API on topic-create or property-update paths. Preconditions: the shadow topic (PIP-180) feature must be present and usable - it exists and cannot be disabled in affected versions 3.0.0-4.0.13 and 4.1.0-4.2.4 (2.x has no shadow topic implementation). Limiting factors: cross-tenant confidentiality exposure is restricted to messages still retained and readable in the source topic's ledgers, and client-side end-to-end encrypted messages cannot be decrypted without the keys; the impact assessment holds only for the default authorization provider. |
| Impact | This is a genuine priority for any organization running multi-tenant Apache Pulsar, though its severity is bounded by a real privilege prerequisite. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, score 8.7) indicates a low-complexity, network-reachable attack over the admin REST API that requires some authentication (PR:L) and no user interaction, with high confidentiality, integrity and availability impact to the targeted (cross-tenant) data. The CWE-862 (Missing Authorization) classification is consistent with the description: the broker authorizes the caller only against the topic being created/updated, never against the cross-tenant source topic. No EPSS score, CISA KEV listing, or public POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation - the 8.7 rating is driven by impact, not by observed exploitation. The key limiting factor is that, under the default authorization provider, the attacker must already hold the tenant admin role in some tenant; this is a meaningful barrier in well-segmented deployments but trivial in environments where tenant admin is handed out broadly. Note that the vendor explicitly scopes the impact analysis to the default authorization provider - custom providers may behave differently, and this caveat should be verified against local configuration. On balance: a real, high-impact cross-tenant data disclosure and destruction flaw that matters most to shared/multi-tenant Pulsar clusters, but not a mass-exploitable unauthenticated bug. |
| Exploit ScenarioDerived | An authenticated user holding the tenant admin role in Tenant A uses the admin REST API to create a topic (or update its properties) with the reserved property PULSAR.SHADOW_SOURCE pointing at a persistent topic in Tenant B, which the broker accepts without checking any permission on the Tenant B source. The attacker then consumes from the shadow topic to read Tenant B's still-retained messages using only Tenant A permissions, or lets the shadow topic's retention/deletion logic permanently trim or delete Tenant B's BookKeeper and tiered-storage ledgers. No public exploit code is identified, but the attack is low-complexity (AV:N/AC:L) once tenant admin access is obtained. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Missing authorization in Apache Pulsar's shadow topic feature allows an authenticated tenant administrator to bind a topic in their own tenant to a persistent topic in another tenant through the PULSAR.SHADOW_SOURCE property, exposing retained messages and enabling destructive retention or deletion of the source topic's ledgers. This affects shadow-topic-capable releases before the fixed 4.0.14 and 4.2.5 versions under the default authorization provider, and no public exploit was identified at time of analysis.
RemediationAI
Vendor-released patch: upgrade 4.0.x to at least 4.0.14 and 4.1.x/4.2.x to at least 4.2.5 (newer supported releases are also acceptable). Fixed brokers disable shadow topics by default via enableShadowTopics=false; after upgrading, set enableShadowTopics=true on all brokers only if shadow topics are required, otherwise existing shadow topics will not load, and cross-tenant binding will require the superuser role. If immediate upgrade is impossible, reduce exposure by granting the tenant admin role only to trusted principals, since affected versions provide no setting to disable shadow topics; this restricts legitimate topic administration and does not remove the underlying flaw. Advisory: https://pulsar.apache.org/security/CVE-2026-105937/.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Shadow topics (PIP-180) are backed by the source topic's managed ledger, and the reserved PULSAR.SHADOW_SOURCE property selects that source. CWE-862 (Missing Authorization) manifests because the admin REST API's topic-create and property-update paths authorize only the topic being created or updated, not the source topic named in the property; the SHADOW_TOPIC policy on the source topic is enforced only by the source-side admin API. Because the shadow topic's managed ledger applies its own retention, trimming, offloading and deletion to the source ledgers, a cross-tenant binding can both read retained data and destroy unacknowledged or retained messages, bypassing source-side subscriptions and retention policy. The CPE cpe:2.3:a:apache_software_foundation:apache_pulsar:*:*:*:*:*:*:*:* covers affected 3.0.0-4.0.13 and 4.1.0-4.2.4; 2.x lacks shadow topics, and fixed releases disable the feature by default (enableShadowTopics=false) and require the superuser role for cross-tenant binding.
Know when Apache Pulsar gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Network REST API with low complexity (AV:N/AC:L), no UI, but a required tenant-admin role under the default provider makes it PR:L; cross-tenant read, schema tampering, and permanent ledger deletion give C/I/A:H.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
2DescriptionCVE.org
Apache Pulsar shadow topics (PIP-180) are topics that read the stored messages of a source topic from that topic's managed ledger. The source topic is selected by setting the reserved topic property PULSAR.SHADOW_SOURCE. The admin REST API accepts this property when creating a non-partitioned or partitioned topic and when updating the properties of an existing topic. On these paths the broker authorizes the caller only against the topic being created or updated. It does not authorize the caller against the source topic named in the property. The existing authorization for shadow topic configuration (the SHADOW_TOPIC topic policy on the source topic) is applied only to the source-side shadow topics admin API, not to these paths.
As a result, an authenticated user who is allowed to create topics or update topic properties in one tenant can bind a topic in that tenant to a persistent topic in any other tenant. With the default authorization provider, these operations require the tenant admin role for the user's own tenant. The user does not need any permission on the source topic, its namespace or its tenant. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different.
The user can then consume from the shadow topic, using only permissions on their own topic, and receive retained messages that were published to the source topic in the other tenant. Exposure is limited to messages that are still retained and readable in the source topic's ledgers; messages protected with client-side end-to-end encryption cannot be decrypted without the encryption keys. A producer on the shadow topic can also register a new schema version under the source topic's schema, subject to the schema compatibility settings; existing schema versions are not replaced.
In addition, the shadow topic's managed ledger applies its own retention, trimming, offloading and deletion to the source topic's ledgers. This can permanently delete the source topic's ledger data from BookKeeper and from tiered storage, regardless of the source topic's own subscriptions and retention policy, including messages that have not yet been acknowledged. Deleting the shadow topic can also delete the source topic's ledgers. This data loss can also affect shadow topics that were configured intentionally by administrators.
This issue affects Apache Pulsar versions from 3.0.0 before 4.0.14 and from 4.1.0 before 4.2.5. Apache Pulsar 2.x releases do not contain the shadow topic implementation.
- 4.0.x version users should upgrade to at least 4.0.14.
- 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.
Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.
The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/.
In the fixed versions, shadow topics are disabled by default and are controlled by the new broker configuration setting enableShadowTopics (default false). While it is disabled, the broker rejects creating shadow topics, setting the PULSAR.SHADOW_SOURCE property, and loading or replicating to existing shadow topics. Deployments that use shadow topics must set enableShadowTopics=true in the broker configuration of all brokers after upgrading; otherwise existing shadow topics will not be loaded. When shadow topics are enabled, binding a shadow topic to a source topic in a different tenant requires the superuser role. The fixed versions also prevent a shadow topic from deleting or trimming the ledgers and offloaded data of its source topic.
Affected versions provide no configuration option to disable shadow topics. Users who cannot upgrade immediately can reduce exposure by granting the tenant admin role only to trusted principals.
Executive ViewAI
Apache Pulsar's shadow topic feature contains an authorization gap that allows a user holding tenant administrator rights to bind a topic in their own tenant to a persistent topic belonging to a different tenant, exposing retained message data and permitting destructive retention or deletion of the source topic's ledgers. For any organization running multi-tenant Pulsar messaging, this directly undermines the tenant isolation boundary that data segregation and compliance obligations depend on, meaning one over-privileged operator could read or destroy another business unit's or customer's message data. No public exploit has been identified, but the flaw affects shadow-topic-capable releases before 4.0.14 and 4.2.5 under the default authorization provider, so exposure is broad wherever tenant administration is loosely delegated.
No vendor-released patch is confirmed in the provided data, so interim mitigations are required: restrict tenant administrator role assignments to the minimum set of trusted operators, audit and remove any PULSAR.SHADOW_SOURCE bindings that reference topics outside the binding tenant's namespace, disable or block shadow topic creation for tenants that do not require the feature, and segment high-value or regulated tenants onto separate Pulsar clusters until the 4.0.14 or 4.2.5 releases cited in the advisory can be deployed.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
More in Apache Pulsar
View allUnauthenticated role forgery in Apache Pulsar lets a client present a forged or unsigned JSON Web Token listing arbitrar
Apache Pulsar deployments using the filesystem packages storage provider allow an authenticated user holding packages pe
Apache Pulsar 2.8.1 through 4.0.13 and 4.1.0 through 4.2.4 can grant an authenticated low-privileged user the proxy's fu
Truncating a partitioned topic through the Apache Pulsar broker admin REST API succeeds without the caller holding tenan
Apache Pulsar 2.8.0 through 4.2.x deployments that enable package management allow an authenticated user to read package
The deprecated functions connectors endpoints (/admin/v2/functions/connectors and /admin/v3/functions/connectors) in Apa
An authenticated Apache Pulsar client that holds no permission whatsoever on a target topic can read that topic's regist
Authorization flaw in Apache Pulsar's Functions Worker trigger REST endpoint allows an authenticated user who holds func
Authorization bypass in Apache Pulsar (2.8.0 through 4.0.13 and 4.1.0 through 4.2.4) allows an authenticated user holdin
Missing authorization checks in the Apache Pulsar broker admin REST endpoints for non-persistent topics allow an authent
Cross-tenant information disclosure in Apache Pulsar's transaction administration REST API allows any authenticated user
Apache Pulsar's WebSocket service performs an incomplete authorization check when a WebSocket consumer supplies a dead l
Exploit-DB