## Impact An attacker who publishes a malicious image with bare-name...

## Impact An attacker who publishes a malicious image with bare-name `Config.Env` entries matching well-known secret variables can have the host's secret values silently copied into the container, where attacker-controlled code can read and exfiltrate them. This requires the launching shell or CI job to have the targeted secret(s) exported. `container exec` is not affected. ## Details The `container` CLI resolves "bare" environment-variable names (no `=`) by inheriting their value from the launching process's own environment — intended for the interactive `--env VAR` flag, but applied the same way to the image's `Config.Env`, which is attacker-controlled metadata pulled from a registry. Bare names are already out of spec (the OCI image spec mandates `KEY=VALUE`), and since the resolution happens in the CLI client process, "the launching process's environment" is the user's shell or CI runner — not the container. ## Mitigations 1. Upgrade to `container` 1.2.0 or later, which restricts bare-name host inheritance to CLI `--env`/`--env-file` inputs: image-supplied `Config.Env` entries must be `KEY=VALUE`, and bare names are dropped instead of being resolved from the host. 2. If you can't upgrade immediately, avoid running untrusted images from a shell or CI job that has secrets exported in its environment; run untrusted images from a minimal environment instead. 3. Scrub or unset sensitive variables (cloud keys, registry/CI tokens, API keys) from the calling shell/job before invoking `container run`/`create` on an image you don't fully trust. A restrictive umask, running as a non-root user, or sandboxing the container's filesystem does not mitigate this: the leak happens in the CLI client process before the container starts. ## Verifying whether you are affected Inspect an image's `Config.Env` for bare (no `=`) entries before running it: ```bash container image inspect <image> --format '{{json .Config.Env}}' ``` Any entry in the returned list that does not contain `=` would have been resolved from your shell's environment on affected versions. If you've run such an image on an affected version with matching secrets exported, rotate those secrets — this check confirms the image was capable of triggering the leak, not whether the container acted on it. ## References - Fix: [apple/container#2027](https://github.com/apple/container/pull/2027) (merged as `48145ac`, released in `1.2.0`)

Severity from

GitHub (reviewed advisory)

• github.com/apple/container/security/advisories/GHSA-xwgf-4rc5-p4m4
• github.com/apple/container