#kubernetes

A vulnerability exists in the NodeRestriction admission controller where nodes can bypass dynamic resource allocation authorization checks. When the DynamicResourceAllocation feature gate is enabled, the controller properly validates resource claim statuses during pod status updates but fails to perform equivalent validation during pod creation. This allows a compromised node to create mirror pods that access unauthorized dynamic resources, potentially leading to privilege escalation.

Making sure your Kubernetes environment is secure and compliant is a critical, ongoing challenge, especially for enterprise workloads in the hybrid cloud. To help you meet security requirements with greater confidence and efficiency, we’ve just rolled out key updates to Red Hat Advanced Cluster Security for Kubernetes Cloud Service. This latest release helps significantly strengthen your security posture with newly added industry-standard certifications, including ISO 27001 and PCI DSS 4.0, and deeper integration with key AWS services. These enhancements are designed to streamline compliance

Grab a large sweet tea or a cup of coffee and read the 2024 Product Security Risk Report from Red Hat Product Security. As someone striving to stay informed about the open source ecosystem and its security challenges, I found this year's report noticeably longer, but the depth and detail didn’t disappoint. In fact, one notable addition to this year’s report is the discussion of AI. The numbers game: up, up, and...wait, what?First, let’s break down the raw numbers. Red Hat Security Advisories (RHSA) hit a new peak in 2024, clocking in at 2975. There has been a steady increase over the pa

Many organizations face challenges in creating value from data while maintaining strict regulatory standards set for handling sensitive data. For these organizations, handling large, complex data sets while maintaining efficiency, security and scalability becomes paramount to their deployment. The collaboration between Red Hat and Cloudera offers customers a solution that helps organizations to manage the complete data lifecycle, putting data to work faster and reducing time to value. With Cloudera Private Cloud on Red Hat OpenShift, organizations get aggregated and visualized data that can he

### Impact This vulnerability allows an attacker to perform arbitrary actions on behalf of the victim via the API, such as creating, modifying, and deleting Kubernetes resources. Due to the improper filtering of URL protocols in the repository page, an attacker can achieve cross-site scripting with permission to edit the repository. In `ui/src/app/shared/components/urls.ts`, the following code exists to parse the repository URL. https://github.com/argoproj/argo-cd/blob/0ae5882d5ae9fe88efc51f65ca8543fb8c3a0aa1/ui/src/app/shared/components/urls.ts#L14-L26 Since this code doesn't validate the protocol of repository URLs, it's possible to inject `javascript:` URLs here. https://github.com/argoproj/argo-cd/blob/0ae5882d5ae9fe88efc51f65ca8543fb8c3a0aa1/ui/src/app/shared/components/repo.tsx#L5-L7 As the return value of this function is used in the `href` attribute of the `a` tag, it's possible to achieve cross-site scripting by using `javascript:` URLs. Browsers may return the proper ho...

### Impact When the Contrast initializer is configured with a `CONTRAST_LOG_LEVEL` of `info` or `debug`, the workload secret is logged to `stderr` and written to Kubernetes logs. Since `info` is the default setting, this affects all Contrast installations that don't customize their initializers' log level. The following audiences are **intended** to have access to workload secrets (see https://docs.edgeless.systems/contrast/1.7/architecture/secrets#workload-secrets): * Contrast Coordinator (can derive all workload secrets) * Contrast Initializer (obtains only the secret configured in the manifest) * Seedshare owner (can derive all workload secrets) * Workload owner (can update manifests to obtain secrets) This vulnerability allows the following parties **unintended access** to workload secrets issued by a Coordinator: * Kubernetes users with `get` or `list` permission on `pods/logs`. * Others with read access to the Kubernetes log storage (most notably, the cloud provider). Thi...

May Linux Patch Wednesday. This time: 1091 vulnerabilities. Of those, 716 are in the Linux Kernel. 🤯 5 vulnerabilities are exploited in the wild: 🔻 RCE – PHP CSS Parser (CVE-2020-13756). In AttackerKB, an exploit exists.🔻 DoS – Apache ActiveMQ (CVE-2025-27533). In AttackerKB, an exploit exists.🔻 SFB – Chromium (CVE-2025-4664). In CISA KEV.🔻 PathTrav – […]

### Summary When using Keycloak as an oidc provider, the clientsecret gets printed into the container stdout logs for an example at container startup. ### Details Container Image (15.04.2025): ghcr.io/project-zot/zot-linux-amd64:latest Here is an example how the configuration can look which causes the above stated problem: ` http: address: "0.0.0.0" port: 5000 externalUrl: "https://zot.example.com" auth: { failDelay: 1, openid: { providers: { oidc: { name: "Keycloak", clientid: "zot-client-id", clientsecret: fsdfkmmiwljasdklfsjaskldjfkljewijrf234i52k3j45l, keypath: "", issuer: "https://keycloak.example.com/realms/example", scopes: ["openid"] } } } } ` ### PoC Set up a blank new zot k8s deployment with the code snippet above. ### Impact exposure of secrets, on configuring a oidc provider

# Impact A bug was found in the containerd's CRI implementation where containerd doesn't put usernamespaced containers under the Kubernetes' cgroup hierarchy, therefore some Kubernetes limits are not honored. This may cause a denial of service of the Kubernetes node. # Patches This bug has been fixed in containerd 2.0.5+ and 2.1.0+. Users should update to these versions to resolve the issue. # Workarounds Disable usernamespaced pods in Kubernetes temporarily. # Credits The containerd project would like to thank Rodrigo Campos Catelin and Piotr Rogowski for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md). # For more information If you have any questions or comments about this advisory: * Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose) * Email us at [email protected] To report a security issue in containerd: * [Report a new vulnerabi...

To understand Red Hat OpenShift's journey to quantum-safe cryptography, it helps to look at the current and planned post-quantum cryptography support in Red Hat Enterprise Linux (RHEL). This is because OpenShift includes Red Hat Enterprise Linux CoreOS (RHCOS), which provides several important cryptographic libraries. Bringing post-quantum cryptography to OpenShift is not a one-line configuration, of course. It's an architectural transition.There are three main areas of focus when considering post-quantum cryptography for OpenShift: RHCOS kernelsOpenShift Core userspaceGo versions used by the