Skip to content
AppleGHSA-g57j-434g-5xj2

## 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...

GitHub advisory

Affected versions

PackageAffectedFixed in
apple/container
Product
< 1.2.01.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

Critical advisories by email

Wednesdays: the week’s critical and high advisories in the AI and data stack, with the fixed versions. Only in weeks that have some.

Double opt-in. Unsubscribe any time.