J311Yl0V3U

DataSource API Missing Authorization Check Leads to Arbitrary Data Source Metadata Disclosure in Apache DolphinScheduler. This issue affects Apache DolphinScheduler: before 3.4.2. Users are recommended to upgrade to version 3.4.2, which fixes the issue.

Incorrect Authorization vulnerability of `/v2` experimental interface in Apache DolphinScheduler. This issue affects Apache DolphinScheduler: before 3.4.2. Users are recommended to upgrade to version 3.4.2, which fixes the issue.

**Name of the Vulnerable Software and Affected Versions** Apache Camel K versions 2.0.0 through 2.8.0 Apache Camel K versions 2.9.0 through 2.9.1 Apache Camel K versions 2.10.0 **Description** Authorized users in a Kubernetes namespace can create a Build resource to control Pod generation in a namespace of their choice, including the operator namespace. This cross-namespace flaw allows users to hijack pods in secure namespaces through an externally controlled reference to a resource in another sphere and authorization bypass via a user-controlled key. **Recommendations** Update versions 2.0.0 through 2.8.0 to 2.8.1. Update versions 2.9.0 through 2.9.1 to 2.9.2. Update version 2.10.0 to 2.10.1.

**Name of the Vulnerable Software and Affected Versions** local-path-provisioner versions prior to 0.0.36 **Description** A malicious user with permissions to edit the `local-path-config` ConfigMap in the `local-path-storage` namespace can manipulate the `helperPod.yaml` template. This template is used to create HelperPods during PVC provisioning and cleanup operations but is not sufficiently validated before use. An attacker can inject security-sensitive fields such as `securityContext.privileged`, `hostPath` volumes, and Linux capabilities into the template. When a PVC operation triggers the creation of a HelperPod, the provisioner uses the attacker-controlled template, potentially resulting in a privileged pod running on the target node with the host root filesystem mounted. This allows the attacker to access sensitive host files, read ServiceAccount tokens from other pods on the same node, access other tenants' local-path volume data, or modify files on the host node. **Recommendations** Update to version 0.0.36 or later. Restrict write access to the `local-path-config` ConfigMap in the `local-path-storage` namespace to trusted administrators only. Mark the `local-path-config` ConfigMap as immutable. Enable Kubernetes Pod Security Admission for the `local-path-storage` namespace by enforcing the `baseline` policy to prevent the creation of privileged HelperPods.

**Name of the Vulnerable Software and Affected Versions** Kube-router versions prior to 2.8.0 **Description** Kube-router's proxy module does not validate externalIPs or loadBalancer IPs before programming them into the node's network configuration. This impacts multi-tenant clusters where untrusted users have namespace-scoped permissions to create or modify Services. The `buildServicesInfo()` function copies IPs from `Service.spec.externalIPs` and `status.loadBalancer.ingress` without validating them against the `--service-external-ip-range` parameter. An attacker can bind arbitrary VIPs on all cluster nodes or cause denial of service to critical cluster services such as kube-dns. The `--service-external-ip-range` parameter is only used by the netpol module and is not checked by the proxy module. This allows attackers to potentially hijack traffic or disrupt DNS services. The vulnerability can be exploited by creating a Service with an externalIP matching the kube-dns ClusterIP, redirecting all DNS queries to attacker-controlled pods. The issue is not unique to kube-router, as the upstream Kubernetes project identified a similar issue as CVE-2020-8554. **Recommendations** Update to Kube-router version 2.8.0 or later.

**Name of the Vulnerable Software and Affected Versions** Nuclio versions prior to 1.15.20 **Description** Nuclio's Shell Runtime component contains a command injection issue. When a function is invoked via HTTP, the runtime reads the `X-Nuclio-Arguments` header and directly incorporates its value into shell commands without validation or sanitization. This allows attackers with function invocation permissions to inject malicious commands, potentially executing arbitrary code with root privileges in function containers, stealing ServiceAccount Tokens with cluster-admin level permissions, and ultimately gaining complete control over the Kubernetes cluster. The vulnerability stems from the lack of validation when processing user-supplied arguments in the `getCommandArguments` function and the subsequent execution of these arguments using `sh -c`. Attackers can exploit this by crafting malicious payloads in the `X-Nuclio-Arguments` header, leveraging shell metacharacters like semicolons, pipes, and backticks to inject arbitrary commands. The vulnerability affects all versions that include the Shell Runtime component. A successful exploit can lead to complete cluster compromise, including data breaches, supply chain attacks, and ransomware deployment. **Recommendations** Disable the Shell Runtime by setting `enabled: false` in the Nuclio platform configuration. Restrict function deployment permissions using Role-Based Access Control (RBAC) to limit who can deploy functions. Implement strict input validation in the `getCommandArguments` function to filter out unsafe characters. Remove the use of `sh -c` execution and use parameterized command execution instead. Limit the permissions of the ServiceAccount used by function pods to reduce the potential impact of a successful exploit.