Description

Contrast, Edgeless Systems' runtime for confidential containers on Kubernetes, is affected in versions up to and including 1.9.0. The VOLUME directive in a Dockerfile (config.volumes in the OCI image configuration) is only a hint and is not handled specially by Kubernetes, but containerd adds a mount point for it when Kubernetes sets none, requiring the runtime to be able to push arbitrary data to the Kata agent. As a result, on bare-metal Contrast deployments (AKS deployments are not affected) that run an image declaring at least one VOLUME for which no Kubernetes mount exists at that path, the untrusted host can write arbitrary file trees below that mount point inside the confidential container, compromising the integrity of a directory that is typically important to the application's core functionality. Version 1.9.1 fixes the issue by disallowing this configuration in `contrast generate`.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.5",
  "pubDate": "2026-09-27T02:17:16.393Z",
  "pubdate": "2026-09-27T02:17:16.393Z",
  "executiveSummary": "Contrast, the confidential container runtime by Edgeless Systems, is vulnerable to an arbitrary file injection flaw affecting bare-metal Kubernetes deployments up to version 1.9.0.\nThe vulnerability stems from improper handling of OCI image VOLUME directives when they lack corresponding Kubernetes mount configurations.\nOn affected bare-metal systems, an untrusted host can inject arbitrary file structures into the container's filesystem at the designated VOLUME path.\nThis bypasses container integrity guarantees, allowing the host to modify critical application files or configuration data within the confidential container environment.\nAKS deployments are explicitly noted as unaffected.\nSuccessful exploitation requires the deployment of an image containing a VOLUME directive without an explicit Kubernetes volume mount at the same path.\nThe impact involves a complete loss of file integrity within the affected volume, potentially leading to privilege escalation, data manipulation, or arbitrary code execution within the confidential runtime boundary.",
  "technicalDetails": "The vulnerability exists within the Contrast runtime's handling of OCI image configurations, specifically the VOLUME directive. In Kubernetes, the VOLUME instruction in a Dockerfile acts only as a metadata hint; it does not inherently create a mount point. However, the containerd runtime environment, when integrated with Kubernetes, defaults to adding a mount point for these paths if no explicit Kubernetes mount is defined.\nIn the context of confidential containers, this behavior creates an inconsistency between the expected security boundary and the actual filesystem implementation. On bare-metal deployments, the Contrast runtime relies on the Kata agent to manage these mounts. Because the runtime is configured to allow these system-injected mounts, it becomes capable of pushing arbitrary data into the container's internal filesystem via the host-to-guest communication channel.\nThe attack flow proceeds as follows: 1) An attacker identifies an image being deployed that specifies one or more VOLUME directives in its OCI configuration. 2) The attacker ensures that no corresponding Kubernetes 'volumeMounts' are defined in the pod specification for those specific paths. 3) Upon container initialization, containerd facilitates a mount point for the volume. 4) The untrusted host, leveraging the host-side access provided by the bare-metal configuration, writes arbitrary files or directory structures directly into the directory path associated with the VOLUME directive.\nBecause these files are written into the confidential container's runtime environment, the containerized application treats them as trusted local data. This allows for the manipulation of configuration files, execution of malicious scripts, or the modification of application binaries, effectively compromising the integrity of the confidential container. This vulnerability bypasses the intended memory and storage encryption protections because the host is acting as a legitimate participant in the initial filesystem construction process. The root cause is the runtime's failure to validate or restrict these system-injected mounts in the absence of explicit Kubernetes definitions, effectively granting the host filesystem-level read/write access to sensitive container internal paths."
}