Tenant users may supply Dockerfile-like steps or image instructions when building execution environments for AI workloads. If the builder runs privileged and only switches filesystem roots, a build command can retain visibility into host process or mount namespaces rather than receiving complete VM isolation. The advisory describes a specific worker…
Inspect the ClaimsCase · DiggingBeagle record
Beta9 image build chroot could expose a privileged worker namespace to tenant code
A reported tenant image-building path relies on privileged chroot and may leak worker-host namespaces to build commands.
Scope
This is an unreviewed advisory with a proof in an identified build path, not established field exploitation.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade D
- AI role
- AGAINST AI
Basis and provenance
The pinned Claim and its primary disclosure support the described controlled result, but do not establish a population-wide rate or calibrated impact. The only available supporting evidence is the reporter's or advisory author's own account; independent reproduction has not been shown. Impact remains unbanded because no calibrated impact rubric for this particular evidence is established.
Assessed Nov 2, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-2026-NOV02-BETA9-PRIVILEGED-BUILD-CHROOT-A · GitHub Advisory GHSA-xvhg-75x6-gj86, Beta9 build worker isolation
At a glance
Container root changes and privileged execution cannot substitute for isolation of tenant-controlled build steps.
Read the implicationsThis is an unreviewed advisory with a proof in an identified build path, not established field exploitation. The advisory does not establish the effective production worker permissions or which hosting configurations can reach the identified build path.
Limits and uncertaintyFull account
Tenant users may supply Dockerfile-like steps or image instructions when building execution environments for AI workloads. If the builder runs privileged and only switches filesystem roots, a build command can retain visibility into host process or mount namespaces rather than receiving complete VM isolation. The advisory describes a specific worker boundary and its reproduction; it does not prove all deployments are vulnerable or that any external tenant changed production host binaries.
Changing the apparent filesystem root with chroot does not itself create isolated process, mount or user namespaces. The trust question is whether a tenant-controlled build instruction can still observe or affect the privileged worker's host context after that root change. The advisory identifies a specific image-building execution path, but the available evidence does not establish a compromise of a production Beta9 tenant or a universal escape across configurations. The correct test compares effective process capabilities, namespace identifiers and mounted objects before and after entering the tenant build context.
Mechanism and trust boundary
- 01
Tenant supplies image build commands
The service accepts user-defined build actions for an agent environment.
Boundary: Tenant content into hosted build service
- 02
Privileged worker uses chroot
The build runs with host-level namespaces not fully isolated from the tenant command.
Boundary: Filesystem root change into assumed sandbox
- 03
Build code reaches worker resources
Reported tests observe host-worker objects beyond intended image workspace.
Boundary: Tenant build step into privileged build host
Claims & evidence
CLM-2026-NOV02-BETA9-PRIVILEGED-BUILD-CHROOT-AGHSA-xvhg-75x6-gj86 describes Beta9 tenant image build steps running as commands in a privileged Buildah worker with chroot isolation, with a proof of access to worker-level files or namespaces.supported
Basis: reported finding
- supportsGitHub Advisory GHSA-xvhg-75x6-gj86, Beta9 build worker isolationprimary disclosure
Advisory, affected image build process and privileged chroot proof
Implications
Container root changes and privileged execution cannot substitute for isolation of tenant-controlled build steps.
Controls and mitigations
- Use unprivileged isolated build workers or microVMs, deny host namespace access and audit exact build process capabilities.
- Instrument the worker's namespace and capability set during a harmless tenant build; require a separate unprivileged user namespace or VM boundary for submitted build commands.
Unknowns and contradictions
- This is an unreviewed advisory with a proof in an identified build path, not established field exploitation.
- The advisory does not establish the effective production worker permissions or which hosting configurations can reach the identified build path.
Sources and citation
Material revision history
- Nov 2, 2026 · Canonical change recorded · new in release · revision 214