Advisoriesby Ibis## 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...
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| apple/container Product | < 1.2.0 | 1.2.0 |
Details and references
## 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)