CVE-2026-57231: Podman Malformed Image Host Environment Variable Leak

Podman is an open-source, daemonless container engine designed to manage Open Container Initiative (OCI) containers and pods on Linux, macOS, and Windows systems. When initiating container lifecycles via the command-line interface or automated configuration deployment (such as Kubernetes YAML configurations via the Kube Play engine), Podman constructs a container specification. This configuration defines the operating boundaries, storage constraints, network architecture, and environmental attributes that direct container behavior.

The vulnerability is classified under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) and CWE-668 (Exposure of Resource to Wrong Sphere). The security flaw originates from a structural mismatch between CLI environment parser functions and OCI image metadata config parser logic. When a container image config contains environment keys lacking explicit values, Podman fails to isolate the runtime configuration, collapsing the boundary between host environmental values and local guest layers.

In standard deployments, administrators and workflows often configure environment variables within administrative host sessions to pass secrets, session tokens, or API keys safely. By design, the container environment should be strictly declared during run-time configurations, preserving host boundaries. CVE-2026-57231 compromises this boundary, turning container launch and deployment operations into potential channels for system-level credential theft.

To understand the root cause, it is necessary to examine how Podman parses environment variables. During a standard podman run invocation, users specify the -e or --env flag to pass dynamic runtime parameters. Users may define the variable literally (e.g., --env MYVAR=value), reference an existing environment variable on the host (e.g., --env MYVAR), or pass general wildcard identifiers (e.g., --env "*" or --env "AWS_*") to instruct Podman to pull all matching environment variables from the current execution shell.

This runtime variable mapping is executed by the utility routine envLib.ParseSlice. Because CLI execution assumes the terminal operator maintains authority over the current host session, envLib.ParseSlice implements a permissive parser. If a slice entry does not contain an equals character (=), the parser assumes the input specifies a variable lookup instruction. It queries the shell context, retrieves the respective value, and appends the fully constructed key-value pair to the target specification.

The security vulnerability manifests because Podman engineers reused this exact parser (envLib.ParseSlice) to process the static container image configuration metadata (inspectData.Config.Env) defined during image build pipelines. Because OCI image specifications require all environment variables to maintain a strict key=value format, Podman assumed that image-defined environment slices would always contain an equals sign. However, an attacker can bypass standard container build constraints and manually construct a malformed configuration block containing standalone strings or wildcard characters. When processed, the permissive parser translates these elements into requests to import the host's actual environment variables, directly leaking host credentials to the spawned container application.

The vulnerability was addressed in the Podman source tree by developer Paul Holzinger. The fix targets the unsafe reuse of envLib.ParseSlice within the spec generator components. The primary modification replaces the permissive library parsing function with a strict, validation-oriented routine named ParseImageEnvs.

The code block below demonstrates the newly introduced validator inside pkg/specgen/generate/container.go:

func ParseImageEnvs(imageEnvs []string) (map[string]string, error) {
	envs := make(map[string]string, len(imageEnvs))
	for _, env := range imageEnvs {
		key, val, hasValue := strings.Cut(env, "=")
		if !hasValue || key == "" {
			return nil, fmt.Errorf("invalid image env variable %q", env)
		}
		envs[key] = val
	}
	return envs, nil
}

This validator enforces strict conformancy using the standard library's strings.Cut function. If hasValue evaluates to false (meaning there is no = separator), or if the key length is empty, the logic throws a validation error and fails closed, entirely preventing the container from initializing with contaminated boundaries.

In CompleteSpec within the same file, the vulnerable implementation was modified to use this new function:

-	envs, err = envLib.ParseSlice(inspectData.Config.Env)
+	envs, err := ParseImageEnvs(inspectData.Config.Env)
 	if err != nil {
-		return nil, fmt.Errorf("env fields from image failed to parse: %w", err)
+		return nil, err
 	}

Additionally, the parser for Kubernetes manifest translation within pkg/specgen/generate/kube/kube.go was updated to call this secure routine. This ensures that any pod deployment via podman kube play enforces the same safety checks on standard and wildcard configuration keys.

Exploiting this flaw does not require complex binary payload development or local privileges on the host system. The attack relies entirely on an attacker's ability to host a malformed image on an accessible image registry and wait for a target user to deploy or run the image. The exploit procedure utilizes standard container manipulation utilities to patch OCI image configuration blocks.

An attacker begins by identifying or pulling a benign baseline image, such as standard Debian or Alpine images. Because traditional container builders like Buildah or Dockerfiles enforce a strict format on ENV instructions, the attacker must bypass standard compilation steps. The manifest configuration must be directly manipulated at the storage level. Using standard copy utilities like skopeo, the attacker unpacks the target image to a local directory:

mkdir /tmp/exploit-prep && skopeo copy containers-storage:alpine:latest dir:/tmp/exploit-prep

The configuration JSON is located by identifying the digest value listed in manifest.json. The attacker then manipulates the array stored under .config.Env within the configuration block, appending key-only strings or wildcard characters like "*":

"Env": [
    "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
    "*"
]

The attacker recalculates the SHA256 checksum, updates the file size references in manifest.json, repackages the image block, and pushes the malformed image to a registry. When a victim pulls this image and executes it using standard commands (podman run --rm registry.local/malformed-image:1.0 printenv), Podman parses the * symbol within Config.Env. Under affected versions, Podman imports all environmental variables from the host's terminal context, making credentials immediately accessible to the container processes.

The security implications of CVE-2026-57231 are severe for environments where containers are spun up automatically or in automated workflows. Because the CVSS vector is rated CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5 Base Score), the exploit pathway demands zero specialized configuration, user interaction, or authorization. The threat is most pronounced in continuous integration and continuous deployment (CI/CD) orchestrations.

In typical CI/CD pipelines, runner jobs execute with highly privileged environmental variables injected at startup. These variables contain cloud platform credentials (such as AWS keys, GCP service tokens, or Azure client secrets), database connection strings, SSH keys, and artifact registry credentials. If a pipeline retrieves a public or compromised private base image containing the malformed environment configuration, the malicious container can exfiltrate all system secrets to an external command-and-control server immediately after launch.

The vulnerability is particularly stealthy because it leaves minimal trace in traditional runtime threat monitoring systems. Because Podman populates the environment fields natively during runtime spec construction, the container process appears to be executing with standard parameters. The transfer of variables is handled by the container engine itself, evading static detection rules that trigger on unusual run-time options like --env.

The primary remediation pathway requires updating Podman installations to the patched releases. Deployments operating on the 5.x lifecycle branch must be updated to version 5.8.4 or above. Environments utilizing major version 6 must be updated to version 6.0.0 or above. These patched releases cleanly enforce validation of the image environment structures.

For environments unable to immediately perform system packages upgrades, administrators must implement network-level and registry-level mitigation strategies. These strategies include restricting container pulls to local, verified registries where security pipelines inspect manifest integrity, and utilizing custom OPA (Open Policy Agent) validation rules to block deployments of unapproved images.

To identify potentially vulnerable or malformed images present in local storage, security administrators can run programmatic script routines. The following shell command leverages podman image inspect to audit local image configuration metadata. It extracts and inspects the environments array, signaling any entries that fail to include the mandatory = character:

podman image inspect --format '{{range .Config.Env}}{{println .}}{{end}}' <image_name> | grep -v "="

If the command yields any string output, the inspected image contains a structural format violation and must be flagged as potentially malicious or malformed.