Apache : Security Vulnerabilities, CVEs,

Improper Encoding or Escaping of Output vulnerability in Apache Zeppelin. The attackers can modify helium.json and exposure XSS attacks to normal users. This issue affects Apache Zeppelin: from 0.8.2 before 0.11.1. Users are recommended to upgrade to version 0.11.1, which fixes the issue.

Improper Input Validation vulnerability in Apache Zeppelin. The attackers can execute malicious queries by setting improper configuration properties to LDAP search filter. This issue affects Apache Zeppelin: from 0.8.2 before 0.11.1. Users are recommended to upgrade to version 0.11.1, which fixes the issue.

Improper Encoding or Escaping of Output vulnerability in Apache Zeppelin. The attackers can execute shell scripts or malicious code by overriding configuration like ZEPPELIN_INTP_CLASSPATH_OVERRIDES. This issue affects Apache Zeppelin: from 0.8.2 before 0.11.1. Users are recommended to upgrade to version 0.11.1, which fixes the issue.

Improper Input Validation vulnerability in Apache Zeppelin. The attackers can call updating cron API with invalid or improper privileges so that the notebook can run with the privileges. This issue affects Apache Zeppelin: from 0.8.2 before 0.11.1. Users are recommended to upgrade to version 0.11.1, which fixes the issue.

Improper Control of Generation of Code ('Code Injection') vulnerability in Apache Zeppelin. The attacker can inject sensitive configuration or malicious code when connecting MySQL database via JDBC driver. This issue affects Apache Zeppelin: before 0.11.1. Users are recommended to upgrade to version 0.11.1, which fixes the issue.

Authentication Bypass by Spoofing vulnerability by replacing to exsiting notes in Apache Zeppelin.This issue affects Apache Zeppelin: from 0.10.1 before 0.11.0. Users are recommended to upgrade to version 0.11.0, which fixes the issue.

Improper Input Validation vulnerability in Apache Zeppelin when creating a new note from Zeppelin's UI.This issue affects Apache Zeppelin: from 0.10.1 before 0.11.0. Users are recommended to upgrade to version 0.11.0, which fixes the issue.

Improper Control of Generation of Code ('Code Injection') vulnerability in Apache Zeppelin. The attackers can use Shell interpreter as a code generation gateway, and execute the generated code as a normal way. This issue affects Apache Zeppelin: from 0.10.1 before 0.11.1. Users are recommended to upgrade to version 0.11.1, which doesn't have Shell interpreter by default.

Improper Input Validation vulnerability in Apache Zeppelin. By adding relative path indicators(E.g ..), attackers can see the contents for any files in the filesystem that the server account can access.  This issue affects Apache Zeppelin: from 0.9.0 before 0.11.0. Users are recommended to upgrade to version 0.11.0, which fixes the issue.

Insertion of Sensitive Information into Log File vulnerability in the Apache Solr Operator. This issue affects all versions of the Apache Solr Operator from 0.3.0 through 0.8.0. When asked to bootstrap Solr security, the operator will enable basic authentication and create several accounts for accessing Solr: including the "solr" and "admin" accounts for use by end-users, and a "k8s-oper" account which the operator uses for its own requests to Solr. One common source of these operator requests is healthchecks: liveness, readiness, and startup probes are all used to determine Solr's health and ability to receive traffic. By default, the operator configures the Solr APIs used for these probes to be exempt from authentication, but users may specifically request that authentication be required on probe endpoints as well. Whenever one of these probes would fail, if authentication was in use, the Solr Operator would create a Kubernetes "event" containing the username and password of the "k8s-oper" account. Within the affected version range, this vulnerability affects any solrcloud resource which (1) bootstrapped security through use of the `.solrOptions.security.authenticationType=basic` option, and (2) required authentication be used on probes by setting `.solrOptions.security.probesRequireAuth=true`. Users are recommended to upgrade to Solr Operator version 0.8.1, which fixes this issue by ensuring that probes no longer print the credentials used for Solr requests.  Users may also mitigate the vulnerability by disabling authentication on their healthcheck probes using the setting `.solrOptions.security.probesRequireAuth=false`.

HTTP/2 CONTINUATION DoS attack can cause Apache Traffic Server to consume more resources on the server.  Version from 8.0.0 through 8.1.9, from 9.0.0 through 9.2.3 are affected. Users can set a new setting (proxy.config.http2.max_continuation_frames_per_minute) to limit the number of CONTINUATION frames per minute.  ATS does have a fixed amount of memory a request can use and ATS adheres to these limits in previous releases. Users are recommended to upgrade to versions 8.1.10 or 9.2.4 which fixes the issue.

This vulnerability allows authenticated users with produce or consume permissions to perform unauthorized operations on partitioned topics, such as unloading topics and triggering compaction. These management operations should be restricted to users with the tenant admin role or superuser role. An authenticated user with produce permission can create subscriptions and update subscription properties on partitioned topics, even though this should be limited to users with consume permissions. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be slightly different. Additionally, the vulnerability allows an authenticated user to read, create, modify, and delete namespace properties in any namespace in any tenant. In Pulsar, namespace properties are reserved for user provided metadata about the namespace. This issue affects Apache Pulsar versions from 2.7.1 to 2.10.6, from 2.11.0 to 2.11.4, from 3.0.0 to 3.0.3, from 3.1.0 to 3.1.3, and from 3.2.0 to 3.2.1. 3.0 Apache Pulsar users should upgrade to at least 3.0.4. 3.1 and 3.2 Apache Pulsar users should upgrade to at least 3.2.2. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.

Improper Preservation of Permissions vulnerability in Apache Airflow.This issue affects Apache Airflow from 2.8.2 through 2.8.3. Airflow's local file task handler in Airflow incorrectly set permissions for all parent folders of log folder, in default configuration adding write access to Unix group of the folders. In the case Airflow is run with the root user (not recommended) it added group write permission to all folders up to the root of the filesystem. If your log files are stored in the home directory, these permission changes might impact your ability to run SSH operations after your home directory becomes group-writeable. This issue does not affect users who use or extend Airflow using Official Airflow Docker reference images ( https://hub.docker.com/r/apache/airflow/ ) - those images require to have group write permission set anyway. You are affected only if you install Airflow using local installation / virtualenv or other Docker images, but the issue has no impact if docker containers are used as intended, i.e. where Airflow components do not share containers with other applications and users. Also you should not be affected if your umask is 002 (group write enabled) - this is the default on many linux systems. Recommendation for users using Airflow outside of the containers: * if you are using root to run Airflow, change your Airflow user to use non-root * upgrade Apache Airflow to 2.8.4 or above * If you prefer not to upgrade, you can change the https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#file-task-handler-new-folder-permissions  to 0o755 (original value 0o775). * if you already ran Airflow tasks before and your default umask is 022 (group write disabled) you should stop Airflow components, check permissions of AIRFLOW_HOME/logs in all your components and all parent directories of this directory and remove group write access for all the parent directories

Out-of-bounds Write vulnerability in Apache Commons Configuration.This issue affects Apache Commons Configuration: from 2.0 before 2.10.1. Users are recommended to upgrade to version 2.10.1, which fixes the issue.

Out-of-bounds Write vulnerability in Apache Commons Configuration.This issue affects Apache Commons Configuration: from 2.0 before 2.10.1. Users are recommended to upgrade to version 2.10.1, which fixes the issue.

A problem has been identified in the CloudStack additional VM configuration (extraconfig) feature which can be misused by anyone who has privilege to deploy a VM instance or configure settings of an already deployed VM instance, to configure additional VM configuration even when the feature is not explicitly enabled by the administrator. In a KVM based CloudStack environment, an attacker can exploit this issue to attach host devices such as storage disks, and PCI and USB devices such as network adapters and GPUs, in a regular VM instance that can be further exploited to gain access to the underlying network and storage infrastructure resources, and access any VM instance disks on the local storage. Users are advised to upgrade to version 4.18.1.1 or 4.19.0.1, which fixes this issue.

The CloudStack management server and secondary storage VM could be tricked into making requests to restricted or random resources by means of following 301 HTTP redirects presented by external servers when downloading templates or ISOs. Users are recommended to upgrade to version 4.18.1.1 or 4.19.0.1, which fixes this issue.

By default the CloudStack management server honours the x-forwarded-for HTTP header and logs it as the source IP of an API request. This could lead to authentication bypass and other operational problems should an attacker decide to spoof their IP address this way. Users are recommended to upgrade to CloudStack version 4.18.1.1 or 4.19.0.1, which fixes this issue.

A SSRF vulnerability using the Aegis DataBinding in versions of Apache CXF before 4.0.4, 3.6.3 and 3.5.8 allows an attacker to perform SSRF style attacks on webservices that take at least one parameter of any type. Users of other data bindings (including the default databinding) are not impacted.

Apache Airflow, versions 2.8.0 through 2.8.2, has a vulnerability that allows an authenticated user with limited permissions to access resources such as variables, connections, etc from the UI which they do not have permission to access.  Users of Apache Airflow are recommended to upgrade to version 2.8.3 or newer to mitigate the risk associated with this 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. 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. 2.10 Apache Pulsar users should upgrade to at least 2.10.6. 2.11 Apache Pulsar users should upgrade to at least 2.11.4. 3.0 Apache Pulsar users should upgrade to at least 3.0.3. 3.1 Apache Pulsar users should upgrade to at least 3.1.3. 3.2 Apache Pulsar users should upgrade to at least 3.2.1. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.

Apache Airflow, versions before 2.8.2, has a vulnerability that allows authenticated users to view DAG code and import errors of DAGs they do not have permission to view through the API and the UI. Users of Apache Airflow are recommended to upgrade to version 2.8.2 or newer to mitigate the risk associated with this vulnerability

The Pulsar Functions Worker includes a capability that permits authenticated users to create functions where the function's implementation is referenced by a URL. The supported URL schemes include "file", "http", and "https". When a function is created using this method, the Functions Worker will retrieve the implementation from the URL provided by the user. However, this feature introduces a vulnerability that can be exploited by an attacker to gain unauthorized access to any file that the Pulsar Functions Worker process has permissions to read. This includes reading the process environment which potentially includes sensitive information, such as secrets. Furthermore, an attacker could leverage this vulnerability to use the Pulsar Functions Worker as a proxy to access the content of remote HTTP and HTTPS endpoint URLs. This could also be used to carry out denial of service attacks. This vulnerability also applies to the Pulsar Broker when it is configured with "functionsWorkerEnabled=true". 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. 2.10 Pulsar Function Worker users should upgrade to at least 2.10.6. 2.11 Pulsar Function Worker users should upgrade to at least 2.11.4. 3.0 Pulsar Function Worker users should upgrade to at least 3.0.3. 3.1 Pulsar Function Worker users should upgrade to at least 3.1.3. 3.2 Pulsar Function Worker users should upgrade to at least 3.2.1. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions. The updated versions of Pulsar Functions Worker will, by default, impose restrictions on the creation of functions using URLs. For users who rely on this functionality, the Function Worker configuration provides two configuration keys: "additionalEnabledConnectorUrlPatterns" and "additionalEnabledFunctionsUrlPatterns". These keys allow users to specify a set of URL patterns that are permitted, enabling the creation of functions using URLs that match the defined patterns. This approach ensures that the feature remains available to those who require it, while limiting the potential for unauthorized access and exploitation.

An error in the evaluation of the fetch metadata headers could allow a bypass of the CSRF protection in Apache Wicket. This issue affects Apache Wicket: from 9.1.0 through 9.16.0, and the milestone releases for the 10.0 series. Apache Wicket 8.x does not support CSRF protection via the fetch metadata headers and as such is not affected. Users are recommended to upgrade to version 9.17.0 or 10.0.0, which fixes the issue.

Download of Code Without Integrity Check vulnerability in Apache Doris. The jdbc driver files used for JDBC catalog is not checked and may resulting in remote command execution. Once the attacker is authorized to create a JDBC catalog, he/she can use arbitrary driver jar file with unchecked code snippet. This code snippet will be run when catalog is initializing without any check. This issue affects Apache Doris: from 1.2.0 through 2.0.4. Users are recommended to upgrade to version 2.0.5 or 2.1.x, which fixes the issue.