#kubernetes

### 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...

Menlo Park, California, USA, 7th August 2025, CyberNewsWire

Red Hat OpenShift Service Mesh 3.1 has been released and is included with the Red Hat OpenShift Container Platform and Red Hat OpenShift Platform Plus. Based on the Istio, Envoy, and Kiali projects, this release updates the version of Istio to 1.26 and Kiali to 2.11, and is supported on OpenShift Container Platform 4.16 and above.This is the first minor release following Red Hat OpenShift Service Mesh 3.0, a major update to converge OpenShift Service Mesh with the community Istio project, with installation and management using the Sail operator. This change helps ensure that OpenShift Service

Menlo Park, United States, 30th July 2025, CyberNewsWire

### Summary A Denial of Service (DoS) vulnerability exists in Kyverno due to improper handling of JMESPath variable substitutions. Attackers with permissions to create or update Kyverno policies can craft expressions using the `{{@}}` variable combined with a pipe and an invalid JMESPath function (e.g., `{{@ | non_existent_function }}`). This leads to a `nil` value being substituted into the policy structure. Subsequent processing by internal functions, specifically `getValueAsStringMap`, which expect string values, results in a panic due to a type assertion failure (`interface {} is nil, not string`). This crashes Kyverno worker threads in the admission controller (and can lead to full admission controller unavailability in Enforce mode) and causes continuous crashes of the reports controller pod, leading to service degradation or unavailability." ### Details The vulnerability lies in the `getValueAsStringMap` function within `pkg/engine/wildcards/wildcards.go` (specifically around ...