Apache Pulsar
Monthly
Apache Pulsar deployments using the filesystem packages storage provider allow an authenticated user holding packages permission on any namespace to traverse out of their authorized tenant/namespace and download, overwrite, or delete packages belonging to other tenants or namespaces. The flaw is a CWE-22 path traversal in the unvalidated package version component; exploitation requires package management to be explicitly enabled and the non-default FileSystemPackagesStorageProvider to be configured, so default BookKeeper-backed deployments are not affected. No public exploit code was identified at time of analysis, and exploitation requires at least low-privilege authenticated access unless broker authentication is disabled, in which case any client able to reach the admin REST API can perform the operations without credentials.
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 full privilege set - including superuser and tenant-admin rights - on the broker admin REST API, the functions worker, and the binary protocol when their requests are relayed by a Pulsar proxy. Two distinct weaknesses in the proxy-to-broker principal check (CWE-863) are involved: the original principal is authorized with the proxy's authentication data, letting MultiRolesTokenAuthorizationProvider or a custom data-driven provider expand the caller's roles to every role in the proxy's token, and a separate tenant-admin check succeeds whenever the proxy role itself is an admin of the tenant, even under the default provider. No public exploit code has been identified at time of analysis; exposure is limited to deployments that use the multi-role token provider or a data-driven custom provider, or that list a proxy role as a tenant admin.
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.
Truncating a partitioned topic through the Apache Pulsar broker admin REST API succeeds without the caller holding tenant admin or superuser rights, letting an authenticated user wipe consumer backlog and destroy retained data on topics they merely have lookup permission for. The broker proxies each per-partition truncate request through its own internal admin client, so the tenant-admin authorization check is evaluated against the broker's configured identity rather than the caller's, and passes whenever that internal role is a superuser or tenant admin (the usual setup when authorization is enabled). Affected releases are 2.8.0 through 4.0.13 and 4.1.0 through 4.2.4, with fixes in 4.0.14 and 4.2.5; successful exploitation requires a valid authenticated identity, lookup permission on the target, a partitioned topic addressed by its partitioned name, and a suitably privileged broker internal client, and yields high integrity and availability impact with no confidentiality impact. No CISA KEV entry or public exploit code was identified at the time of analysis, and no EPSS score was supplied.
Unauthenticated role forgery in Apache Pulsar lets a client present a forged or unsigned JSON Web Token listing arbitrary roles and have those roles honored when the broker uses MultiRolesTokenAuthorizationProvider alongside a non-empty anonymousUserRole. The flaw is reachable over the broker's HTTP surfaces, including the admin REST API and the WebSocket API, where failed credentials can fall back to the anonymous role while the original Authorization header is retained and later trusted without signature verification; an attacker who names a role configured in superUserRoles can obtain super-user access to tenants, namespaces, topics, permissions and broker configuration. Only deployments combining MultiRolesTokenAuthorizationProvider with a non-empty anonymousUserRole and the fallback conditions are exposed, while installations using the default PulsarAuthorizationProvider, another authorization provider, or an unset anonymousUserRole are unaffected. Vendor-released patch: 4.0.14 and 4.2.5; no public exploit identified at time of analysis, and exploitation also requires the specific non-default configuration described.
Authorization bypass in Apache Pulsar (2.8.0 through 4.0.13 and 4.1.0 through 4.2.4) allows an authenticated user holding only namespace- or topic-level consume permission to clear backlogs, expire messages for all subscriptions, or delete subscriptions that the namespace's Prefix subscription authentication mode or per-subscription role grants should deny them. The flaw only affects brokers with authentication/authorization enabled, the default authorization provider in use, and namespaces that actually configure Prefix subscription auth mode or explicit subscription permissions; default deployments are unaffected because consume permission already authorizes these operations there. Impact is limited to subscription-state integrity - cursor advancement, subscription removal, and skipping of not-yet-replicated geo-replication messages - with no message disclosure, no policy modification, and no broker availability impact; no public exploit identified at time of analysis and CVSS scores remain low (2.3 per the vendor's CVSS 4.0 vector).
The deprecated functions connectors endpoints (/admin/v2/functions/connectors and /admin/v3/functions/connectors) in Apache Pulsar fail to enforce the super-user authorization check that the equivalent worker connectors endpoint (/admin/v2/worker/connectors) applies, so any authenticated client can read the catalog of installed Pulsar IO connector types regardless of its role. Pulsar 2.4.1 through 4.0.13 and 4.1.0 through 4.2.4 are affected when authentication and authorization are enabled; unauthenticated requests are rejected unless the operator has explicitly configured anonymous access with an anonymous user role. Impact is confined to metadata disclosure - connector names, descriptions, and source/sink/configuration class names, not configured instances or credentials - and no public exploit code has been identified at time of analysis.
Authorization flaw in Apache Pulsar's Functions Worker trigger REST endpoint allows an authenticated user who holds function-management permission on a namespace to cause the Worker to publish caller-controlled messages to a configured input topic that the user is not authorized to produce to, including topics in other tenants. Exploitation requires the Worker's own broker-client identity to be authorized to produce to the target topic and, in Pulsar 2.3.0 and later, to list that topic's subscriptions, which in practice mainly holds when the Worker identity is a superuser; no function instance needs to be running and no function code is executed. This is a moderate-severity integrity issue rather than a critical priority, and no public exploit was identified at time of analysis; vendor fixes are available in 4.0.14 and 4.2.5.
Fail-open topic initialization in Apache Pulsar (1.22.0-incubating through 4.0.13, and 4.1.0 through 4.2.4) causes the broker to silently disable a namespace's encryption_required policy for a topic whenever any step of persistent-topic loading fails, such as a metadata-store read error or a topic-level policy load failure. An authenticated client that already holds produce permission on the affected topic (CVSS PR:L) can then publish unencrypted messages that the broker accepts and stores, so the namespace's end-to-end encryption guarantee is lost for that topic; the impact is integrity-only, since already-encrypted messages and the encryption keys are never exposed. Exploitation depends on an operational initialization failure the attacker neither triggers nor controls, and the condition recurs on every topic reload (unload, bundle reassignment, broker restart) while the root cause persists - no public exploit code identified at time of analysis, and CISA KEV does not list this issue.
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.
Cross-tenant information disclosure in Apache Pulsar's transaction administration REST API allows any authenticated user - including an account granted no permissions - to read transaction coordinator and transaction metadata belonging to other tenants. The flaw is reachable only when broker authentication and authorization are enabled and transaction support is turned on via transactionCoordinatorEnabled, which is disabled by default; affected read endpoints under /admin/v3/transactions validate authentication and broker/coordinator locality but skip tenant, namespace, and topic authorization checks. Exposure is limited to metadata and statistics such as coordinator service URLs, transaction topic and subscription names, the opening principal, and pending-acknowledgement state; message contents cannot be read and transactions cannot be aborted, scaled, or otherwise modified. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor-assessed severity is low (CVSS 4.0 base 2.3; independently assessed CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).
Apache Pulsar 2.8.0 through 4.2.x deployments that enable package management allow an authenticated user to read package contents belonging to another tenant by supplying a crafted package URL when registering or updating a function, source, or sink. The Functions worker validates the caller's rights only on the namespace where the component is being created, then retrieves the referenced package from the Packages Management Service using the worker's own broker credentials, so the package ACL is evaluated against the worker instead of the requesting user (CWE-863, confused deputy). Impact is limited to confidentiality - package code, business logic, or embedded credentials may be disclosed - with no modification, deletion, or availability effect; exploitation requires authentication/authorization and non-default package-management settings, and no public exploit was identified at time of analysis.
Apache Pulsar's WebSocket service performs an incomplete authorization check when a WebSocket consumer supplies a dead letter policy via consumer endpoint query parameters, letting an authenticated user who holds only CONSUME permission on a subscribed topic cause messages to be written into a topic of their choosing - potentially in another tenant's namespace - because the deadLetterTopic's PRODUCE permission is never verified and the write is performed with the WebSocket service's own broker client identity. Affected releases are 2.3.0 through 4.0.13 and 4.1.0 through 4.2.4; the practical exposure is limited because webSocketServiceEnabled is off by default, the attacker must be an authenticated user, the WebSocket service's broker role must already hold PRODUCE on the target, and the target must accept a schema-less producer (schema validation is not enforced by default). Impact is limited to unauthorised message injection with low integrity and availability effect (dead-letter messages are distinguishable by their properties, but those properties are unauthenticated and cannot be trusted to establish origin); no public exploit code or CISA KEV-listed active exploitation was identified at time of analysis.
An authenticated Apache Pulsar client that holds no permission whatsoever on a target topic can read that topic's registered schema and register new schema versions on topics in other namespaces or tenants, because the broker's GetSchema and GetOrCreateSchema binary-protocol commands checked only that the connection was authenticated and skipped the topic-level authorization check applied to other topic commands. Deployments are exposed only when both authentication and authorization are enabled, and practical exploitation requires a client that speaks the binary protocol directly, since the standard Pulsar client performs an authorized topic lookup first that masks the missing check (GetSchema affected from 2.2.0, GetOrCreateSchema from 2.5.0, up to the fixed 4.0.14 and 4.2.5 releases). Impact is bounded: only schema metadata such as record field names and types is disclosed (never message payloads), and unauthorized schema registration is constrained by the topic's schema compatibility and auto-update policies, though a bad schema version can break legitimate producers and consumers until an administrator corrects it. No public exploit code was identified at time of analysis, and this is a moderate, administratively correctable authorization gap rather than a drop-everything priority.
Apache Pulsar deployments using the filesystem packages storage provider allow an authenticated user holding packages permission on any namespace to traverse out of their authorized tenant/namespace and download, overwrite, or delete packages belonging to other tenants or namespaces. The flaw is a CWE-22 path traversal in the unvalidated package version component; exploitation requires package management to be explicitly enabled and the non-default FileSystemPackagesStorageProvider to be configured, so default BookKeeper-backed deployments are not affected. No public exploit code was identified at time of analysis, and exploitation requires at least low-privilege authenticated access unless broker authentication is disabled, in which case any client able to reach the admin REST API can perform the operations without credentials.
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 full privilege set - including superuser and tenant-admin rights - on the broker admin REST API, the functions worker, and the binary protocol when their requests are relayed by a Pulsar proxy. Two distinct weaknesses in the proxy-to-broker principal check (CWE-863) are involved: the original principal is authorized with the proxy's authentication data, letting MultiRolesTokenAuthorizationProvider or a custom data-driven provider expand the caller's roles to every role in the proxy's token, and a separate tenant-admin check succeeds whenever the proxy role itself is an admin of the tenant, even under the default provider. No public exploit code has been identified at time of analysis; exposure is limited to deployments that use the multi-role token provider or a data-driven custom provider, or that list a proxy role as a tenant admin.
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.
Truncating a partitioned topic through the Apache Pulsar broker admin REST API succeeds without the caller holding tenant admin or superuser rights, letting an authenticated user wipe consumer backlog and destroy retained data on topics they merely have lookup permission for. The broker proxies each per-partition truncate request through its own internal admin client, so the tenant-admin authorization check is evaluated against the broker's configured identity rather than the caller's, and passes whenever that internal role is a superuser or tenant admin (the usual setup when authorization is enabled). Affected releases are 2.8.0 through 4.0.13 and 4.1.0 through 4.2.4, with fixes in 4.0.14 and 4.2.5; successful exploitation requires a valid authenticated identity, lookup permission on the target, a partitioned topic addressed by its partitioned name, and a suitably privileged broker internal client, and yields high integrity and availability impact with no confidentiality impact. No CISA KEV entry or public exploit code was identified at the time of analysis, and no EPSS score was supplied.
Unauthenticated role forgery in Apache Pulsar lets a client present a forged or unsigned JSON Web Token listing arbitrary roles and have those roles honored when the broker uses MultiRolesTokenAuthorizationProvider alongside a non-empty anonymousUserRole. The flaw is reachable over the broker's HTTP surfaces, including the admin REST API and the WebSocket API, where failed credentials can fall back to the anonymous role while the original Authorization header is retained and later trusted without signature verification; an attacker who names a role configured in superUserRoles can obtain super-user access to tenants, namespaces, topics, permissions and broker configuration. Only deployments combining MultiRolesTokenAuthorizationProvider with a non-empty anonymousUserRole and the fallback conditions are exposed, while installations using the default PulsarAuthorizationProvider, another authorization provider, or an unset anonymousUserRole are unaffected. Vendor-released patch: 4.0.14 and 4.2.5; no public exploit identified at time of analysis, and exploitation also requires the specific non-default configuration described.
Authorization bypass in Apache Pulsar (2.8.0 through 4.0.13 and 4.1.0 through 4.2.4) allows an authenticated user holding only namespace- or topic-level consume permission to clear backlogs, expire messages for all subscriptions, or delete subscriptions that the namespace's Prefix subscription authentication mode or per-subscription role grants should deny them. The flaw only affects brokers with authentication/authorization enabled, the default authorization provider in use, and namespaces that actually configure Prefix subscription auth mode or explicit subscription permissions; default deployments are unaffected because consume permission already authorizes these operations there. Impact is limited to subscription-state integrity - cursor advancement, subscription removal, and skipping of not-yet-replicated geo-replication messages - with no message disclosure, no policy modification, and no broker availability impact; no public exploit identified at time of analysis and CVSS scores remain low (2.3 per the vendor's CVSS 4.0 vector).
The deprecated functions connectors endpoints (/admin/v2/functions/connectors and /admin/v3/functions/connectors) in Apache Pulsar fail to enforce the super-user authorization check that the equivalent worker connectors endpoint (/admin/v2/worker/connectors) applies, so any authenticated client can read the catalog of installed Pulsar IO connector types regardless of its role. Pulsar 2.4.1 through 4.0.13 and 4.1.0 through 4.2.4 are affected when authentication and authorization are enabled; unauthenticated requests are rejected unless the operator has explicitly configured anonymous access with an anonymous user role. Impact is confined to metadata disclosure - connector names, descriptions, and source/sink/configuration class names, not configured instances or credentials - and no public exploit code has been identified at time of analysis.
Authorization flaw in Apache Pulsar's Functions Worker trigger REST endpoint allows an authenticated user who holds function-management permission on a namespace to cause the Worker to publish caller-controlled messages to a configured input topic that the user is not authorized to produce to, including topics in other tenants. Exploitation requires the Worker's own broker-client identity to be authorized to produce to the target topic and, in Pulsar 2.3.0 and later, to list that topic's subscriptions, which in practice mainly holds when the Worker identity is a superuser; no function instance needs to be running and no function code is executed. This is a moderate-severity integrity issue rather than a critical priority, and no public exploit was identified at time of analysis; vendor fixes are available in 4.0.14 and 4.2.5.
Fail-open topic initialization in Apache Pulsar (1.22.0-incubating through 4.0.13, and 4.1.0 through 4.2.4) causes the broker to silently disable a namespace's encryption_required policy for a topic whenever any step of persistent-topic loading fails, such as a metadata-store read error or a topic-level policy load failure. An authenticated client that already holds produce permission on the affected topic (CVSS PR:L) can then publish unencrypted messages that the broker accepts and stores, so the namespace's end-to-end encryption guarantee is lost for that topic; the impact is integrity-only, since already-encrypted messages and the encryption keys are never exposed. Exploitation depends on an operational initialization failure the attacker neither triggers nor controls, and the condition recurs on every topic reload (unload, bundle reassignment, broker restart) while the root cause persists - no public exploit code identified at time of analysis, and CISA KEV does not list this issue.
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.
Cross-tenant information disclosure in Apache Pulsar's transaction administration REST API allows any authenticated user - including an account granted no permissions - to read transaction coordinator and transaction metadata belonging to other tenants. The flaw is reachable only when broker authentication and authorization are enabled and transaction support is turned on via transactionCoordinatorEnabled, which is disabled by default; affected read endpoints under /admin/v3/transactions validate authentication and broker/coordinator locality but skip tenant, namespace, and topic authorization checks. Exposure is limited to metadata and statistics such as coordinator service URLs, transaction topic and subscription names, the opening principal, and pending-acknowledgement state; message contents cannot be read and transactions cannot be aborted, scaled, or otherwise modified. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor-assessed severity is low (CVSS 4.0 base 2.3; independently assessed CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).
Apache Pulsar 2.8.0 through 4.2.x deployments that enable package management allow an authenticated user to read package contents belonging to another tenant by supplying a crafted package URL when registering or updating a function, source, or sink. The Functions worker validates the caller's rights only on the namespace where the component is being created, then retrieves the referenced package from the Packages Management Service using the worker's own broker credentials, so the package ACL is evaluated against the worker instead of the requesting user (CWE-863, confused deputy). Impact is limited to confidentiality - package code, business logic, or embedded credentials may be disclosed - with no modification, deletion, or availability effect; exploitation requires authentication/authorization and non-default package-management settings, and no public exploit was identified at time of analysis.
Apache Pulsar's WebSocket service performs an incomplete authorization check when a WebSocket consumer supplies a dead letter policy via consumer endpoint query parameters, letting an authenticated user who holds only CONSUME permission on a subscribed topic cause messages to be written into a topic of their choosing - potentially in another tenant's namespace - because the deadLetterTopic's PRODUCE permission is never verified and the write is performed with the WebSocket service's own broker client identity. Affected releases are 2.3.0 through 4.0.13 and 4.1.0 through 4.2.4; the practical exposure is limited because webSocketServiceEnabled is off by default, the attacker must be an authenticated user, the WebSocket service's broker role must already hold PRODUCE on the target, and the target must accept a schema-less producer (schema validation is not enforced by default). Impact is limited to unauthorised message injection with low integrity and availability effect (dead-letter messages are distinguishable by their properties, but those properties are unauthenticated and cannot be trusted to establish origin); no public exploit code or CISA KEV-listed active exploitation was identified at time of analysis.
An authenticated Apache Pulsar client that holds no permission whatsoever on a target topic can read that topic's registered schema and register new schema versions on topics in other namespaces or tenants, because the broker's GetSchema and GetOrCreateSchema binary-protocol commands checked only that the connection was authenticated and skipped the topic-level authorization check applied to other topic commands. Deployments are exposed only when both authentication and authorization are enabled, and practical exploitation requires a client that speaks the binary protocol directly, since the standard Pulsar client performs an authorized topic lookup first that masks the missing check (GetSchema affected from 2.2.0, GetOrCreateSchema from 2.5.0, up to the fixed 4.0.14 and 4.2.5 releases). Impact is bounded: only schema metadata such as record field names and types is disclosed (never message payloads), and unauthorized schema registration is constrained by the topic's schema compatibility and auto-update policies, though a bad schema version can break legitimate producers and consumers until an administrator corrects it. No public exploit code was identified at time of analysis, and this is a moderate, administratively correctable authorization gap rather than a drop-everything priority.