EUVD-2026-107472
GHSA-7w25-m888-8hcq
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate with 'functions' permission in a namespace
-
ExploitCall Functions Worker trigger REST endpoint with target input topic
-
ExecutionWorker publishes caller-controlled content via its own superuser credentials
-
ImpactForged messages delivered to cross-tenant topic consumers
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 caller who holds the 'functions' management permission on a namespace (PR:L) and access to the Functions Worker trigger REST API. A hard limiting precondition is that the Functions Worker's own broker-client identity must be authorized to produce to the target input topic - and, in Pulsar 2.3.0 and later, to list that topic's subscriptions - which in practice holds mainly when the Worker runs as a superuser; where the Worker identity lacks produce rights on the target topic, the attack fails. Versions before 2.4.0 are more exposed because the trigger endpoint performs no caller-authorization check at all, so there access to the REST API alone suffices. No function instance need be running and no function code is executed. Authorization must be enabled for the 2.4.0+ scenario to be meaningful (otherwise no checks apply at all). |
| Impact | This is a genuine but moderate-severity authorization flaw, not a critical priority. The signals are internally consistent and point to limited real-world risk. The provided CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N) scores only 4.9 (Medium): it requires an authenticated caller who already holds the 'functions' permission in a namespace (PR:L), and the AT:P (attack requirements) metric reflects a hard precondition - the Functions Worker's own broker-client identity must itself be authorized to produce to (and, in 2.3.0+, list subscriptions of) the target topic, which is realistically only true when that identity is a superuser. Impact is integrity-only (SI:H; VC:N/VI:N/VA:N) - the attacker injects caller-controlled messages into topics they cannot legitimately produce to, affecting data integrity for downstream consumers, with no confidentiality or availability loss. No EPSS score, KEV listing, or POC was supplied in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation; this is consistent with a privilege-requiring, config-dependent, integrity-only issue rather than a mass-exploitation target. One data-quality note: the input Tag 'Authentication Bypass' conflicts with the CWE-862 (Missing Authorization) classification and the description - the caller is authenticated and authorized for function operations; the flaw is a missing per-topic produce-authorization check, i.e. an authorization gap, not an authentication bypass. |
| Exploit ScenarioDerived | An authenticated user holding the 'functions' permission on namespace A calls the Functions Worker trigger REST endpoint, supplying a message body and a function whose configured input topic resides in another tenant/namespace they cannot produce to. Because the Worker publishes using its own (often superuser) broker credentials and only checks function-operation authorization, the attacker's chosen content is injected into that topic under the Worker's identity, reaching its consumers. No public exploit code was identified at time of analysis and no function instance or function code needs to run. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
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.
RemediationAI
Upgrade to a fixed Apache Pulsar release: 4.0.x users should move to at least 4.0.14, and 4.1.x or 4.2.x users should move to at least 4.2.5, or to a newer supported release line. In fixed versions, when authorization is enabled, triggering a function additionally requires the caller to be authorized to produce to the selected input topic before any message is published. If immediate upgrade is not possible, limit the permission to manage functions to trusted roles, which reduces exposure on Pulsar 2.4.0 and later but does not remove the underlying missing produce-authorization check. For versions before 2.4.0, where the trigger endpoint performs no caller authorization at all, restrict access to the Functions Worker REST API to trusted callers. As a defense-in-depth measure, avoid running the Functions Worker's broker-client identity as a superuser and grant it only the produce and subscription-list permissions actually required; this narrows the set of topics the Worker can be abused to publish to, but must be validated against function input topics and operational workflows because overly restrictive Worker permissions can break legitimate function triggering. Consult the vendor advisory at https://pulsar.apache.org/security/CVE-2026-105935/ before changing authorization or Worker broker-client privileges.
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
Apache Pulsar's Functions Worker exposes a REST API that triggers a function by publishing a caller-supplied value to one of the function's configured input topics. The Worker performs this publish using its own broker client and its configured broker-client credentials, not the credentials of the API caller, so the publish is attributed to the Worker identity. The root cause is CWE-862, missing authorization: in Pulsar 2.4.0 and later with authorization enabled, the trigger endpoint verifies only that the caller may perform function operations in the function's namespace; it does not verify that the caller may produce to the selected input topic before publishing. Versions before 2.4.0 perform no caller authorization check at all for the trigger endpoint. Function input topics are not constrained to the function's own tenant or namespace, and registering a function does not require produce permission on its input topics. As a result, an authenticated user with the functions permission on a namespace can abuse the Worker's privileged broker identity to inject messages into topics the user cannot directly access, including cross-tenant topics. The practical precondition is that the Worker's broker-client identity itself has produce permission on the target topic and, from 2.3.0 onward, permission to list the target topic's subscriptions - conditions typically met when that identity is a superuser. The issue concerns the external Functions Worker REST API and does not alter the trust model for function code, which must remain fully trusted; no function instance or function code execution is needed for exploitation.
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:N/VI:N/VA:N/SC:N/SI:H/SA:N
Authenticated functions-permission caller gives PR:L; the Worker identity must be a superuser authorized to the target topic (an out-of-attacker-control precondition) gives AC:H; cross-tenant message injection under the Worker identity is a scope-changed integrity impact (S:C/I:H) with no C or A loss.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
2DescriptionCVE.org
The Pulsar Functions Worker provides a REST API endpoint for triggering a function, which publishes a caller-supplied value to one of the function's configured input topics. The Functions Worker performs this publish with its own broker client, which authenticates with the Worker's configured broker-client credentials rather than the credentials of the API caller.
When authorization is enabled, in Apache Pulsar 2.4.0 and later versions, the trigger endpoint checks only that the caller is authorized to perform function operations in the function's namespace. It does not check that the caller is authorized to produce to the input topic that the message is published to. Versions before 2.4.0 do not perform a caller authorization check for the trigger endpoint at all. Function input topics are not restricted to the function's own tenant or namespace, and registering a function does not require produce permission on its input topics.
As a result, an authenticated user who is authorized to manage functions in a namespace, for example a role granted the functions permission on that namespace, can cause the Functions Worker to publish messages with caller-controlled content to a topic that the user is not authorized to produce to, including topics in other tenants. These messages are published under the identity of the Functions Worker. The issue does not require any function instance to be running or any function code to be executed. It requires that the Functions Worker's broker-client identity is itself authorized to produce to the target topic and, in Apache Pulsar 2.3.0 and later versions, to list the subscriptions of the target topic, as is the case when that identity is a superuser. The impact is on the integrity of the data in the affected topics: consumers of those topics may receive messages from a user who is not permitted to publish them. This concerns the Functions Worker REST API as called by an external, authenticated client; it does not change the security model for function code, which must be fully trusted.
In fixed versions, when authorization is enabled, triggering a function additionally requires the caller to be authorized to produce to the selected input topic before any message is published.
This issue affects Apache Pulsar versions from 2.0.0-rc1-incubating before 4.0.14 and from 4.1.0 before 4.2.5.
- 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 of Apache Pulsar 2.4.0 and later versions with authorization enabled who cannot upgrade immediately can limit the permission to manage functions to trusted roles. Users of versions before 2.4.0 should restrict access to the Functions Worker REST API to trusted callers, because in these versions the trigger endpoint does not check the caller's permission to manage functions.
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 bypass in Apache Pulsar (2.8.0 through 4.0.13 and 4.1.0 through 4.2.4) allows an authenticated user holdin
Missing authorization checks in the Apache Pulsar broker admin REST endpoints for non-persistent topics allow an authent
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