Vulnerabilities

FreeScout is an open source help desk and shared inbox built with PHP.<br /> <br /> A vulnerability has been identified in the Free Scout Application, which exposes SMTP server credentials used by an organization in the application to users of the application. This issue arises from the application storing complete stack traces of exceptions in its database. The sensitive information is then inadvertently disclosed to users via the `/conversation/ajax-html/send_log?folder_id=&amp;thread_id={id}` endpoint. The stack trace reveals value of parameters, including the username and password, passed to the `Swift_Transport_Esmtp_Auth_LoginAuthenticator-&gt;authenticate()` function. Exploiting this vulnerability allows an attacker to gain unauthorized access to SMTP server credentials. With this sensitive information in hand, the attacker can potentially send unauthorized emails from the compromised SMTP server, posing a severe threat to the confidentiality and integrity of email communications. This could lead to targeted attacks on both the application users and the organization itself, compromising the security of email exchange servers. This issue has been addressed in version 1.8.124. Users are advised to upgrade. Users unable to upgrade should adopt the following measures: 1. Avoid Storing Complete Stack Traces, 2. Implement redaction mechanisms to filter and exclude sensitive information, and 3. Review and enhance the application&amp;#39;s logging practices.

stimulus_reflex is a system to extend the capabilities of both Rails and Stimulus by intercepting user interactions and passing them to Rails over real-time websockets. In affected versions more methods than expected can be called on reflex instances. Being able to call some of them has security implications. To invoke a reflex a websocket message of the following shape is sent: `\"target\":\"[class_name]#[method_name]\",\"args\":[]`. The server will proceed to instantiate `reflex` using the provided `class_name` as long as it extends `StimulusReflex::Reflex`. It then attempts to call `method_name` on the instance with the provided arguments. This is problematic as `reflex.method method_name` can be more methods that those explicitly specified by the developer in their reflex class. A good example is the instance_variable_set method. This vulnerability has been patched in versions 3.4.2 and 3.5.0.rc4. Users unable to upgrade should: see the backing GHSA advisory for mitigation advice.

The Video Conferencing with Zoom plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin&amp;#39;s &amp;#39;zoom_recordings_by_meeting&amp;#39; shortcode in all versions up to, and including, 4.4.4 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers with contributor-level and above permissions to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The CWW Companion plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the Module2 widget in all versions up to, and including, 1.2.7 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers with contributor-level and above permissions to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

Peering Manager is a BGP session management tool. Affected versions of Peering Manager are subject to a potential stored Cross-Site Scripting (XSS) attack in the `name` attribute of AS or Platform. The XSS triggers on a routers detail page. Adversaries are able to execute arbitrary JavaScript code with the permission of a victim. XSS attacks are often used to steal credentials or login tokens of other users. This issue has been addressed in version 1.8.3. Users are advised to upgrade. There are no known workarounds for this vulnerability.<br />

Peering Manager is a BGP session management tool. In Peering Manager

One of Gotham Gaia services was found to be vulnerable to a stored cross-site scripting (XSS) vulnerability that could have allowed an attacker to bypass CSP and get a persistent cross site scripting payload on the stack.<br />

A potential security vulnerability has been reported in the system BIOS of certain HP PC products, which might allow memory tampering. HP is releasing mitigation for the potential vulnerability.

The vulnerability allows authenticated users with only produce or consume permissions to modify topic-level policies, such as retention, TTL, and offloading settings. These management operations should be restricted to users with the tenant admin role or super user role.<br /> <br /> This issue affects Apache Pulsar versions from 2.7.1 to 2.10.5, from 2.11.0 to 2.11.3, from 3.0.0 to 3.0.2, from 3.1.0 to 3.1.2, and 3.2.0. <br /> <br /> 2.10 Apache Pulsar users should upgrade to at least 2.10.6.<br /> 2.11 Apache Pulsar users should upgrade to at least 2.11.4.<br /> 3.0 Apache Pulsar users should upgrade to at least 3.0.3.<br /> 3.1 Apache Pulsar users should upgrade to at least 3.1.3.<br /> 3.2 Apache Pulsar users should upgrade to at least 3.2.1.<br /> <br /> Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.

Improper Authentication vulnerability in Apache Pulsar Proxy allows an attacker to connect to the /proxy-stats endpoint without authentication. The vulnerable endpoint exposes detailed statistics about live connections, along with the capability to modify the logging level of proxied connections without requiring proper authentication credentials.<br /> <br /> This issue affects Apache Pulsar versions from 2.6.0 to 2.10.5, from 2.11.0 to 2.11.2, from 3.0.0 to 3.0.1, and 3.1.0.<br /> <br /> The known risks include exposing sensitive information such as connected client IP and unauthorized logging level manipulation which could lead to a denial-of-service condition by significantly increasing the proxy&amp;#39;s logging overhead. When deployed via the Apache Pulsar Helm chart within Kubernetes environments, the actual client IP might not be revealed through the load balancer&amp;#39;s default behavior, which typically obscures the original source IP addresses when externalTrafficPolicy is being configured to "Cluster" by default. The /proxy-stats endpoint contains topic level statistics, however, in the default configuration, the topic level statistics aren&amp;#39;t known to be exposed.<br /> <br /> 2.10 Pulsar Proxy users should upgrade to at least 2.10.6.<br /> 2.11 Pulsar Proxy users should upgrade to at least 2.11.3.<br /> 3.0 Pulsar Proxy users should upgrade to at least 3.0.2.<br /> 3.1 Pulsar Proxy users should upgrade to at least 3.1.1.<br /> <br /> Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions. Additionally, it&amp;#39;s imperative to recognize that the Apache Pulsar Proxy is not intended for direct exposure to the internet. The architectural design of Pulsar Proxy assumes that it will operate within a secured network environment, safeguarded by appropriate perimeter defenses.

Improper input validation in the Pulsar Function Worker allows a malicious authenticated user to execute arbitrary Java code on the Pulsar Function worker, outside of the sandboxes designated for running user-provided functions. This vulnerability also applies to the Pulsar Broker when it is configured with "functionsWorkerEnabled=true".<br /> <br /> This issue affects Apache Pulsar versions from 2.4.0 to 2.10.5, from 2.11.0 to 2.11.3, from 3.0.0 to 3.0.2, from 3.1.0 to 3.1.2, and 3.2.0. <br /> <br /> 2.10 Pulsar Function Worker users should upgrade to at least 2.10.6.<br /> 2.11 Pulsar Function Worker users should upgrade to at least 2.11.4.<br /> 3.0 Pulsar Function Worker users should upgrade to at least 3.0.3.<br /> 3.1 Pulsar Function Worker users should upgrade to at least 3.1.3.<br /> 3.2 Pulsar Function Worker users should upgrade to at least 3.2.1.<br /> <br /> Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.

In Pulsar Functions Worker, authenticated users can upload functions in jar or nar files. These files, essentially zip files, are extracted by the Functions Worker. However, if a malicious file is uploaded, it could exploit a directory traversal vulnerability. This occurs when the filenames in the zip files, which aren&amp;#39;t properly validated, contain special elements like "..", altering the directory path. This could allow an attacker to create or modify files outside of the designated extraction directory, potentially influencing system behavior. This vulnerability also applies to the Pulsar Broker when it is configured with "functionsWorkerEnabled=true".<br /> <br /> This issue affects Apache Pulsar versions from 2.4.0 to 2.10.5, from 2.11.0 to 2.11.3, from 3.0.0 to 3.0.2, from 3.1.0 to 3.1.2, and 3.2.0. <br /> <br /> 2.10 Pulsar Function Worker users should upgrade to at least 2.10.6.<br /> 2.11 Pulsar Function Worker users should upgrade to at least 2.11.4.<br /> 3.0 Pulsar Function Worker users should upgrade to at least 3.0.3.<br /> 3.1 Pulsar Function Worker users should upgrade to at least 3.1.3.<br /> 3.2 Pulsar Function Worker users should upgrade to at least 3.2.1.<br /> <br /> Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.