#kubernetes

In kubelet v1.13.6 and v1.14.2, containers for pods that do not specify an explicit `runAsUser` attempt to run as uid 0 (root) on container restart, or if the image was previously pulled to the node. If the pod specified `mustRunAsNonRoot: true`, the kubelet will refuse to start the container as root. If the pod did not specify `mustRunAsNonRoot: true`, the kubelet will run the container as uid 0.

In Kubernetes clusters using VSphere as a cloud provider, with a logging level set to 4 or above, VSphere cloud credentials will be leaked in the cloud controller manager's log. This affects < v1.19.3.

In Kubernetes clusters using Ceph RBD as a storage provisioner, with logging level of at least 4, Ceph RBD admin secrets can be written to logs. This occurs in kube-controller-manager's logs during provisioning of Ceph RBD persistent claims. This affects < v1.19.3, < v1.18.10, < v1.17.13.

The Kubernetes kubelet component in versions 1.1-1.16.12, 1.17.0-1.17.8 and 1.18.0-1.18.5 do not account for disk usage by a pod which writes to its own /etc/hosts file. The /etc/hosts file mounted in a pod by kubelet is not included by the kubelet eviction manager when calculating ephemeral storage usage by a pod. If a pod writes a large amount of data to the /etc/hosts file, it could fill the storage space of the node and cause the node to fail.

The Kubernetes kube-apiserver in versions v1.6-v1.15, and versions prior to v1.16.13, v1.17.9 and v1.18.7 are vulnerable to an unvalidated redirect on proxied upgrade requests that could allow an attacker to escalate privileges from a node compromise to a full cluster compromise.

Apache Solr versions 6.0.0 through 8.11.2 and versions 9.0.0 up to 9.4.1 are affected by an unrestricted file upload vulnerability which can result in remote code execution in the context of the user running Apache Solr. When Apache Solr creates a Collection, it will use a specific directory as the classpath and load some classes from it. The backup function of the Collection can export malicious class files uploaded by attackers to the directory, allowing Solr to load custom classes and create arbitrary Java code. Execution can further bypass the Java sandbox configured by Solr, ultimately causing arbitrary command execution.

### Summary Attackers with commit access to the default branch of a repo using Renovate could manipulate helmv3 registryAliases to execute arbitrary commands. ### Details Since [#26848](https://github.com/renovatebot/renovate/pull/26848), `registryAliases` has become mergeable. This means that the helmv3 manager started honoring its value and uses a `helm repo add <key> <parameters>` command for each defined alias. See source code: https://github.com/renovatebot/renovate/blob/23f3df6216375cb5bcfe027b0faee304f877f891/lib/modules/manager/helmv3/artifacts.ts#L80 The key was not quoted, leading to the ability to use variable references (`$FOO`) in it and have them printed by Renovate on the pull request, or even running any shell commands. ### PoC Inside a repository where Renovate runs, add a Helm chart with an outdated dependency, for example: test-chart/Chart.yaml: ``` apiVersion: v2 name: redis version: 1.0.0 dependencies: - name: redis version: 18.13.10 repository: oc...

It's time to start regulating LLMs to ensure they're accurately trained and ready to handle business deals that could affect the bottom line.

A security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using containers, init containers, and ephemeral containers with the envFrom field populated. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the kubernetes.io/enforce-mountable-secrets annotation are used together with containers, init containers, and ephemeral containers with the envFrom field populated.

Threat actors are actively exploiting critical vulnerabilities in OpenMetadata to gain unauthorized access to Kubernetes workloads and leverage them for cryptocurrency mining activity. That's according to the Microsoft Threat Intelligence team, which said the flaws have been weaponized since the start of April 2024. OpenMetadata is an open-source platform that operates as a