Export limit exceeded: 413900 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 413900 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 413900 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (413900 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-84748 | 1 Apache | 1 Brpc | 2026-10-22 | N/A |
| Improper authorization in Apache bRPC (versions < 1.18.0) on all platforms allows remote attackers to access builtin services through the public port. Root Cause: ServerOptions.internal_port is documented to make builtin services (and Tabbed services) reachable only from the internal port, and the HTTP/h2 dispatch path enforced this. However, all protobuf-based protocol dispatch paths (baidu_std, hulu_pbrpc, sofa_pbrpc, and the nshead-based protocols public_pbrpc, nshead_mcpack, nova_pbrpc and ubrpc2pb) computed the security_mode flag but never enforced it between method resolution and method invocation. Since builtin services share the method map with user services, a client able to reach the public port could invoke builtin services such as brpc.vars or hotspots by name over these pb protocols and disclose sensitive runtime information (metrics, flags, profiler data) that the operator intended to expose only via the internal port. Affected Scenarios: Use a bRPC server with ServerOptions.internal_port configured (or with builtin/Tabbed services otherwise expected to be gated by it) while the public port is reachable from an untrusted network and any pb-based protocol is enabled. How to Fix: (Choose one of the following options) 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3511 | ||||
| CVE-2026-86146 | 1 Apache | 1 Brpc | 2026-10-22 | N/A |
| Inconsistent interpretation of HTTP requests (HTTP request/response smuggling) in the bundled HTTP/1.1 parser of Apache bRPC (version < 1.18.0) on all platforms allows remote attackers to smuggle requests and inject headers when bRPC is deployed behind a proxy or load balancer that parses the same bytes differently. Root Cause: The bRPC fork of http-parser accepts and acts on several HTTP/1.1 header forms that a conforming front-end either rejects or interprets differently, so the framing or the header set of a message can differ between the front-end and bRPC: 1. A space before the colon of framing headers (e.g. Content-Length : 5) is accepted; the value still drives bRPC's framing while the reported field name contains the trailing space. 2. Interior spaces inside a Content-Length value (e.g. Content-Length: 1 3) are skipped, so bRPC reads 13 where a front-end reads 1 or rejects the message (same class as CVE-2022-32213 in Node.js). 3. Obsolete line folding (obs-fold, RFC 7230 3.2.4) of Content-Length and Transfer-Encoding values is accepted, so a folded framing value drives bRPC's framing while a front-end that does not unfold sees a different message. 4. Chunked trailer fields are fed to the same header callbacks as the header section and are merged into the header map like real headers. A front-end only inspects the header section, so any chunked request can smuggle fields such as Authorization or X-Forwarded-For past it. 5. Transfer-Encoding lists with optional whitespace after a comma (e.g. Transfer-Encoding: gzip, chunked) are not recognized as chunked: such requests are rejected, and responses are read until connection close instead of as chunked, causing response desync. Affected Scenarios: bRPC server or client communicating over HTTP/1.1 with a front proxy, load balancer, or any peer that parses the message independently. An attacker able to send requests through the front-end can desynchronize the two parsers to smuggle requests, forge headers (e.g. Authorization, X-Forwarded-For) via chunked trailers, or desynchronize responses. How to Fix: (Choose one of the following options) 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3521 Note: After applying the fix, the four header forms above are rejected by default and chunked trailers are dropped instead of merged into the header map. Two gflags are provided for compatibility: http_allow_obs_fold=true restores acceptance of folded Content-Length/Transfer-Encoding values, and http_strict_header_token=true additionally rejects spaces inside any header field name (not only the ones that decide framing). Legitimate clients that do not use these obsolete forms are unaffected. | ||||
| CVE-2026-86147 | 1 Apache | 1 Brpc | 2026-10-22 | N/A |
| External control of file name or path and uncontrolled resource consumption in Apache bRPC (version < 1.18.0) on all platforms allows remote attackers who can reach the builtin service port to create directories and truncate/overwrite files with the privileges of the server process, or to hold the process-wide CPU/contention profiler for an arbitrarily long time. Root Cause: 1. The builtin /flags service allows gflags carrying a validator to be modified at runtime via ?setvalue=. The bvar/mbvar dump path gflags (bvar_dump_file, bvar_dump_tabs, mbvar_dump_file) were registered with an accept-anything validator whose only purpose was to wake the dumping thread. A remote attacker could therefore repoint the dump path (e.g. GET /flags/bvar_dump_file?setvalue=/victim/dir/target followed by GET /flags/bvar_dump?setvalue=true, or the equivalent for mbvar_dump_file, which is used verbatim without a forced suffix), making the dumping thread recursively create directories and open/truncate files at attacker-chosen locations. Tab names in bvar_dump_tabs were appended to the path without sanitization, allowing '..' to escape the configured directory. 2. The /pprof builtin service did not clamp the ?seconds= parameter to FLAGS_max_profiling_seconds (a limit that /hotspots enforced). A single request such as ?seconds=2147483647 made the handler sleep for decades while holding the process-wide gperftools CPU profiler or bthread contention profiler, so /hotspots/cpu and /hotspots/contention returned 503 for everyone else during that time. Affected Scenarios: Any Apache bRPC server exposing the builtin services (enabled by default on the same port as normal RPC traffic) to untrusted networks. How to Fix: (Choose one of the following options) 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3523 Note: After the fix, bvar_dump_file, bvar_dump_tabs and mbvar_dump_file can no longer be modified at runtime through the /flags builtin service. They can still be changed programmatically via google::SetCommandLineOption(), taking effect on the next dump cycle. The profiling duration of /pprof is now capped by the -max_profiling_seconds gflag (default 300 seconds), which can be adjusted by the server owner. | ||||
| CVE-2026-86249 | 1 Apache | 1 Brpc | 2026-10-22 | N/A |
| On a brpc::Server that sets both ServerOptions.auth and ServerOptions.internal_port, the HTTP built-in service exemption on internal_port can be abused to bypass authentication entirely. VerifyHttpRequest() returns true without checking any credential when a built-in service is requested on internal_port, and this verdict is not per - request: verification runs only for the first message of a connection and the result latches the connection. Sending a request such as GET /status to internal_port first authenticates the whole connection, after which every subsequent request dispatched on the same connection is handled without ever calling VerifyHttpRequest(). This lets a remote attacker reach ordinary (non-built-in, non-tabbed) authenticated services without supplying valid credentials whenever the server uses ServerOptions.internal_port together with an Authenticator. The fix restricts internal_port so that it carries only built-in and Tabbed services; requests for ordinary services sent to internal_port are rejected with EPREM / HTTP 403. Mitigation / Fix: upgrade to 1.18.0 or apply PR https://github.com/apache/brpc/pull/3525 . Users who rely on serving normal services on internal_port must move those requests to the port passed to Server::Start(). | ||||
| CVE-2026-87849 | 1 Apache | 1 Brpc | 2026-10-22 | N/A |
| The Discovery naming-service reply parser in Apache bRPC (versions < 1.18.0) calls RapidJSON object-only accessors (FindMember) on JSON values without first validating that those values are objects. A malformed Discovery response whose data/service members or instances list contain non-object entries (e.g. a bare integer) triggers the RapidJSON object-access precondition on the client, reading memory out of bounds and potentially crashing the bRPC client. Root Cause: In src/brpc/policy/discovery_naming_service.cpp, DiscoveryNamingService::GetServers() and DiscoveryNames::ListDiscoveryNodes() access JSON values with member functions on non-object values. RapidJSON only defines these operations for object types; invoking them on a non-object violates the class invariant and results in undefined behavior (out-of-bounds read), commonly crashing the process. Affected Scenarios: An operator-configured (or compromised) Discovery backend returns a malformed /discovery/nodes or /discovery/fetchs response whose data/service/instance entries are not JSON objects, crashing any bRPC client that refreshes its server list. How to Fix: 1. Upgrade bRPC to version 1.18.0 or later, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3533 The fix validates that the Discovery response data, per-service data, and instance entries are JSON objects (and skips non-object node/instance entries and rejects non-object data/service values) before calling member accessors. | ||||
| CVE-2026-90484 | 1 Apache | 1 Brpc | 2026-10-22 | N/A |
| The MySQL client response parser in Apache bRPC dereferences a null pointer when the server peer sends a zero-payload-length response packet. A response packet whose declared payload length is zero is accepted by the frame-length check (is_full_package), after which the parser reads the response type byte via an unbounded 5-byte fetch that returns nullptr, and type = p[4] dereferences it, crashing the client process. Root Cause: In brpc::policy::MysqlReply::ConsumePartialIOBuf, buf.fetch(header, 5) returns nullptr when the buffered data only holds the 4-byte header of a zero-length packet, then the code reads p[4] (and, in the fast-auth path, p2[4]) without checking for a null or zero-length packet. Affected Scenarios: A brpc MySQL client connecting to a malicious or compromised MySQL server (or a MITM) can be crashed by a zero-length server response packet, resulting in denial of service of the client. Fix: The fix rejects zero-length response packets (returning PARSE_ERROR_ABSOLUTELY_WRONG) both for the initial response type determination and after a fast-auth marker, before reading the type byte. Upgrade to the Apache bRPC version 1.18.0 or apply the PR patch at https://github.com/apache/brpc/pull/3536. | ||||
| CVE-2026-114397 | 2 Polonel, Trudesk Project | 2 Trudesk, Trudesk | 2026-10-22 | 7.4 High |
| Trudesk through 1.2.11 contains a missing authentication vulnerability in debug routes enabled whenever NODE_ENV is unset, letting unauthenticated attackers invoke them remotely. Attackers can call /debug/populatedb to delete all groups, tags and tickets, then log in with seeded accounts using the password 'password'. | ||||
| CVE-2026-114403 | 1 Phpoffice | 1 Phppresentation | 2026-10-22 | 8.1 High |
| PHPOffice PHPPresentation through 1.2.0 contains an insecure deserialization vulnerability that allows attackers to instantiate arbitrary PHP objects by supplying a crafted presentation file. Attackers can upload a ZIP containing PhpPresentation.xml that IOFactory::load passes to unserialize(), enabling gadget-chain code execution, file writes, or denial of service. | ||||
| CVE-2026-114404 | 1 Phpoffice | 1 Phppresentation | 2026-10-22 | 6.1 Medium |
| PHPOffice PHPPresentation 1.2.0 contains a cross-site scripting vulnerability in the HTML writer that allows attackers who supply presentation content to inject script into generated HTML. Attackers can craft a PPTX with malicious text runs, hyperlink relationship targets, or shape descr attributes that are emitted unescaped, executing script in viewers' browsers. | ||||
| CVE-2026-20179 | 1 Cisco | 4 Cisco Open Source Snort3, Cisco Secure Firewall Threat Defense (ftd) Software, Cisco Utd Snort Ips Engine Software and 1 more | 2026-10-22 | 5.8 Medium |
| Multiple Cisco products are affected by a vulnerability in the Snort 3 Generic Routing Encapsulation (GRE) Detection Engine that could allow an unauthenticated, remote attacker to cause the Snort 3 Detection Engine to restart, resulting in an interruption of packet inspection. This vulnerability is due to incomplete error checking when Snort 3 parses GRE packets. An attacker could exploit this vulnerability by sending a crafted GRE packet to a targeted device to be parsed by Snort. A successful exploit could allow the attacker to cause the Snort 3 Detection Engine to restart unexpectedly, resulting in a DoS condition. | ||||
| CVE-2026-20291 | 1 Cisco | 5 Cisco Open Source Snort3, Cisco Secure Firewall Threat Defense (ftd) Software, Cisco Utd Snort Ips Engine Software and 2 more | 2026-10-22 | 7.8 High |
| As part of Cisco's ongoing commitment to proactive security and product quality, the Cisco owned Open Source Snort 3 Software engineering team has conducted a comprehensive internal security review. This review resulted in software hardening releases that address multiple internally discovered vulnerabilities. The vulnerabilities tracked by CVE-2026-20291 are related to issues concerning improper privilege management that are grouped under the Common Weakness Enumeration (CWE) Base CWE-269. | ||||
| CVE-2026-76490 | 1 Cisco | 1 Expressway Series | 2026-10-22 | 8.6 High |
| As part of Cisco's ongoing commitment to proactive security and product quality, the Cisco Expressway Series software engineering team has conducted a comprehensive internal security review. This review resulted in software hardening releases that address multiple internally discovered vulnerabilities. The vulnerabilities tracked by CVE-2026-76490 are related to issues concerning out-of-bounds writes that are grouped under the Common Weakness Enumeration (CWE) Base CWE-787. | ||||
| CVE-2026-76524 | 1 Cisco | 1 Cisco Open Source Snort3 | 2026-10-22 | 7.8 High |
| A vulnerability in the control channel socket implementation of Open Source Snort 3 could allow an authenticated, local attacker with low privileges to execute arbitrary commands as the Snort 3 process user. This vulnerability is due to a lack of authentication when a local user connects to the Snort control channel socket. An attacker could exploit this vulnerability by connecting to the Snort 3 control channel socket as a local user. A successful exploit could allow the attacker to execute arbitrary commands as well as read and write Snort 3 process memory. | ||||
| CVE-2026-76497 | 1 Cisco | 1 Expressway Series | 2026-10-22 | 6.6 Medium |
| As part of Cisco's ongoing commitment to proactive security and product quality, the Cisco Expressway Series software engineering team has conducted a comprehensive internal security review. This review resulted in software hardening releases that address multiple internally discovered vulnerabilities. The vulnerabilities tracked by CVE-2026-76497 are related to issues concerning insecure temporary files that are grouped under the Common Weakness Enumeration (CWE) Base CWE-377. | ||||
| CVE-2026-114123 | 1 Dynamics365ninja | 1 D365fo-mcp-server | 2026-10-22 | 7.5 High |
| D365 F&O MCP Server is a Model Context Protocol server for querying Dynamics 365 Finance & Operations X++ code and metadata. Prior to version 1.11.0, the officially documented Azure one-click deployment uses infrastructure/azuredeploy.json and infrastructure/main.bicep to default the apiKey parameter to an empty string and pass it to the App Service API_KEY setting. With API_KEY unset or empty, src/middleware/apiKeyAuth.ts passes requests through without authentication, while src/index.ts binds the HTTP listener to 0.0.0.0 by default. If the deployer leaves the optional key blank and does not add separate network restrictions or upstream authentication, the resulting public App Service allows unauthenticated JSON-RPC tools/call requests to /mcp. The deployment's MCP_SERVER_MODE=read-only setting does not prevent anonymous access to read/search tools, including search, get_object_info, batch_get_info, extension_info, security_info, find_references, and find_event_handlers, exposing indexed proprietary X++ source snippets and metadata. Exposed information can include business logic, extension and event-handler wiring, security-role and privilege structure, and labels originally indexed from PackagesLocalDirectory. Deployments protected by a configured API key, effective upstream authentication, or network restrictions preventing attacker access are outside this unauthenticated exposure scenario. This issue is fixed in version 1.11.0. | ||||
| CVE-2026-92204 | 1 Airbyte | 1 Airbyte | 2026-10-22 | N/A |
| Airbyte OneDrive Connector _get_shared_drive_object Server-Side Request Forgery Information Disclosure Vulnerability. This vulnerability allows remote attackers to initiate arbitrary server-side requests on affected installations of Airbyte. Authentication is required to exploit this vulnerability. The specific flaw exists within the _get_shared_drive_object method. The issue results from the lack of proper validation of a URI prior to accessing resources. An attacker can leverage this vulnerability to disclose information in the context of the service account. Was ZDI-CAN-28216. | ||||
| CVE-2026-105933 | 1 Apache | 1 Pulsar | 2026-10-22 | N/A |
| 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. | ||||
| CVE-2026-105935 | 1 Apache | 1 Pulsar | 2026-10-22 | N/A |
| 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. | ||||
| CVE-2026-105936 | 1 Apache | 1 Pulsar | 2026-10-22 | N/A |
| The Pulsar Functions worker REST API provides two endpoints that return the catalog of Pulsar IO connectors installed on the functions worker: the worker connectors endpoint (/admin/v2/worker/connectors) and the deprecated functions connectors endpoint (/admin/v2/functions/connectors and /admin/v3/functions/connectors). When authorization is enabled, the worker connectors endpoint requires super-user access. The functions connectors endpoint, served both by the functions worker and by a broker running the functions worker, returns the same catalog without this check. As a result, when authentication and authorization are enabled, any authenticated client can read the connector catalog through the functions connectors endpoint, regardless of the permissions granted to its role and without super-user access. Unauthenticated requests are rejected unless anonymous access is configured with an anonymous user role. The catalog contains the connector type definitions installed in the functions worker's connectors directory: the connector name, its description, and the source, sink and configuration class names. It does not contain configured source or sink instances, their configuration values or credentials, and an installed connector type does not indicate that a connector is configured or running. The impact is limited to disclosure of this metadata, which can include the names and descriptions of custom connectors installed by the operator. The issue does not allow modifying the catalog or managing connectors. Connector definitions that have a source or sink class are also returned by the built-in sources and sinks endpoints to authenticated clients. In fixed versions, the functions connectors endpoint applies the same checks as the worker connectors endpoint, so that it requires super-user access when authorization is enabled. Clients that are not super-users can use the built-in sources and sinks endpoints to list the available connector types. This issue affects Apache Pulsar versions from 2.4.1 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/. | ||||
| CVE-2026-105937 | 1 Apache | 1 Pulsar | 2026-10-22 | N/A |
| 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. | ||||