Filtered by vendor Linuxfoundation
Subscribe
Total
601 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-55175 | 1 Linuxfoundation | 1 Spinnaker | 2026-07-21 | N/A | 7.5 HIGH |
| Spinnaker is an open source, multi-cloud continuous delivery platform. Prior to versions 2026.1.1, 2026.0.3, 2025.4.4, and 2025.3.4 on their respective release lines, Kustomize bake operations allow unsafe YAML tag processing in rosco manifests. This can lead to remote code execution on rosco pods when performing Kustomize bakes. This issue is fixed in versions 2026.1.1, 2026.0.3, 2025.4.4, and 2025.3.4. | |||||
| CVE-2026-44795 | 1 Linuxfoundation | 1 Spinnaker | 2026-07-21 | N/A | 8.8 HIGH |
| Spinnaker is an open source, multi-cloud continuous delivery platform. Prior to 2026.1.0, 2026.0.3, 2025.4.4, and 2025.3.3, unsafe YAML processing bypasses safe deserialization when using CloudFormation deployments or CloudFoundry baking. The use of a non-safe constructor allows arbitrary loading of Java classes, leading to remote code execution. This issue is fixed in versions 2026.1.0, 2026.0.3, 2025.4.4, and 2025.3.3. | |||||
| CVE-2026-44477 | 1 Linuxfoundation | 1 Cloudnativepg | 2026-07-15 | N/A | 9.9 CRITICAL |
| CloudNativePG is a platform designed to manage PostgreSQL databases within Kubernetes environments. Prior to 1.29.1 and 1.28.3, the CloudNativePG metrics exporter opens its PostgreSQL connection as the postgres superuser via the pod-local Unix socket, then demotes the session with SET ROLE pg_monitor. SET ROLE changes only current_user; session_user remains postgres. Any SQL expression evaluated inside the scrape session can invoke RESET ROLE to recover real superuser privileges, then use COPY ... TO PROGRAM to spawn an OS-level subprocess as the postgres user inside the primary pod. The READ ONLY transaction flag does not block this; it gates writes to database state, not external processes. This vulnerability is fixed in 1.29.1 and 1.28.3. | |||||
| CVE-2026-29186 | 1 Linuxfoundation | 1 Backstage Plugin-techdocs-node | 2026-07-15 | N/A | 7.7 HIGH |
| Backstage is an open framework for building developer portals. Prior to version 1.14.3, this is a configuration bypass vulnerability that enables arbitrary code execution. The @backstage/plugin-techdocs-node package uses an allowlist to filter dangerous MkDocs configuration keys during the documentation build process. A gap in this allowlist allows attackers to craft an mkdocs.yml that causes arbitrary Python code execution, completely bypassing TechDocs' security controls. This issue has been patched in version 1.14.3. | |||||
| CVE-2026-28500 | 1 Linuxfoundation | 1 Onnx | 2026-07-15 | N/A | 8.6 HIGH |
| Open Neural Network Exchange (ONNX) is an open standard for machine learning interoperability. In versions up to and including 1.20.1, a security control bypass exists in onnx.hub.load() due to improper logic in the repository trust verification mechanism. While the function is designed to warn users when loading models from non-official sources, the use of the silent=True parameter completely suppresses all security warnings and confirmation prompts. This vulnerability transforms a standard model-loading function into a vector for Zero-Interaction Supply-Chain Attacks. When chained with file-system vulnerabilities, an attacker can silently exfiltrate sensitive files (SSH keys, cloud credentials) from the victim's machine the moment the model is loaded. As of time of publication, no known patched versions are available. | |||||
| CVE-2026-27489 | 1 Linuxfoundation | 1 Onnx | 2026-07-15 | N/A | 7.5 HIGH |
| Open Neural Network Exchange (ONNX) is an open standard for machine learning interoperability. Prior to version 1.21.0, a path traversal vulnerability via symlink allows to read arbitrary files outside model or user-provided directory. This issue has been patched in version 1.21.0. | |||||
| CVE-2026-27134 | 1 Linuxfoundation | 1 Strimzi Kafka Operator | 2026-07-15 | N/A | 8.1 HIGH |
| Strimzi provides a way to run an Apache Kafka cluster on Kubernetes or OpenShift in various deployment configurations. In versions 0.49.0 through 0.50.0, when using a custom Cluster or Clients CA with a multistage CA chain consisting of multiple CAs, Strimzi incorrectly configures the trusted certificates for mTLS authentication on the internal as well as user-configured listeners. All CAs from the CA chain will be trusted. And users with certificates signed by any of the CAs in the chain will be able to authenticate. This issue affects only users using a custom Cluster or Clients CA with a multistage CA chain consisting of multiple CAs. It does not affect users using the Strimzi-managed Cluster and Clients CAs. It also does not affect users using custom Cluster or Clients CA with only a single CA (i.e., no CA chain with multiple CAs). This issue has been fixed in version 0.50.1. To workaround this issue, instead of providing the full CA chain as the custom CA, users can provide only the single CA that should be used. | |||||
| CVE-2026-25153 | 1 Linuxfoundation | 1 Backstage | 2026-07-15 | N/A | 7.7 HIGH |
| Backstage is an open framework for building developer portals, and @backstage/plugin-techdocs-node provides common node.js functionalities for TechDocs. In versions of @backstage/plugin-techdocs-node prior to 1.13.11 and 1.14.1, when TechDocs is configured with `runIn: local`, a malicious actor who can submit or modify a repository's `mkdocs.yml` file can execute arbitrary Python code on the TechDocs build server via MkDocs hooks configuration. @backstage/plugin-techdocs-node versions 1.13.11 and 1.14.1 contain a fix. The fix introduces an allowlist of supported MkDocs configuration keys. Unsupported configuration keys (including `hooks`) are now removed from `mkdocs.yml` before running the generator, with a warning logged to indicate which keys were removed. Users of `@techdocs/cli` should also upgrade to the latest version, which includes the fixed `@backstage/plugin-techdocs-node` dependency. Some workarounds are available. Configure TechDocs with `runIn: docker` instead of `runIn: local` to provide container isolation, though it does not fully mitigate the risk. Limit who can modify `mkdocs.yml` files in repositories that TechDocs processes; only allow trusted contributors. Implement PR review requirements for changes to `mkdocs.yml` files to detect malicious `hooks` configurations before they are merged. Use MkDocs < 1.4.0 (e.g., 1.3.1) which does not support hooks. Note: This may limit access to newer MkDocs features. Building documentation in CI/CD pipelines using `@techdocs/cli` does not mitigate this vulnerability, as the CLI uses the same vulnerable `@backstage/plugin-techdocs-node` package. | |||||
| CVE-2026-24747 | 1 Linuxfoundation | 1 Pytorch | 2026-07-15 | N/A | 8.8 HIGH |
| PyTorch is a Python package that provides tensor computation. Prior to version 2.10.0, a vulnerability in PyTorch's `weights_only` unpickler allows an attacker to craft a malicious checkpoint file (`.pth`) that, when loaded with `torch.load(..., weights_only=True)`, can corrupt memory and potentially lead to arbitrary code execution. Version 2.10.0 fixes the issue. | |||||
| CVE-2026-44512 | 1 Linuxfoundation | 1 Onnx | 2026-07-13 | N/A | 5.5 MEDIUM |
| Open Neural Network Exchange (ONNX) is an open standard for machine learning interoperability. From 1.9.0 before 1.22.0, onnx.version_converter.convert_version() can dereference a null pointer in Upsample_6_7::adapt_upsample_6_7() in onnx/version_converter/adapters/upsample_6_7.h when processing an untrusted model with an Upsample node that has zero inputs, causing an unrecoverable denial of service. This issue is fixed in version 1.22.0. | |||||
| CVE-2022-41354 | 1 Linuxfoundation | 1 Argo-cd | 2026-07-09 | N/A | 4.3 MEDIUM |
| An access control issue in Argo CD v2.4.12 and below allows unauthenticated attackers to enumerate existing applications. | |||||
| CVE-2025-63396 | 1 Linuxfoundation | 1 Pytorch | 2026-07-05 | N/A | 3.3 LOW |
| An issue was discovered in PyTorch v2.5 and v2.7.1. Omission of profiler.stop() can cause torch.profiler.profile (PythonTracer) to crash or hang during finalization, leading to a Denial of Service (DoS). | |||||
| CVE-2026-53488 | 1 Linuxfoundation | 1 Containerd | 2026-07-03 | N/A | 8.8 HIGH |
| containerd is an open-source container runtime. In versions prior to 1.7.33, 2.3.2, 2.2.5, 2.1.9, and 2.0.10 the CRI plugin propagates labels from an image config (LABEL instruction in Dockerfile) to a container without validation. This may result in executing an arbitrary command on the host, via a plugin that consumes container labels for some operations. This issue has been fixed in versions 1.7.33, 2.3.2, 2.2.5, 2.1.9, and 2.0.10. | |||||
| CVE-2026-46680 | 1 Linuxfoundation | 1 Containerd | 2026-07-03 | N/A | 7.8 HIGH |
| containerd is an open-source container runtime. In versions prior to 1.7.32, 2.0.9, 2.2.4 and 2.3.1, containers launched with a numeric User directive that cannot be parsed as a 32-bit integer are incorrectly treated as a username, leading to runAsNonRoot evasion. If a crafted image provides an /etc/passwd file mapping this large numeric string to root, the container ultimately runs as root (UID 0). This allows the Kubernetes runAsNonRoot restriction to be bypassed, causing unexpected behavior for environments that require containers to run as a non-root user. This issue has been fixed in versions 1.7.32, 2.0.9, 2.2.4 and 2.3.1. | |||||
| CVE-2026-50195 | 1 Linuxfoundation | 1 Containerd | 2026-07-02 | N/A | 9.9 CRITICAL |
| containerd is an open-source container runtime. Versions prior to 2.3.2, 2.2.5 and 2.1.9 contain a vulnerability in the CRI checkpoint import process where it fails to validate the image references specified within a checkpoint image's configuration. An attacker with permissions to create pods can use a crafted checkpoint image to force containerd to pull a malicious image and assign it an arbitrary local tag, thereby poisoning the node's local image cache. Subsequently, if other pods on the same node attempt to use the poisoned tag with an IfNotPresent (or Never) pull policy, they will unknowingly execute the attacker's malicious image instead of the legitimate one. This can lead to a compromise of the affected pods, allowing the attacker to execute arbitrary code under the victim pod's identity. This issue has been fixed in versions 2.3.2, 2.2.5 and 2.1.9. | |||||
| CVE-2026-47262 | 1 Linuxfoundation | 1 Containerd | 2026-07-02 | N/A | 5.5 MEDIUM |
| containerd is an open-source container runtime. Versions prior to 1.7.33, 2.0.10, 2.1.9, 2.2.5 and 2.3.2, contain a vulnerability that allows a maliciously crafted image to cause a Denial of Service (DoS) condition. When creating a container from this image, memory exhaustion occurs, leading to an Out Of Memory (OOM) kill of the containerd process. This renders the container runtime API unavailable and can disrupt clients such as the Docker Engine or Kubernetes control-plane components. This issue has been fixed in versions 1.7.33, 2.0.10, 2.1.9, 2.2.5 and 2.3.2. | |||||
| CVE-2026-53489 | 1 Linuxfoundation | 1 Containerd | 2026-07-02 | N/A | 6.5 MEDIUM |
| containerd is an open-source container runtime. Versions prior to 2.3.2, 2.2.5 and 2.1.9 contain a bug where the CRI plugin restores container.log from a checkpoint image without validating a symlinked path. This could result in reading an arbitrary file on the host via kubectl logs. This issue has been fixed in versions 2.3.2, 2.2.5 and 2.1.9. | |||||
| CVE-2026-53492 | 1 Linuxfoundation | 1 Containerd | 2026-07-02 | N/A | 9.6 CRITICAL |
| containerd is an open-source container runtime. In Versions prior to 2.3.2, 2.2.5 and 2.1.9, the CRI implementation improperly trusts Container Device Interface (CDI) annotations found within untrusted checkpoint image metadata during container restoration. When restoring a container from a checkpoint, containerd preserves CDI-related annotations from the checkpoint archive rather than relying solely on the pod's create-time specification. This allows a user with pod creation permissions to bypass standard Kubernetes resource allocation and device plugin enforcement, injecting arbitrary CDI edits (such as device nodes and host mounts) into the restored container. Successful exploitation requires that the node has CDI enabled and contains a matching host CDI specification for the requested device; environments where CDI is disabled or lacking sensitive device specifications are not affected. This issue has been fixed in versions 2.3.2, 2.2.5 and 2.1.9. | |||||
| CVE-2026-4538 | 1 Linuxfoundation | 1 Pytorch | 2026-06-17 | 4.3 MEDIUM | 5.3 MEDIUM |
| A vulnerability was identified in PyTorch 2.10.0. The affected element is an unknown function of the component pt2 Loading Handler. The manipulation leads to deserialization. The attack can only be performed from a local environment. The exploit is publicly available and might be used. The project was informed of the problem early through a pull request but has not reacted yet. | |||||
| CVE-2026-44247 | 1 Linuxfoundation | 1 Volcano | 2026-06-17 | N/A | 6.8 MEDIUM |
| Volcano is a Kubernetes-native batch scheduling system. Prior to v1.14.2, v1.13.3, and v1.12.4, the Volcano webhook server does not enforce a size limit on incoming HTTP request bodies. Any in-cluster pod that can reach the webhook endpoint may send an arbitrarily large request body, potentially causing the webhook server to be killed by OOM. All Volcano deployments with the webhook server exposed to in-cluster traffic are affected. This vulnerability is fixed in v1.14.2, v1.13.3, and v1.12.4. | |||||