CVE-2026-57231: 
Podman vulnerability analysis and mitigation

CVE-2026-57231 is a host environment variable disclosure vulnerability in Podman, a tool for managing OCI containers and pods. A malicious container image can embed environment variable entries with only a key and no value (e.g., HOST*), causing Podman to resolve those variables from the host session and pass them into the container — effectively exfiltrating all host environment variables when a wildcard (*) is used. The vulnerability affects Podman versions from 1.8.1 through 5.8.3 and was published on June 26, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Red Hat).

The root cause is that Podman reused the same environment variable parsing logic (envLib.ParseSlice) for both CLI-supplied --env flags and image config Env entries. The --env VAR and --env VAR* forms are intentionally supported to read values from the host environment, but this same behavior was incorrectly applied when processing image-embedded environment variables, which the OCI image spec requires to be in strict key=value format. Classified under CWE-200 (Exposure of Sensitive Information), CWE-668 (Exposure of Resource to Wrong Sphere), and CWE-914 (Improper Control of Dynamically-Identified Variables), the flaw allows a crafted image to include entries like HOST* in its config Env section, triggering Podman to inject all matching host variables into the container at runtime. The fix introduces a strict ParseImageEnvs function that rejects any image env entry lacking a = separator (GitHub Advisory, Patch Commit).

Successful exploitation allows a malicious container image to silently exfiltrate all environment variables present in the Podman host session at the time the container is launched, including credentials, API tokens, cloud provider secrets, and other sensitive configuration data. The confidentiality impact is high, as any secret stored in environment variables (a common practice in CI/CD pipelines and cloud-native deployments) is exposed to the container and potentially to the attacker who controls the image. There is no integrity or availability impact, but the credential disclosure could enable lateral movement or privilege escalation in downstream systems (GitHub Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code has been published, and there is no evidence of in-the-wild exploitation as of the time of disclosure (GitHub Advisory). The EPSS score is approximately 0.0026 (0.26%), indicating a low current probability of exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported. The NVD SSVC assessment classifies exploitation as "none" and technical impact as "partial" (Red Hat).

1. Craft a malicious image: Start from any base OCI container image and modify its image config Env section to include an entry with only a key and no value — for example, HOST* — using a tool like skopeo and jq to directly manipulate the image manifest and config JSON.
2. Inject the malformed env entry: Use jq to append the malicious entry (e.g., "HOST*") to the .config.Env array in the image config blob, then recompute the digest and update the manifest accordingly (as demonstrated in the upstream test case 030-run.bats).
3. Distribute the image: Push the crafted image to a public or private registry, or distribute it via any channel where the target user might pull and run it.
4. Wait for victim execution: When a user runs podman run <malicious-image> in a session where sensitive environment variables (e.g., AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN) are set, Podman resolves the wildcard against the host environment and injects all matching variables into the container.
5. Exfiltrate the data: The container process can read all injected environment variables via printenv or equivalent, and transmit them to an attacker-controlled endpoint via network calls, completing the credential theft (GitHub Advisory, Patch Commit).

• Image Inspection: Image config contains Env entries without a = separator (e.g., HOST, *, AWS*); detectable via podman image inspect --format '{{.Config.Env}}' <image> before running.
• Logs: Podman versions ≥ 5.8.4 will log an error such as invalid image env variable "HOST*" and refuse to start the container — absence of this error on older versions when running untrusted images is a risk indicator.
• Network: Unexpected outbound connections from a newly started container to external IPs shortly after launch, potentially transmitting environment variable data.
• Process: Container processes executing printenv, env, or equivalent commands immediately after startup without a clear operational reason.

Upgrade Podman to version 5.8.4 or 6.0.0, which enforce strict key=value parsing for image-embedded environment variables and reject malformed entries (GitHub Advisory). As an immediate workaround, inspect any image before running it using podman image inspect --format '{{.Config.Env}}' <image> and verify that all entries contain a = sign with a non-empty key; do not run images from untrusted sources. Additionally, avoid storing sensitive credentials in shell environment variables when running Podman — use Podman secrets or a dedicated secrets manager instead (Red Hat Bugzilla).

The vulnerability was discussed on Reddit's r/podman community in the context of the Podman 6.0.0 release, with users noting the upgrade path from 5.x. The Linux Handbook newsletter and tech media outlets such as TechTimes covered the Podman 6.0 release and its security improvements, including this fix. A Mastodon post on infosec.exchange also noted the disclosure. Overall community sentiment appears measured, with no widespread alarm given the absence of known exploitation (Reddit, TechTimes).