EUVD-2026-107469
GHSA-6xq3-9hvx-9qxg
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate with produce/consume permission
-
ExploitCall unauthorized non-persistent entryFilters endpoint
-
ImpactAlter or remove topic entry filter policy affecting new subscription dispatchers
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 | Exploitation requires an authenticated user who has been granted produce or consume permission on the non-persistent topic or its namespace (so not unauthenticated - the broker must have authentication and authorization enabled using the default authorization provider). Beyond that, impact is gated by two broker configuration requirements that are both OFF by default: (1) the operator must have deployed one or more entry filter implementations into the broker's entry filters directory (empty by default), and (2) allowOverrideEntryFilters must be set to true (default false) so that topic-level policies actually affect dispatch. The issue affects only non-persistent topics - persistent topics and namespace-level policies are unaffected. A policy change also only impacts subscription dispatchers created after the change (new or re-created subscriptions), not existing dispatchers, further limiting practical effect. |
| Impact | This is a genuinely low-priority issue despite the attention-grabbing tags. The signals are consistent and point to minimal real-world risk: the vendor CVSS 4.0 base score is 2.3 (Low), with AV:N but AT:P (attack requirements present) and PR:L (requires an already-authenticated user). CWE-862 (Missing Authorization) correctly characterizes it as a broken-access-control flaw, not code execution. No EPSS score was provided, there is no CISA KEV listing, and no public exploit was identified in the input - exploitation status is 'no public exploit identified at time of analysis.' The two 'RCE' and 'Authentication Bypass' tags conflict directly with the authoritative description, which states the issue 'does not allow a caller to install or load entry filter code or to run arbitrary code in the broker' and that the attacker must already be an authenticated user with produce/consume rights - so these tags overstate severity and should not drive prioritization. The most important mitigating signal is that practical impact requires TWO non-default broker configurations to be simultaneously true (entry filters deployed AND allowOverrideEntryFilters=true), so most default deployments are not exploitable at all. Net: low-severity, config-dependent, authorization-only issue affecting non-persistent topics; patch during normal maintenance cycles rather than as an emergency. |
| Exploit ScenarioDerived | In a Pulsar cluster where an operator has deployed entry filters and enabled allowOverrideEntryFilters, an authenticated user holding only produce or consume permission on a non-persistent topic calls the /admin/v2/non-persistent/{tenant}/{namespace}/{topic}/entryFilters endpoint, which omits the topic-policy authorization check. The user removes or replaces the topic's entry filter policy; newly created subscription dispatchers then stop enforcing the intended message filtering, allowing withheld messages through or withholding others. No public exploit code is referenced, and the attacker cannot read message contents or execute code. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Missing authorization checks in the Apache Pulsar broker admin REST endpoints for non-persistent topics allow an authenticated user holding only produce or consume permission on a topic or its namespace to read, replace, or delete that topic's entry filter policy. Only non-persistent topics on Pulsar 3.3.0 through 4.0.13 and 4.1.0 through 4.2.4 are affected; persistent topics, namespace-level policies, and versions before 3.3.0 are not. Real impact is tightly gated: the operator must have deployed entry filter implementations (the filters directory is empty by default) and must have set allowOverrideEntryFilters=true (default false), and even then only subscription dispatchers created after the change are affected, so conversation of the vulnerable policy only reshapes which already-installed filters withhold messages. No public exploit code was identified at time of analysis, and despite the accompanying 'RCE' tag the description confirms the flaw does not permit loading filter code or running arbitrary code in the broker.
RemediationAI
Vendor-released patch: upgrade to Apache Pulsar 4.0.14 (for 3.3.x and 4.0.x deployments) or 4.2.5 (for 4.1.x and 4.2.x deployments), or to any newer supported release; see the advisory at https://pulsar.apache.org/security/CVE-2026-105932/ for the official guidance. Because exploitation additionally requires two non-default broker settings, the most effective compensating control for teams that cannot upgrade immediately is to leave allowOverrideEntryFilters at its default of false, which makes topic-level entry filter policies inert for message dispatch; the trade-off is that operators who intentionally use per-topic filter overrides lose that capability. As a second control, avoid granting produce or consume permission on non-persistent topics or namespaces to principals that should not manage topic policies, or restrict the admin REST surface (/admin/v2/non-persistent/.../entryFilters) at the network or reverse-proxy layer, at the cost of administrative convenience for legitimate tenant admins. Deleting unused entry filter implementations from the broker's entry filters directory removes the prerequisite entirely, but requires a broker restart and disables filtering you may depend on. None of these controls require disabling authentication or the default authorization provider, which should remain enabled.
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
Entry filters are a Pulsar broker feature that lets an operator plug in compiled filter implementations (loaded at broker startup from a configured entry filters directory) to withhold selected messages from subscription dispatch. Topic-level entry filter policies are set through the broker admin REST API, and the persistent-topic variants at /admin/v2/persistent/{tenant}/{namespace}/{topic}/entryFilters correctly gate those calls on the entry filters topic policy authorization operation. The non-persistent-topic variants (/admin/v2/non-persistent/{tenant}/{namespace}/{topic}/entryFilters) omit that check entirely - a classic CWE-862 Missing Authorization flaw - and rely only on the indirect lookup permission check performed while retrieving the topic's partition metadata. Because of that gap, a user granted produce or consume on a non-persistent topic or its namespace, but not the tenant admin or superuser role required to manage topic policies, can read, replace, or remove the topic-level entry filter policy (impact is limited to disclosure of configured filter names, not message contents - filters cannot modify payloads). Versions before 3.3.0 are unaffected because the entry filters policy check lived in code shared by the persistent and non-persistent handlers. Two deployment prerequisites bound the realistic risk: the affected filters must already be installed by the operator (arbitrary filter names are rejected, and no code can be loaded), and allowOverrideEntryFilters must be true so that a topic-level policy actually overrides the broker-level configuration. Even when both hold, the modified policy applies only to subscription dispatchers created after the change; existing dispatchers retain the filters they were built with, and because non-persistent topics do not persist messages, withheld messages are simply not delivered.
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:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N
Network-reachable REST API but requires two non-default broker configurations (AC:H) and an authenticated low-privileged user (PR:L); impact is limited to disclosing filter names and altering message dispatch (C/I/A all Low).
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
2DescriptionCVE.org
The Apache Pulsar broker admin REST API provides endpoints to read, set and remove the topic-level entry filter policy of a topic. For persistent topics these endpoints check that the caller is authorized for the entry filters topic policy operation. The corresponding endpoints for non-persistent topics (/admin/v2/non-persistent/{tenant}/{namespace}/{topic}/entryFilters) do not perform this authorization check. The only authorization check these endpoints perform is an indirect lookup permission check, made while the topic's partition metadata is retrieved; it is present in all affected versions.
As a result, when authentication and authorization are enabled, an authenticated user who has been granted produce or consume permission on a non-persistent topic, or on its namespace, but not permission to manage the topic's policies can read, replace or remove the topic-level entry filter policy of that topic. These operations should be restricted to users with the tenant admin role or the superuser role. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be slightly different.
The practical impact is limited by two broker configuration requirements, neither of which is met by default:
- Entry filters must have been installed by the operator. Entry filter implementations are loaded only at broker startup from the broker's entry filters directory, which is empty by default. A request can only select among entry filters the operator has already deployed; setting any other filter name is rejected. The issue does not allow a caller to install or load entry filter code or to run arbitrary code in the broker.
- Topic-level entry filter policies must be allowed to override the broker-level configuration (allowOverrideEntryFilters, which is disabled by default). When this setting is disabled, the topic-level entry filter policy has no effect on message dispatch.
In deployments where both conditions are met, an unauthorized user can remove the topic-level entry filter policy of a non-persistent topic, for example one used to restrict which messages are delivered to consumers, or apply a different installed entry filter that withholds messages from subscriptions of that topic. Removing it makes the topic fall back to the namespace-level or broker-level entry filters, which are not removed. A changed policy affects only subscription dispatchers created after the change, for example for new subscriptions or when a subscription is re-created after all of its consumers have disconnected; dispatchers that already exist keep the entry filters they were created with. Because non-persistent topics do not store messages, messages withheld by an entry filter are not delivered. Reading the policy discloses only the names of the configured entry filters. The issue does not allow reading message contents, and entry filters cannot modify message payloads. Persistent topics and namespace-level entry filter policies are not affected. Apache Pulsar versions before 3.3.0 are not affected, because in those versions the entry filters topic policy check is made in code shared by the persistent and non-persistent endpoints.
This issue affects Apache Pulsar versions from 3.3.0 before 4.0.14 and from 4.1.0 before 4.2.5.
- 3.3.x and 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/.
Users who cannot upgrade immediately and have deployed entry filters should keep allowOverrideEntryFilters at its default value of false, so that topic-level entry filter policies do not affect message dispatch.
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
Missing authorization in Apache Pulsar's shadow topic feature allows an authenticated tenant administrator to bind a top
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
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