## Impact A malicious builder peer may be able to use the `json` response mode...
LowPublished Aug 12, 2026
## Impact A malicious builder peer may be able to use the `json` response mode of the builder `Walk` RPC to learn the canonical, resolved host filesystem path that a build-context symlink points to, even when that target lies outside the build context, confirming that the symlink target exists. ## Details The [`container-builder-shim` Swift project](https://github.com/apple/container-builder-shim) that creates the standard builder image for `container build` does not yet issue `json` mode `Walk` requests. The victim must configure `container` to use a non-standard builder that intentionally makes these calls. `BuildFSSync.walk()`'s `json` response mode builds a `FileInfo` record for every context path a `Walk` request resolves to, including entries matched via glob pattern expansion. When an entry is a symlink, `FileInfo`'s initializer resolves the symlink's target with `resolvingSymlinksInPath()` and then checks whether the resolved path is lexically inside the context root. If it is not, it reports the resolved path as-is (`target.cleanPath`) rather than treating it as out of bounds — the same lexical-containment-without-resolving-symlinks root cause as GHSA-2v2q-4q35-h585, a...
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| apple/container Product | < 1.2.0 | 1.2.0 |
Details and references
## Impact A malicious builder peer may be able to use the `json` response mode of the builder `Walk` RPC to learn the canonical, resolved host filesystem path that a build-context symlink points to, even when that target lies outside the build context, confirming that the symlink target exists. ## Details The [`container-builder-shim` Swift project](https://github.com/apple/container-builder-shim) that creates the standard builder image for `container build` does not yet issue `json` mode `Walk` requests. The victim must configure `container` to use a non-standard builder that intentionally makes these calls. `BuildFSSync.walk()`'s `json` response mode builds a `FileInfo` record for every context path a `Walk` request resolves to, including entries matched via glob pattern expansion. When an entry is a symlink, `FileInfo`'s initializer resolves the symlink's target with `resolvingSymlinksInPath()` and then checks whether the resolved path is lexically inside the context root. If it is not, it reports the resolved path as-is (`target.cleanPath`) rather than treating it as out of bounds — the same lexical-containment-without-resolving-symlinks root cause as GHSA-2v2q-4q35-h585, applied to a metadata field instead of file content. Because the reported value is the *resolved* (canonicalized) path rather than the literal string on disk, it can disclose more than what the context's author necessarily already knows — for example, resolving a relative symlink to its absolute location, or resolving through an intermediate symlink chain — which can confirm the existence and exact location of a file the requester didn't otherwise have visibility into. ## Affected code `BuildFSSync.FileInfo`'s initializer, in `Sources/ContainerBuild/BuildFSSync.swift`, used only by `walk()`'s `json` response mode. Present since `Sources/ContainerBuild` was introduced (initial commit, 2025-06-03). **Not affected:** - `BuildFSSync.read()` and `BuildFSSync.info()` are a related but distinct finding, tracked separately in [GHSA-2v2q-4q35-h585](https://github.com/apple/container/security/advisories/GHSA-2v2q-4q35-h585). - `Globber`, which resolves glob patterns for `walk()` (both response modes), does not descend through symlinked directories to reach files nested behind them — the `FileManager.contentsOfDirectory(at:)` and `FileManager.enumerate(at:)` calls that it uses do not follow directory symlink., on the current implementation. ## Mitigations 1. Upgrade to `container` 1.2.0 or later. 2. Only build with the default, unmodified builder — do not set a custom `build.image` in `container`'s configuration unless you trust its publisher as much as you trust the `container` project itself, since a stock builder never requests the `json` walk mode this finding depends on. 3. As defense in depth against this and related build-context symlink-containment issues, avoid running `container build` against build contexts you did not author yourself or have not reviewed. Restricting which paths a Dockerfile's `COPY`/`ADD` instructions reference does not mitigate this: the disclosure happens while the host walks the context to answer a `Walk` request, before any Dockerfile instruction is evaluated. ## Verifying whether you are affected This does not leave a durable artifact to scan for after the fact, since disclosure happens in-memory during a build rather than writing a marker to the host filesystem. To check whether a specific build context contains the symlink shape this finding depends on, inspect it without building: ``` find <context-dir> -type l | while read -r l; do case "$(readlink -f "$l")" in "$(readlink -f <context-dir>)"/*) ;; *) echo "escapes context: $l -> $(readlink -f "$l")";; esac done ``` Any symlink reported by this command would have had its resolved target path disclosed on a host running an affected `container` to a builder peer that requested `json`-mode `Walk` responses. ## R
- Severity from
- GitHub (reviewed advisory)
More Apple advisories
All Apple| Date | Advisory | Severity | Fixed in |
|---|---|---|---|
| Aug 17 | Apple Safari: memory corruption | Medium4.3 | 26.5+2 more |
| Aug 12 | Build filesystem sync discloses host files outside the build context via symlinks | Medium | 1.2.0 |
| Aug 12 | TCP port forwarder buffers unbounded pre-connect data from published container ports | Medium | 1.2.0 |
| Aug 12 | HTTP Request Smuggling due to mishandled Transfer-Encoding parsing | Medium6.5 | 0.42.65 |
| Aug 11 | ## Impact The author or publisher of any container image | Medium | 0.40.0+1 more |
| Aug 11 | ## Impact An attacker who publishes a malicious image with bare-name... | Medium | 1.2.0 |