Apache Pulsar Shadow Topic Auth Flaw CVE-2026-105937 Allows Cross-Tenant Data Access

Apache Pulsar shadow topics feature contains an authorization bypass that allows authenticated users to access data across tenant boundaries. According to the National Vulnerability Database record for CVE-2026-105937, the broker fails to verify permissions on the source topic when users configure shadow properties. This gap exists in versions 3.0.0 before 4.0.14 and 4.1.0 before 4.2.5.

The risk

The vulnerability stems from how the admin REST API handles the PULSAR.SHADOW_SOURCE property. When creating or updating topics, the broker only checks if the caller has permission for the target topic. It ignores the permissions required for the source topic identified in the property. This allows a user with tenant admin rights in one tenant to bind a new topic to a persistent topic in any other tenant. The user does not need any specific permission on the source topic, its namespace, or its tenant.

Who is exposed

Organizations running Apache Pulsar versions 3.0.0 through 4.0.13 and 4.1.0 through 4.2.4 are exposed. Users operating these versions can exploit the flaw if they hold the tenant admin role for their own tenant. The impact includes reading retained messages from other tenants and potentially deleting ledger data. Messages protected by client-side end-to-end encryption remain secure, as the attacker lacks the decryption keys.

Cost and compliance

The National Vulnerability Database rates CVE-2026-105937 as high severity with a CVSS score of 8.7. The flaw is classified under CWE-862, which covers incorrect permission assignment. While the source material does not cite specific compliance frameworks, the ability to access cross-tenant data and trigger unauthorized deletions poses significant risks to data integrity and confidentiality requirements.

What to watch

Security teams should monitor for unusual shadow topic creation events across tenants. Administrators should verify that no unauthorized bindings exist between topics in different namespaces. Check for unexpected data retention changes or ledger deletions in source topics that were not initiated by administrators.

Signals worth monitoring

Teams usually detect this activity by reviewing admin API logs for PULSAR.SHADOW_SOURCE property assignments. Look for topic creation events where the source tenant differs from the requester's tenant. Monitor for sudden data loss or retention policy changes on source topics. Check access logs for consumers reading from shadow topics that they did not explicitly create. Verify that no unauthorized schema versions were registered on source topics.

What to do and how to stay safe: Apache Pulsar

• Upgrade Apache Pulsar to version 4.0.14 or 4.2.5 to apply the vendor-provided fix.
• Restrict the tenant admin role to trusted principals only if immediate upgrading is not possible.
• Audit existing shadow topic configurations to identify any unauthorized cross-tenant bindings.
• Review broker logs for unusual topic property updates or ledger deletion events.

Step-by-step guide: Vulnerability Prioritization: Fix What Actually Matters First

General security guidance from the SecOps Signal newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Does this vulnerability affect Apache Pulsar 2.x releases?

No, Apache Pulsar 2.x releases do not contain the shadow topic implementation and are not affected by this specific flaw.

How do fixed versions prevent this issue?

Fixed versions disable shadow topics by default and require the superuser role to bind shadow topics to different tenants.

Can attackers decrypt end-to-end encrypted messages?

No, messages protected with client-side end-to-end encryption cannot be decrypted without the encryption keys.