Michael Marshall

**Name of the Vulnerable Software and Affected Versions** Apache Pulsar WebSocket Proxy versions 2.8.0 through 2.8.* Apache Pulsar WebSocket Proxy versions 2.9.0 through 2.9.* Apache Pulsar WebSocket Proxy versions 2.10.0 through 2.10.4 Apache Pulsar WebSocket Proxy versions 2.11.0 through 2.11.1 Apache Pulsar WebSocket Proxy version 3.0.0 **Description** An Improper Authentication vulnerability in Apache Pulsar WebSocket Proxy allows an attacker to connect to the "/pingpong" endpoint without authentication. The known risks include a denial of service due to the WebSocket Proxy accepting any connections, and excessive data transfer due to misuse of the WebSocket ping/pong feature. **Recommendations** For Apache Pulsar WebSocket Proxy versions 2.8.0 through 2.8.*, upgrade to at least version 2.10.5, 2.11.2, or 3.0.1. For Apache Pulsar WebSocket Proxy versions 2.9.0 through 2.9.*, upgrade to at least version 2.10.5, 2.11.2, or 3.0.1. For Apache Pulsar WebSocket Proxy versions 2.10.0 through 2.10.4, upgrade to at least version 2.10.5. For Apache Pulsar WebSocket Proxy versions 2.11.0 through 2.11.1, upgrade to at least version 2.11.2. For Apache Pulsar WebSocket Proxy version 3.0.0, upgrade to at least version 3.0.1.

**Name of the Vulnerable Software and Affected Versions** Apache Pulsar Broker versions 2.9.0 through 2.9.5 Apache Pulsar Broker versions 2.10.0 through 2.10.3 Apache Pulsar Broker version 2.11.0 **Description** The issue is related to an Incorrect Authorization vulnerability in Apache Pulsar Broker's Rest Producer, allowing an authenticated user with a custom HTTP header to produce a message to any topic using the broker's admin role. This can be exploited when an attacker connects directly to the Pulsar Broker. The vulnerability poses two known risks: producing garbage messages to any topic in the cluster and influencing topic settings for other tenants, potentially leading to exfiltration and/or deletion of messages. **Recommendations** Apache Pulsar Broker versions 2.9.0 through 2.9.5 should upgrade to one of the patched versions. Apache Pulsar Broker versions 2.10.0 through 2.10.3 should upgrade to at least version 2.10.4. Apache Pulsar Broker version 2.11.0 should upgrade to at least version 2.11.1.

**Name of the Vulnerable Software and Affected Versions** Apache Pulsar versions prior to 2.10.4 Apache Pulsar version 2.11.0 Apache Pulsar versions 2.9.* and earlier **Description** The issue is related to an Incorrect Authorization vulnerability in Apache Pulsar Function Worker, which can allow a remote attacker to access the configuration of the cloud platform. Any authenticated user can retrieve a source's configuration or a sink's configuration without authorization, potentially leading to leaked credentials. The vulnerability is mitigated by the fact that there is no known way for an authenticated user to enumerate another tenant's sources or sinks, meaning the source or sink name would need to be guessed in order to exploit this vulnerability. **Recommendations** For Apache Pulsar version 2.10, upgrade to at least version 2.10.4. For Apache Pulsar version 2.11, upgrade to at least version 2.11.1. For Apache Pulsar versions 2.9.* and earlier, upgrade to one of the above patched versions. Note that Apache Pulsar version 3.0 is unaffected.

**Name of the Vulnerable Software and Affected Versions** Apache Pulsar versions prior to 2.10.4 Apache Pulsar version 2.11.0 **Description** The issue affects Apache Pulsar when a client connects to the Pulsar Function Worker via the Pulsar Proxy, which uses mTLS authentication. The Pulsar Function Worker incorrectly performs authorization by using the Proxy's role instead of the client's role, leading to potential privilege escalation, especially if the proxy is configured with a superuser role. **Recommendations** For Apache Pulsar version 2.10, upgrade to at least version 2.10.4. For Apache Pulsar version 2.11, upgrade to at least version 2.11.1. For Apache Pulsar versions 2.9 and earlier, upgrade to one of the above patched versions.

**Name of the Vulnerable Software and Affected Versions** Apache Pulsar versions through 2.9.4 Apache Pulsar versions from 2.10.0 through 2.10.3 Apache Pulsar version 2.11.0 **Description** The issue is related to an improper authentication vulnerability in Apache Pulsar Broker, allowing a client to stay connected to a broker after authentication data expires. This can occur if the client connected through the Pulsar Proxy when the broker is configured with `authenticateOriginalAuthData=false`, or if a client connects directly to a broker with a specially crafted connect command when the broker is configured with `authenticateOriginalAuthData=false`. **Recommendations** Apache Pulsar version 2.9 users should upgrade to at least version 2.9.5. Apache Pulsar version 2.10 users should upgrade to at least version 2.10.4. Apache Pulsar version 2.11 users should upgrade to at least version 2.11.1. Any users running Apache Pulsar for versions 2.8 and earlier should upgrade to one of the above patched versions.

**Name of the Vulnerable Software and Affected Versions** Apache Pulsar Broker and Proxy versions 2.6.4 and earlier Apache Pulsar Broker and Proxy versions 2.7.0 through 2.7.4 Apache Pulsar Broker and Proxy versions 2.8.0 through 2.8.3 Apache Pulsar Broker and Proxy versions 2.9.0 through 2.9.2 Apache Pulsar Broker and Proxy version 2.10.0 **Description** The Pulsar Admin Client's intra-cluster and geo-replication HTTPS connections are vulnerable to man-in-the-middle attacks due to the lack of peer TLS certificate verification, even when `tlsAllowInsecureConnection` is disabled. This could lead to the leakage of authentication data, configuration data, and any other data sent by these clients. An attacker must take control of a machine between the client and the server and actively manipulate traffic to perform the attack. **Recommendations** For Apache Pulsar Broker and Proxy versions 2.6.4 and earlier, update to a version that verifies peer TLS certificates. For Apache Pulsar Broker and Proxy versions 2.7.0 through 2.7.4, update to a version that verifies peer TLS certificates. For Apache Pulsar Broker and Proxy versions 2.8.0 through 2.8.3, update to a version that verifies peer TLS certificates. For Apache Pulsar Broker and Proxy versions 2.9.0 through 2.9.2, update to a version that verifies peer TLS certificates. For Apache Pulsar Broker and Proxy version 2.10.0, update to a version that verifies peer TLS certificates. As a temporary workaround, consider restricting access to the intra-cluster and geo-replication HTTPS connections to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Apache Pulsar Broker, Proxy, and WebSocket Proxy versions 2.6.4 and earlier Apache Pulsar Broker, Proxy, and WebSocket Proxy versions 2.7.0 through 2.7.4 Apache Pulsar Broker, Proxy, and WebSocket Proxy versions 2.8.0 through 2.8.3 Apache Pulsar Broker, Proxy, and WebSocket Proxy versions 2.9.0 through 2.9.2 Apache Pulsar Broker, Proxy, and WebSocket Proxy version 2.10.0 **Description** TLS hostname verification cannot be enabled in the Pulsar Broker's Java Client, the Pulsar Broker's Java Admin Client, the Pulsar WebSocket Proxy's Java Client, and the Pulsar Proxy's Admin Client, leaving intra-cluster connections and geo-replication connections vulnerable to man-in-the-middle attacks. This could leak credentials, configuration data, message data, and any other data sent by these clients. The vulnerability affects both the pulsar+ssl protocol and HTTPS. An attacker must take control of a machine between the client and the server and actively manipulate traffic to perform the attack by providing the client with a cryptographically valid certificate for an unrelated host. **Recommendations** For Apache Pulsar Broker, Proxy, and WebSocket Proxy versions 2.6.4 and earlier, update to a version that includes the fix for this issue. For Apache Pulsar Broker, Proxy, and WebSocket Proxy versions 2.7.0 through 2.7.4, update to a version that includes the fix for this issue. For Apache Pulsar Broker, Proxy, and WebSocket Proxy versions 2.8.0 through 2.8.3, update to a version that includes the fix for this issue. For Apache Pulsar Broker, Proxy, and WebSocket Proxy versions 2.9.0 through 2.9.2, update to a version that includes the fix for this issue. For Apache Pulsar Broker, Proxy, and WebSocket Proxy version 2.10.0, update to a version that includes the fix for this issue. As a temporary workaround, consider restricting access to the vulnerable clients to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Apache Pulsar Java Client versions 2.6.4 and earlier Apache Pulsar Java Client versions 2.7.0 through 2.7.4 Apache Pulsar Java Client versions 2.8.0 through 2.8.3 Apache Pulsar Java Client versions 2.9.0 through 2.9.2 Apache Pulsar Java Client version 2.10.0 **Description** Delayed TLS hostname verification in the Pulsar Java Client and the Pulsar Proxy makes each client vulnerable to a man-in-the-middle attack. Connections from the Pulsar Java Client to the Pulsar Broker/Proxy and connections from the Pulsar Proxy to the Pulsar Broker are vulnerable. Authentication data is sent before verifying the server’s TLS certificate matches the hostname, which means authentication data could be exposed to an attacker. An attacker can only take advantage of this vulnerability by taking control of a machine 'between' the client and the server. The attacker must then actively manipulate traffic to perform the attack by providing the client with a cryptographically valid certificate for an unrelated host. Because the client sends authentication data before performing hostname verification, an attacker could gain access to the client’s authentication data. Token-based authentication and username/password authentication methods are vulnerable because the authentication data can be used to impersonate the client in a separate session. **Recommendations** For Apache Pulsar Java Client versions 2.6.4 and earlier, update to a version that includes the fix for this issue. For Apache Pulsar Java Client versions 2.7.0 through 2.7.4, update to a version that includes the fix for this issue. For Apache Pulsar Java Client versions 2.8.0 through 2.8.3, update to a version that includes the fix for this issue. For Apache Pulsar Java Client versions 2.9.0 through 2.9.2, update to a version that includes the fix for this issue. For Apache Pulsar Java Client version 2.10.0, update to a version that includes the fix for this issue. As a temporary workaround, consider disabling token-based authentication and username/password authentication methods until a patch is available. Restrict access to the Pulsar Broker/Proxy to minimize the risk of exploitation. Avoid using vulnerable authentication methods in the affected API endpoints until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Apache Pulsar (affected versions not specified) **Description** The issue is related to the authentication mechanism in Apache Pulsar when using JSON Web Tokens (JWT) for client authentication. If the algorithm of the presented token is set to "none", the signature of the token is not validated. This allows an attacker to connect to Pulsar instances as any user, including administrators. The vulnerability is associated with incorrect validation of the cryptographic signature, which can be exploited by a remote attacker to gain unauthorized access to protected information. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** The Squid Software Foundation Squid version 3.5.27-20180318 **Description** This issue allows remote attackers to deny service on vulnerable installations. Authentication is not required to exploit this. The specific flaw exists within the `ClientRequestContext::sslBumpAccessCheck()` function. A crafted request can trigger the dereference of a null pointer, leading to a denial-of-service condition for users of the system. **Recommendations** For The Squid Software Foundation Squid version 3.5.27-20180318, consider disabling the `sslBumpAccessCheck` functionality within the `ClientRequestContext` as a temporary workaround until a patch is available.