EUVD-2026-107470
GHSA-v4g6-qq55-vgwm
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessTopic loads during init failure
-
ExploitEncryption requirement silently disabled
-
ExecutionAuthenticated producer publishes plaintext
-
ImpactBroker accepts and stores unencrypted messages
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A10:2025 - Mishandling of Exceptional Conditions
ASVS 5.0
V16 - Security Logging and Error Handling Fail-secure design
|
| Exploitation Conditions | Exploitation requires that the namespace policy encryption_required be set AND that a step of persistent-topic initialization fail at load time (e.g., a metadata-store read error, a topic-level policy load failure, or a failure in a later init step); only then does the broker fail open and serve the topic with the encryption requirement disabled. The attacker must be an authenticated client already holding produce permission on the affected topic (PR:L) - not an unauthenticated remote attacker. The window recurs on every topic reload (unload, namespace bundle reassignment, broker restart) while the underlying failure persists, but the attacker does not control or trigger that failure (reflected as AT:P / AC:H). A namespace policy update restores enforcement only until the next reload. Versions outside 1.22.0-incubating-4.0.13 and 4.1.0-4.2.4 are not affected. |
| Impact | This is a low-priority, defense-in-depth weakening rather than a directly exploitable breach. The CVSS 4.0 base score of 2.3 (LOW) is corroborated by the vector: network reachable (AV:N) but gated by an attack requirement (AT:P) - the broker must have loaded the topic while a topic-initialization step was failing - and requiring an authenticated producer with publish rights (PR:L). Impact is limited to a low integrity hit (VI:L) with no confidentiality or availability impact (VC:N/VA:N), consistent with the description's explicit statement that existing encrypted messages, content, and keys are NOT exposed. No EPSS score, KEV listing, or POC was provided, so there is no signal of active or likely exploitation - no public exploit identified at time of analysis. The practical risk is that an operator who believes namespace-wide encryption_required is enforced may silently have it disabled for specific topics after a metadata-store error, topic unload, bundle reassignment, or broker restart, and the topic statistics do not reflect this (the only indicator is a broker log warning). CWE-636 (failure to fail securely / fail-open) accurately characterizes the root cause. Note the input 'Information Disclosure' tag conflicts with the vulnerability's actual nature: the flaw weakens an encryption-enforcement control (an integrity/policy-enforcement failure), and the advisory explicitly rules out disclosure of encrypted data. |
| Exploit ScenarioDerived | An administrator sets encryption_required on a namespace, but a persistent metadata-store or policy-load error causes a topic to load with the encryption requirement silently disabled. An authenticated client that already holds produce permission to that topic then publishes plaintext messages, which the broker accepts and persists unencrypted, defeating the namespace policy. No public exploit code is known; the attacker does not control the triggering initialization failure, which must occur independently. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
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.
RemediationAI
Upgrade to a vendor-released fixed version: 4.0.x users should move to at least 4.0.14, and 4.1.x/4.2.x users should move to at least 4.2.5, per the advisory at https://pulsar.apache.org/security/CVE-2026-105933/; versions older than the supported 4.0.x and 5.0.x lines should be upgraded to a supported patched release, since after the fix a failed initialization aborts the topic load and can be retried instead of silently serving the topic unenforced. Because the vulnerable state requires an initialization failure, the most effective interim control is to eliminate the trigger: watch broker logs for warnings containing "isEncryptionRequired will be set to false" (wording varies by release), resolve the metadata-store or policy-load errors behind them, then unload and reload the affected topic and confirm the warning does not recur - note this is detective only and enforcement silently reverts on the next reload until the root cause is fixed. As a compensating control, tighten produce permissions on encryption_required namespaces so only genuinely trusted clients can write, accepting the operational overhead of narrower ACLs; alternatively, move sensitive traffic to namespaces where encryption is verified downstream by consumers, at the cost of added consumer-side complexity. Do not rely on a namespace policy update alone: it restores enforcement only on the currently loaded topic and is lost at the next unload, bundle reassignment or broker restart.
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 is a multi-tenant messaging system in which the broker reads namespace policies (stored in the metadata store, e.g. ZooKeeper/etcd) together with topic-level policies during PersistentTopic initialization. The encryption_required namespace policy instructs the broker to reject publishes that are not end-to-end encrypted. CVE-2026-105933 is a CWE-636 (Not Failing Securely / fail-open) defect: when any initialization step throws - a metadata-store read error, a failure loading topic-level policies, or a later init step - the broker catches it, logs a warning, sets isEncryptionRequired to false, and completes the load as if it had succeeded, so the topic is served with the requirement unenforced and unloaded topic-level policies are dropped. Because the degraded state is persisted for the lifetime of the loaded topic, already-connected producers as well as newly created producers can publish cleartext payloads; a namespace policy update temporarily restores enforcement on a live topic but is lost at the next reload. The failure is not necessarily transient, so the safe state is only recovered by fixing the underlying cause and reloading. Fixed releases invert the behavior: initialization failure now fails the topic load so it can be retried rather than degrading security. The CVSS 4.0 base score of 2.3 reflects the high attack prerequisites (AT:P, PR:L) and limited integrity-only impact; an independent 3.1 assessment of AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N agrees, characterizing this as a low-priority defense-in-depth weakening rather than a directly exploitable breach.
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:L/VA:N/SC:N/SI:N/SA:N
AC:H because exploitation depends on an attacker-uncontrolled topic-init failure; PR:L because an authenticated producer with publish rights is required; I:L for unenforced encryption policy, C:N/A:N as no data is exposed.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
1DescriptionCVE.org
Apache Pulsar allows an administrator to require end-to-end message encryption for all topics in a namespace by setting the encryption_required namespace policy. When this policy is set, the broker rejects messages that are published without encryption.
When the broker loads a persistent topic, it reads the namespace policies and the topic-level policies as part of topic initialization. If a step of this initialization fails, for example because of an error reading from the metadata store, a failure loading the topic-level policies or a failure in a later initialization step, the broker logs a warning, disables the encryption requirement for that topic, and completes the topic load as if it had succeeded. The topic is then served with encryption_required not enforced, even though the namespace policy requires it. Topic-level policies that could not be loaded are also not applied.
While the encryption requirement is not enforced, an authenticated client with permission to produce to the affected topic can publish messages that are not encrypted, and the broker accepts and stores them. This applies both to producers created after the topic was loaded and to producers that were already connected. Messages published with encryption remain encrypted; the issue does not expose the content of encrypted messages or the encryption keys.
The condition is not limited to transient failures. If the cause of the initialization failure persists, the encryption requirement is disabled again each time the topic is loaded, for example after a topic unload, a namespace bundle reassignment or a broker restart. An update to the namespace policies restores enforcement on a loaded topic, but only until the topic is loaded again. Enforcement is reliably restored only once the underlying cause of the failure has been resolved and the topic has been loaded again. The broker logs a warning when the encryption requirement is disabled, but the topic load is reported as successful and the state of the encryption requirement is not shown in the topic statistics.
In fixed versions, a failure during topic initialization causes the topic load to fail so that it can be retried, instead of loading the topic with the encryption requirement disabled.
This issue affects Apache Pulsar versions from 1.22.0-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 who rely on encryption_required and cannot upgrade immediately can monitor the broker logs for warnings containing "isEncryptionRequired will be set to false" (the exact wording of the message differs between releases), resolve the underlying cause of the failure, and then reload the affected topic and confirm that the warning does not recur.
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
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
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
Exploit-DB