Severity:
CVSS 4.0: 8.7 (high)
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
Affected versions:
- Apache Pulsar 3.0.0 before 4.0.14
- Apache Pulsar 4.1.0 before 4.2.5
Description:
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.
Credit:
Elias Hasas (finder)
Mike Read (finder)
Omar Mousa (finder)
References:
https://pulsar.apache.org/security/CVE-2026-105937/
https://pulsar.apache.org/
https://www.cve.org/CVERecord?id=CVE-2026-105937
