CVE-2026-105937 (GCVE-0-2026-105937)
Vulnerability from cvelistv5
Published
2026-10-21 18:12
Modified
2026-10-23 21:58
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-862 - Missing Authorization
Summary
Apache Pulsar shadow topics (PIP-180) are topics that read the stored messages of a source topic from that topic's managed ledger. The source topic is selected by setting the reserved topic property PULSAR.SHADOW_SOURCE. The admin REST API accepts this property when creating a non-partitioned or partitioned topic and when updating the properties of an existing topic. On these paths the broker authorizes the caller only against the topic being created or updated. It does not authorize the caller against the source topic named in the property. The existing authorization for shadow topic configuration (the SHADOW_TOPIC topic policy on the source topic) is applied only to the source-side shadow topics admin API, not to these paths.
As a result, an authenticated user who is allowed to create topics or update topic properties in one tenant can bind a topic in that tenant to a persistent topic in any other tenant. With the default authorization provider, these operations require the tenant admin role for the user's own tenant. The user does not need any permission on the source topic, its namespace or its tenant. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different.
The user can then consume from the shadow topic, using only permissions on their own topic, and receive retained messages that were published to the source topic in the other tenant. Exposure is limited to messages that are still retained and readable in the source topic's ledgers; messages protected with client-side end-to-end encryption cannot be decrypted without the encryption keys. A producer on the shadow topic can also register a new schema version under the source topic's schema, subject to the schema compatibility settings; existing schema versions are not replaced.
In addition, the shadow topic's managed ledger applies its own retention, trimming, offloading and deletion to the source topic's ledgers. This can permanently delete the source topic's ledger data from BookKeeper and from tiered storage, regardless of the source topic's own subscriptions and retention policy, including messages that have not yet been acknowledged. Deleting the shadow topic can also delete the source topic's ledgers. This data loss can also affect shadow topics that were configured intentionally by administrators.
This issue affects Apache Pulsar versions from 3.0.0 before 4.0.14 and from 4.1.0 before 4.2.5. Apache Pulsar 2.x releases do not contain the shadow topic implementation.
- 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/.
In the fixed versions, shadow topics are disabled by default and are controlled by the new broker configuration setting enableShadowTopics (default false). While it is disabled, the broker rejects creating shadow topics, setting the PULSAR.SHADOW_SOURCE property, and loading or replicating to existing shadow topics. Deployments that use shadow topics must set enableShadowTopics=true in the broker configuration of all brokers after upgrading; otherwise existing shadow topics will not be loaded. When shadow topics are enabled, binding a shadow topic to a source topic in a different tenant requires the superuser role. The fixed versions also prevent a shadow topic from deleting or trimming the ledgers and offloaded data of its source topic.
Affected versions provide no configuration option to disable shadow topics. Users who cannot upgrade immediately can reduce exposure by granting the tenant admin role only to trusted principals.
References
| URL | Tags | |||||||
|---|---|---|---|---|---|---|---|---|
|
||||||||
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Apache Software Foundation | Apache Pulsar |
Version: 3.0.0 ≤ Version: 4.1.0 ≤ |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-105937",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-23T20:45:31.699478Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-23T21:58:44.482Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Pulsar",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.0.14",
"status": "affected",
"version": "3.0.0",
"versionType": "semver"
},
{
"lessThan": "4.2.5",
"status": "affected",
"version": "4.1.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Elias Hasas"
},
{
"lang": "en",
"type": "finder",
"value": "Mike Read"
},
{
"lang": "en",
"type": "finder",
"value": "Omar Mousa"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Apache Pulsar shadow topics (PIP-180) are topics that read the stored messages of a source topic from that topic\u0027s managed ledger. The source topic is selected by setting the reserved topic property PULSAR.SHADOW_SOURCE. The admin REST API accepts this property when creating a non-partitioned or partitioned topic and when updating the properties of an existing topic. On these paths the broker authorizes the caller only against the topic being created or updated. It does not authorize the caller against the source topic named in the property. The existing authorization for shadow topic configuration (the SHADOW_TOPIC topic policy on the source topic) is applied only to the source-side shadow topics admin API, not to these paths.\u003cbr\u003e\u003cbr\u003eAs a result, an authenticated user who is allowed to create topics or update topic properties in one tenant can bind a topic in that tenant to a persistent topic in any other tenant. With the default authorization provider, these operations require the tenant admin role for the user\u0027s own tenant. The user does not need any permission on the source topic, its namespace or its tenant. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different.\u003cbr\u003e\u003cbr\u003eThe user can then consume from the shadow topic, using only permissions on their own topic, and receive retained messages that were published to the source topic in the other tenant. Exposure is limited to messages that are still retained and readable in the source topic\u0027s ledgers; messages protected with client-side end-to-end encryption cannot be decrypted without the encryption keys. A producer on the shadow topic can also register a new schema version under the source topic\u0027s schema, subject to the schema compatibility settings; existing schema versions are not replaced.\u003cbr\u003e\u003cbr\u003eIn addition, the shadow topic\u0027s managed ledger applies its own retention, trimming, offloading and deletion to the source topic\u0027s ledgers. This can permanently delete the source topic\u0027s ledger data from BookKeeper and from tiered storage, regardless of the source topic\u0027s own subscriptions and retention policy, including messages that have not yet been acknowledged. Deleting the shadow topic can also delete the source topic\u0027s ledgers. This data loss can also affect shadow topics that were configured intentionally by administrators.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Pulsar versions from 3.0.0 before 4.0.14 and from 4.1.0 before 4.2.5. Apache Pulsar 2.x releases do not contain the shadow topic implementation.\u003cbr\u003e\u003cbr\u003e- 4.0.x version users should upgrade to at least 4.0.14.\u003cbr\u003e- 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.\u003cbr\u003e\u003cbr\u003eUsers operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.\u003cbr\u003e\u003cbr\u003eThe 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/.\u003cbr\u003e\u003cbr\u003eIn the fixed versions, shadow topics are disabled by default and are controlled by the new broker configuration setting enableShadowTopics (default false). While it is disabled, the broker rejects creating shadow topics, setting the PULSAR.SHADOW_SOURCE property, and loading or replicating to existing shadow topics. Deployments that use shadow topics must set enableShadowTopics=true in the broker configuration of all brokers after upgrading; otherwise existing shadow topics will not be loaded. When shadow topics are enabled, binding a shadow topic to a source topic in a different tenant requires the superuser role. The fixed versions also prevent a shadow topic from deleting or trimming the ledgers and offloaded data of its source topic.\u003cbr\u003e\u003cbr\u003eAffected versions provide no configuration option to disable shadow topics. Users who cannot upgrade immediately can reduce exposure by granting the tenant admin role only to trusted principals."
}
],
"value": "Apache Pulsar shadow topics (PIP-180) are topics that read the stored messages of a source topic from that topic\u0027s managed ledger. The source topic is selected by setting the reserved topic property PULSAR.SHADOW_SOURCE. The admin REST API accepts this property when creating a non-partitioned or partitioned topic and when updating the properties of an existing topic. On these paths the broker authorizes the caller only against the topic being created or updated. It does not authorize the caller against the source topic named in the property. The existing authorization for shadow topic configuration (the SHADOW_TOPIC topic policy on the source topic) is applied only to the source-side shadow topics admin API, not to these paths.\n\nAs a result, an authenticated user who is allowed to create topics or update topic properties in one tenant can bind a topic in that tenant to a persistent topic in any other tenant. With the default authorization provider, these operations require the tenant admin role for the user\u0027s own tenant. The user does not need any permission on the source topic, its namespace or its tenant. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different.\n\nThe user can then consume from the shadow topic, using only permissions on their own topic, and receive retained messages that were published to the source topic in the other tenant. Exposure is limited to messages that are still retained and readable in the source topic\u0027s ledgers; messages protected with client-side end-to-end encryption cannot be decrypted without the encryption keys. A producer on the shadow topic can also register a new schema version under the source topic\u0027s schema, subject to the schema compatibility settings; existing schema versions are not replaced.\n\nIn addition, the shadow topic\u0027s managed ledger applies its own retention, trimming, offloading and deletion to the source topic\u0027s ledgers. This can permanently delete the source topic\u0027s ledger data from BookKeeper and from tiered storage, regardless of the source topic\u0027s own subscriptions and retention policy, including messages that have not yet been acknowledged. Deleting the shadow topic can also delete the source topic\u0027s ledgers. This data loss can also affect shadow topics that were configured intentionally by administrators.\n\nThis issue affects Apache Pulsar versions from 3.0.0 before 4.0.14 and from 4.1.0 before 4.2.5. Apache Pulsar 2.x releases do not contain the shadow topic implementation.\n\n- 4.0.x version users should upgrade to at least 4.0.14.\n- 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.\n\nUsers operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.\n\nThe 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/.\n\nIn the fixed versions, shadow topics are disabled by default and are controlled by the new broker configuration setting enableShadowTopics (default false). While it is disabled, the broker rejects creating shadow topics, setting the PULSAR.SHADOW_SOURCE property, and loading or replicating to existing shadow topics. Deployments that use shadow topics must set enableShadowTopics=true in the broker configuration of all brokers after upgrading; otherwise existing shadow topics will not be loaded. When shadow topics are enabled, binding a shadow topic to a source topic in a different tenant requires the superuser role. The fixed versions also prevent a shadow topic from deleting or trimming the ledgers and offloaded data of its source topic.\n\nAffected versions provide no configuration option to disable shadow topics. Users who cannot upgrade immediately can reduce exposure by granting the tenant admin role only to trusted principals."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.7,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:12:51.420Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://pulsar.apache.org/security/CVE-2026-105937/"
},
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread.html/80foc311bwn839skc1p7fh89pgsrhyoj"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Apache Pulsar: Missing authorization of the shadow topic source allows cross-tenant message disclosure and deletion of source topic data",
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-105937",
"datePublished": "2026-10-21T18:12:51.420Z",
"dateReserved": "2026-10-06T06:45:39.018Z",
"dateUpdated": "2026-10-23T21:58:44.482Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"vulnrichment": {
"containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-105937\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"total\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-10-23T20:45:31.699478Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-10-23T20:45:32.506Z\"}}], \"cna\": {\"title\": \"Apache Pulsar: Missing authorization of the shadow topic source allows cross-tenant message disclosure and deletion of source topic data\", \"source\": {\"discovery\": \"EXTERNAL\"}, \"credits\": [{\"lang\": \"en\", \"type\": \"finder\", \"value\": \"Elias Hasas\"}, {\"lang\": \"en\", \"type\": \"finder\", \"value\": \"Mike Read\"}, {\"lang\": \"en\", \"type\": \"finder\", \"value\": \"Omar Mousa\"}], \"metrics\": [{\"format\": \"CVSS\", \"cvssV4_0\": {\"Safety\": \"NOT_DEFINED\", \"version\": \"4.0\", \"Recovery\": \"NOT_DEFINED\", \"baseScore\": 8.7, \"Automatable\": \"NOT_DEFINED\", \"attackVector\": \"NETWORK\", \"baseSeverity\": \"HIGH\", \"valueDensity\": \"NOT_DEFINED\", \"vectorString\": \"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N\", \"exploitMaturity\": \"NOT_DEFINED\", \"providerUrgency\": \"NOT_DEFINED\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"attackRequirements\": \"NONE\", \"privilegesRequired\": \"LOW\", \"subIntegrityImpact\": \"NONE\", \"vulnIntegrityImpact\": \"HIGH\", \"subAvailabilityImpact\": \"NONE\", \"vulnAvailabilityImpact\": \"HIGH\", \"subConfidentialityImpact\": \"NONE\", \"vulnConfidentialityImpact\": \"HIGH\", \"vulnerabilityResponseEffort\": \"NOT_DEFINED\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"GENERAL\"}]}], \"affected\": [{\"vendor\": \"Apache Software Foundation\", \"product\": \"Apache Pulsar\", \"versions\": [{\"status\": \"affected\", \"version\": \"3.0.0\", \"lessThan\": \"4.0.14\", \"versionType\": \"semver\"}, {\"status\": \"affected\", \"version\": \"4.1.0\", \"lessThan\": \"4.2.5\", \"versionType\": \"semver\"}], \"defaultStatus\": \"unaffected\"}], \"references\": [{\"url\": \"https://pulsar.apache.org/security/CVE-2026-105937/\", \"tags\": [\"vendor-advisory\"]}, {\"url\": \"https://lists.apache.org/thread.html/80foc311bwn839skc1p7fh89pgsrhyoj\", \"tags\": [\"vendor-advisory\"]}], \"x_generator\": {\"engine\": \"Vulnogram 1.0.3\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"Apache Pulsar shadow topics (PIP-180) are topics that read the stored messages of a source topic from that topic\u0027s managed ledger. The source topic is selected by setting the reserved topic property PULSAR.SHADOW_SOURCE. The admin REST API accepts this property when creating a non-partitioned or partitioned topic and when updating the properties of an existing topic. On these paths the broker authorizes the caller only against the topic being created or updated. It does not authorize the caller against the source topic named in the property. The existing authorization for shadow topic configuration (the SHADOW_TOPIC topic policy on the source topic) is applied only to the source-side shadow topics admin API, not to these paths.\\n\\nAs a result, an authenticated user who is allowed to create topics or update topic properties in one tenant can bind a topic in that tenant to a persistent topic in any other tenant. With the default authorization provider, these operations require the tenant admin role for the user\u0027s own tenant. The user does not need any permission on the source topic, its namespace or its tenant. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different.\\n\\nThe user can then consume from the shadow topic, using only permissions on their own topic, and receive retained messages that were published to the source topic in the other tenant. Exposure is limited to messages that are still retained and readable in the source topic\u0027s ledgers; messages protected with client-side end-to-end encryption cannot be decrypted without the encryption keys. A producer on the shadow topic can also register a new schema version under the source topic\u0027s schema, subject to the schema compatibility settings; existing schema versions are not replaced.\\n\\nIn addition, the shadow topic\u0027s managed ledger applies its own retention, trimming, offloading and deletion to the source topic\u0027s ledgers. This can permanently delete the source topic\u0027s ledger data from BookKeeper and from tiered storage, regardless of the source topic\u0027s own subscriptions and retention policy, including messages that have not yet been acknowledged. Deleting the shadow topic can also delete the source topic\u0027s ledgers. This data loss can also affect shadow topics that were configured intentionally by administrators.\\n\\nThis issue affects Apache Pulsar versions from 3.0.0 before 4.0.14 and from 4.1.0 before 4.2.5. Apache Pulsar 2.x releases do not contain the shadow topic implementation.\\n\\n- 4.0.x version users should upgrade to at least 4.0.14.\\n- 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.\\n\\nUsers operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.\\n\\nThe 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/.\\n\\nIn the fixed versions, shadow topics are disabled by default and are controlled by the new broker configuration setting enableShadowTopics (default false). While it is disabled, the broker rejects creating shadow topics, setting the PULSAR.SHADOW_SOURCE property, and loading or replicating to existing shadow topics. Deployments that use shadow topics must set enableShadowTopics=true in the broker configuration of all brokers after upgrading; otherwise existing shadow topics will not be loaded. When shadow topics are enabled, binding a shadow topic to a source topic in a different tenant requires the superuser role. The fixed versions also prevent a shadow topic from deleting or trimming the ledgers and offloaded data of its source topic.\\n\\nAffected versions provide no configuration option to disable shadow topics. Users who cannot upgrade immediately can reduce exposure by granting the tenant admin role only to trusted principals.\", \"supportingMedia\": [{\"type\": \"text/html\", \"value\": \"Apache Pulsar shadow topics (PIP-180) are topics that read the stored messages of a source topic from that topic\u0027s managed ledger. The source topic is selected by setting the reserved topic property PULSAR.SHADOW_SOURCE. The admin REST API accepts this property when creating a non-partitioned or partitioned topic and when updating the properties of an existing topic. On these paths the broker authorizes the caller only against the topic being created or updated. It does not authorize the caller against the source topic named in the property. The existing authorization for shadow topic configuration (the SHADOW_TOPIC topic policy on the source topic) is applied only to the source-side shadow topics admin API, not to these paths.\u003cbr\u003e\u003cbr\u003eAs a result, an authenticated user who is allowed to create topics or update topic properties in one tenant can bind a topic in that tenant to a persistent topic in any other tenant. With the default authorization provider, these operations require the tenant admin role for the user\u0027s own tenant. The user does not need any permission on the source topic, its namespace or its tenant. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different.\u003cbr\u003e\u003cbr\u003eThe user can then consume from the shadow topic, using only permissions on their own topic, and receive retained messages that were published to the source topic in the other tenant. Exposure is limited to messages that are still retained and readable in the source topic\u0027s ledgers; messages protected with client-side end-to-end encryption cannot be decrypted without the encryption keys. A producer on the shadow topic can also register a new schema version under the source topic\u0027s schema, subject to the schema compatibility settings; existing schema versions are not replaced.\u003cbr\u003e\u003cbr\u003eIn addition, the shadow topic\u0027s managed ledger applies its own retention, trimming, offloading and deletion to the source topic\u0027s ledgers. This can permanently delete the source topic\u0027s ledger data from BookKeeper and from tiered storage, regardless of the source topic\u0027s own subscriptions and retention policy, including messages that have not yet been acknowledged. Deleting the shadow topic can also delete the source topic\u0027s ledgers. This data loss can also affect shadow topics that were configured intentionally by administrators.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Pulsar versions from 3.0.0 before 4.0.14 and from 4.1.0 before 4.2.5. Apache Pulsar 2.x releases do not contain the shadow topic implementation.\u003cbr\u003e\u003cbr\u003e- 4.0.x version users should upgrade to at least 4.0.14.\u003cbr\u003e- 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.\u003cbr\u003e\u003cbr\u003eUsers operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.\u003cbr\u003e\u003cbr\u003eThe 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/.\u003cbr\u003e\u003cbr\u003eIn the fixed versions, shadow topics are disabled by default and are controlled by the new broker configuration setting enableShadowTopics (default false). While it is disabled, the broker rejects creating shadow topics, setting the PULSAR.SHADOW_SOURCE property, and loading or replicating to existing shadow topics. Deployments that use shadow topics must set enableShadowTopics=true in the broker configuration of all brokers after upgrading; otherwise existing shadow topics will not be loaded. When shadow topics are enabled, binding a shadow topic to a source topic in a different tenant requires the superuser role. The fixed versions also prevent a shadow topic from deleting or trimming the ledgers and offloaded data of its source topic.\u003cbr\u003e\u003cbr\u003eAffected versions provide no configuration option to disable shadow topics. Users who cannot upgrade immediately can reduce exposure by granting the tenant admin role only to trusted principals.\", \"base64\": false}]}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-862\", \"description\": \"CWE-862 Missing Authorization\"}]}], \"providerMetadata\": {\"orgId\": \"f0158376-9dc2-43b6-827c-5f631a4d8d09\", \"shortName\": \"apache\", \"dateUpdated\": \"2026-10-21T18:12:51.420Z\"}}}",
"cveMetadata": "{\"cveId\": \"CVE-2026-105937\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-10-23T21:58:44.482Z\", \"dateReserved\": \"2026-10-06T06:45:39.018Z\", \"assignerOrgId\": \"f0158376-9dc2-43b6-827c-5f631a4d8d09\", \"datePublished\": \"2026-10-21T18:12:51.420Z\", \"assignerShortName\": \"apache\"}",
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…