The Pulsar broker serves two schema commands on its binary protocol: GetSchema, which returns the schema registered for a topic, and GetOrCreateSchema, which registers a new schema version for an existing topic. The broker handled both commands after checking only that the client connection was authenticated. Unlike the broker's other topic commands, such as those for creating producers and consumers or for looking up topics, these two commands did not check whether the authenticated client was authorized for the target topic. The Pulsar REST API endpoints for schemas were not affected.
An authenticated client without any permission on the target topic, namespace or tenant could use these commands to:
- read the schema registered for a topic in another namespace or tenant, disclosing the schema definition such as record field names and types. Message payloads are not disclosed.
- register a new schema version on an existing topic in another namespace or tenant. The topic's schema compatibility and schema auto-update policies still apply. The issue does not allow message data to be read or modified, but a registered schema version can cause legitimate producers and consumers of that topic to fail with schema incompatibility errors until the schema is corrected by an administrator.
The standard Pulsar client performs an authorized topic lookup before it sends these commands, so the missing check could not be observed when testing with the standard client. A client that implements the binary protocol directly is not required to perform that lookup first.
This issue is relevant only to deployments that have authentication and authorization enabled. The GetSchema command is affected from Apache Pulsar 2.2.0, and the GetOrCreateSchema command from Apache Pulsar 2.5.0. After the fix, the broker requires the lookup permission on the topic for GetSchema and the produce permission on the topic for GetOrCreateSchema. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be slightly different.
This issue affects Apache Pulsar versions from 2.2.0 before 4.0.14, from 4.1.0 through 4.1.3, and from 4.2.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/.
What the EG score is made of (scorer v4.0: the three questions the 0–10 score mixes, published apart · methodology)
The EG score (5.3): severity, escalated by confirmed exploitation. This CVE's 5.3 is its impact severity (EG Severity), not escalated.
- EG Severity
- 5.3 MEDIUMCVSS-B, impact only: no KEV listing, EPSS or EG-KEV tier raises it.a secondary CVSS source · CVSS v3.0 or v3.1
- EG Likelihood
- 0.4% within 30 daysSource: FIRST EPSS (model v2026.06.15, score date 2026-10-24). FIRST's exploitation probability, not an EchelonGraph model.
- Confirmed exploitation
- None on record (CISA KEV, EG-KEV Tier 1)Reported apart from the likelihood: an observed fact, not a probability.
- EG Priority
- SSVC Track at medium mission impactTrack at every mission impact level.CISA BOD 26-04: 60 days if the affected system is publicly exposed; Fix on system upgrade if it is not.Each input and its source: the SSVC and BOD 26-04 blocks below.
SSVC (CISA's decision table, applied by EchelonGraph)Track at every mission impact level.
The CVE record names the fixed release. Apply it within your standard update timelines.
Exploitation none (no CISA value, KEV listing or exploit code on record) · Automatable no (CISA's BOD 26-04 default) · Technical impact partial (CVSS v4.0 confidentiality and integrity impact neither High). EchelonGraph holds no SSVC assessment of this CVE from CISA: none of these inputs is from Vulnrichment. EchelonGraph applied CISA's decision table to them; CISA publishes SSVC inputs and the table, not a decision for each CVE. Mission impact is CISA's Mission & Well-being decision point, and only you can judge it. CISA's table makes it high when Mission Prevalence is Essential — the vulnerable component "directly provides capabilities that constitute at least one MEF for at least one entity" (MEF: mission essential function) — or when Public Well-Being Impact is Irreversible: "multiple fatalities are likely", the cyber-physical system "is likely lost or destroyed", "extreme or serious externalities" are imposed on other parties, or social systems such as elections or the financial grid "are destabilized and potentially collapse". CISA's decision table
BOD 26-04 (CISA's remediation timeline, Table 1)60 days if the affected system is publicly exposed; Fix on system upgrade if it is not.
In CISA KEV no (CISA's KEV catalog) · Automatable no (CISA's BOD 26-04 default) · Technical impact partial (CVSS v4.0 confidentiality and integrity impact neither High). Where an input reads “CISA's BOD 26-04 default”, no one has published it for this CVE, and CISA's implementation guidance says: “If “Automatable” and “Technical Impact” information items about a CVE ID are not available and the CVE ID is not in the KEV Catalog, CISA will treat its values as “no” and “total,” respectively, until CISA or a third party provides metadata about the CVE ID. CISA will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog.” Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it