Apache Pulsar EUVD-2026-107480

Exploitation requires TWO non-default broker settings to be active simultaneously: package management must be explicitly enabled via enablePackagesManagement, AND the filesystem storage provider (FileSystemPackagesStorageProvider) must be selected via packagesManagementStorageProvider. Both are off by default - package management is disabled by default and the default BookKeeper storage provider is NOT affected. The attacker must be an authenticated user holding the packages permission on at least one namespace (per CVSS PR:L); authorization is checked only on tenant/namespace, so any single-namespace grant suffices to reach other tenants. If broker authentication is disabled, any client able to reach the admin REST API can exploit it without credentials. Limiting factors: dependence on the specific filesystem-provider deployment mode, requirement for at least low-privilege authenticated access in authenticated deployments, and the need for network reachability to the broker admin API.

This is a genuine but conditional priority, not a blanket critical. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N) scores 7.7 (High) and the signals are internally consistent: network-reachable via the broker admin REST API, low attack complexity (trivial URL-encoded path traversal), but with Attack Requirements Present (AT:P) because exploitation only works on a specific non-default configuration. PR:L confirms an authenticated user is required - exploitation is NOT unauthenticated unless authentication is disabled broker-wide, in which case any client reaching the admin API can abuse it. No EPSS score was provided in the input, no CISA KEV listing is present, and no public exploit code is referenced, so exploitation status is 'no public exploit identified at time of analysis.' The key risk-limiting factor is the AT:P / non-default-config dependency: both enablePackagesManagement must be enabled AND the FileSystemPackagesStorageProvider must be explicitly selected - the shipped default (BookKeeper storage, packages management disabled) is not affected. Net: real and worth patching promptly for the narrow set of deployments using filesystem package storage, but the large majority of Pulsar installs running defaults are not exposed. No conflicting signals in the provided data; the main gap is the absence of EPSS/KEV/POC telemetry, which prevents weighting of real-world attacker interest.

An authenticated Pulsar user granted the packages permission on just one namespace crafts a package operation whose version component contains URL-encoded path separators and parent-directory references, causing the filesystem storage provider to resolve to a package file belonging to a different tenant or namespace. Because the resolved path still sits inside the configured storage directory, the provider's containment check passes, letting the attacker download, overwrite, or delete another tenant's packages - potentially corrupting the code backing Pulsar Functions, Sources, or Sinks. No public proof-of-concept is referenced in the provided data.