#kubernetes

The Confidential Clusters project integrates confidential computing technology into Kubernetes clusters. It's an end-to-end solution that provides data confidentiality on cloud platforms by isolating a cluster from its underlying infrastructure. In a confidential cluster, all nodes run on top of confidential virtual machines (cVM). Before a node can join the cluster and access secrets, the platform and environment's authenticity are verified through remote attestation. This process involves communication with a trusted remote server.Confidential Clusters enables you to use Red Hat OpenShift,

### Impact A vulnerability has been identified when using Fleet to manage Helm charts where sensitive information is passed through `BundleDeployment.Spec.Options.Helm.Values` may be stored in plain text. This can result in: 1. Unauthorized disclosure of sensitive data: Any user with `GET` or `LIST` permissions on `BundleDeployment` resources could retrieve Helm values containing credentials or other secrets. 2. Lack of encryption at rest: `BundleDeployment` is not configured for Kubernetes encryption at rest by default, causing sensitive values to remain unencrypted within the cluster datastore. This behavior differs from Helm v3’s default approach, where chart state — including values — is stored in Kubernetes secrets, benefiting from built-in protection mechanisms. In affected scenarios, credentials and other sensitive information are exposed both at rest and in responses to API calls. Please consult the associated [MITRE ATT&CK - Technique - Credentials from Password Stores](ht...

### Impact A vulnerability has been identified within Rancher Manager in which it did not enforce request body size limits on certain public (unauthenticated) and authenticated API endpoints. This allows a malicious user to exploit this by sending excessively large payloads, which are fully loaded into memory during processing. This could result in: - Denial of Service (DoS): The server process may crash or become unresponsive when memory consumption exceeds available resources. - Unauthenticated and authenticated exploitation: While the issue was initially observed in unauthenticated `/v3-public/*` endpoints, the absence of request body size limits also affected several authenticated APIs, broadening the potential attack surface. It's worth noting that other areas in Rancher do implement safeguards: requests proxied to Kubernetes APIs are subject to built-in size limits enforced by the [Kubernetes API server itself](https://github.com/kubernetes/kubernetes/blob/v1.33.4/staging/src/k8s...

This is the same vulnerability as https://github.com/edgelesssys/contrast/security/advisories/GHSA-h5f8-crrq-4pw8. The original vulnerability had been fixed for release `v1.8.1`, but the fix was not ported to the main branch and thus not present in releases `v1.9.0` ff. Below is a brief repetition of the relevant sections from the first GHSA, where you can find the full details. ### Impact * [Workload secrets](https://docs.edgeless.systems/contrast/1.11/architecture/secrets#workload-secrets) are visible to Kubernetes users with `get` or `list` permission on `pods/logs`, and thus need to be considered compromised. * Since workload secrets are used for [encrypted storage](https://docs.edgeless.systems/contrast/1.11/howto/encrypted-storage) and [Vault integration](https://docs.edgeless.systems/contrast/1.11/howto/vault), those need to be considered compromised, too. ### Patches Patches: * https://github.com/edgelesssys/contrast/commit/5a5512c4af63c17bb66331e7bd2768a863b2f225 * https...

### Impact A vulnerability exists in NeuVector versions up to and including **5.4.5**, where a fixed string is used as the default password for the built-in `admin` account. If this password is not changed immediately after deployment, any workload with network access within the cluster could use the default credentials to obtain an authentication token. This token can then be used to perform any operation via NeuVector APIs. In earlier versions, NeuVector supports setting the default (bootstrap) password for the `admin` account using a Kubernetes Secret named `neuvector-bootstrap-secret`. This Secret must contain a key named `bootstrapPassword`. However, if NeuVector fails to retrieve this value, it falls back to the fixed default password. ### Patches This issue is resolved in NeuVector version **5.4.6** and later. For rolling upgrades, it's strongly recommended to change the default `admin` password to a secure one. Starting from version **5.4.6**, NeuVector introduces addition...

### Impact When a Java command with password parameters is executed and terminated by NeuVector for Process rule violation. For example, ``` java -cp /app ... Djavax.net.ssl.trustStorePassword=<Password> ``` The command with the password appears in the NeuVector security event. To prevent this, NeuVector uses the following default regular expression to detect and redact sensitive data from process commands: ``` (?i)(password|passwd|token) ``` Also, you can define custom patterns to redact by creating a Kubernetes ConfigMap. For example: ``` kubectl create configmap neuvector-custom-rules --from-file=secret-patterns.yaml -n neuvector ``` Sample `secret-patterns.yaml` content: ``` Pattern_list: - (?i)(pawd|pword) - (?i)(secret) ``` NeuVector uses the default and custom regex to decide whether the process command in a security event should be redacted. **Note:** If numerous regular expression (regex) patterns are configured in the Kubernetes ConfigMap for extended coverage ...

A vulnerability exists in the NodeRestriction admission controller in Kubernetes clusters where node users can delete their corresponding node object by patching themselves with an OwnerReference to a cluster-scoped resource. If the OwnerReference resource does not exist or is subsequently deleted, the given node object will be deleted via garbage collection.

Menlo Park, United States, 26th August 2025, CyberNewsWire

### Summary A namespace label injection vulnerability in Capsule v0.10.3 allows authenticated tenant users to inject arbitrary labels into system namespaces (kube-system, default, capsule-system), bypassing multi-tenant isolation and potentially accessing cross-tenant resources through TenantResource selectors. This vulnerability enables privilege escalation and violates the fundamental security boundaries that Capsule is designed to enforce. ### Details The vulnerability exists in the namespace validation webhook logic located in `pkg/webhook/namespace/validation/patch.go:60-77`. The critical flaw is in the conditional check that only validates tenant ownership when a namespace already has a tenant label: ```go if label, ok := ns.Labels[ln]; ok { // Only checks permissions when namespace has tenant label if !utils.IsTenantOwner(tnt.Spec.Owners, req.UserInfo) { response := admission.Denied(e) return &response } } return nil // Critical issue: allows oper...

## Summary A vulnerability was discovered in the External Secrets Operator where the `List()` calls for Kubernetes Secret and SecretStore resources performed by the `PushSecret` controller did not apply a namespace selector. This flaw allowed an attacker to use label selectors to list and read secrets/secret-stores across the cluster, bypassing intended namespace restrictions. --- ## Impact An attacker with the ability to create or update `PushSecret` resources and control `SecretStore` configurations could exploit this vulnerability to exfiltrate sensitive data from arbitrary namespaces. This could lead to full disclosure of Kubernetes secrets, including credentials, tokens, and other sensitive information stored in the cluster. --- ## Exploitability To exploit this vulnerability, an attacker must: 1. Have permissions to create or update `PushSecret` resources. 2. Control one or more `SecretStore` resources. With these conditions met, the attacker could leverage label select...