GHSA-X9F6-9RVM-MMRG: Improper Access Control and Volume Mount Isolation Bypass in vantage6 Node

The vantage6 platform is designed to facilitate secure, privacy-preserving federated learning across multiple distinct organizations. Within this framework, individual nodes download task configurations, retrieve algorithms packaged as Docker images, and execute them locally. The node is responsible for managing container lifecycles, mounting datasets, and handling input and output files.

This vulnerability, designated as GHSA-X9F6-9RVM-MMRG, is an improper access control issue in the node component. When multiple tasks execute concurrently or sequentially, the node fails to enforce strict logical and physical directory isolation boundaries between container workspaces. This structural deficiency allows a malicious container running on the node to access data belonging to other algorithms.

The root cause of GHSA-X9F6-9RVM-MMRG lies in how the vantage6 node handles temporary directory allocation and volume mounts for Docker-based task executions. When a task is initialized, the node allocates physical folders on the host to store the input JSON payloads and output result files.

Instead of mounting only the explicit subfolder dedicated to a single active container, the system's mounting logic allows container processes to traverse up or guess sibling directories. Predictive naming conventions, such as using sequential indices or static parent folders under /tmp/vantage6/, facilitate this unauthorized traversal. Because the containerized processes run with permissions that can read the host-mounted shares, a container can systematically locate files of other workspaces.

The following diagram illustrates the flow of volume mounts where improper isolation allows cross-container access. When parent directories are exposed to the container environment, directory traversal allows adjacent containers to read and write arbitrary files.

To prevent directory traversal, volume mounting must restrict the scope of accessible folders. The vulnerable implementation exposes a parent path structure that container processes can exploit if they have standard read and write system privileges.

Exploiting this vulnerability does not require administrative privileges on the target node. An attacker must have the ability to submit a federated learning task to the central vantage6 server, specifying a custom Docker image under their control.

Once the target node pulls and executes the malicious container, the containerized program initiates a directory sweeping routine. It attempts to traverse back via parent directories or directly probes common host mount structures. Since the node fails to restrict access to adjacent directories, the attacker's container can extract sensitive inputs or modify output files to compromise the integrity of the federated calculation.

The primary security impact of GHSA-X9F6-9RVM-MMRG is the complete breakdown of the federated learning trust model. In a federated setup, data providers assume that their local data and individual task outputs remain confidential and untampered with.

By accessing other algorithm files, an attacker can perform data harvesting or data poisoning. Modifying input files allows attackers to manipulate model parameters, while reading output files can expose sensitive intermediate statistical summaries. This compromises both data integrity and confidentiality across the entire federated network.

At the time of disclosure, no security patch was backported to the 3.x release line of vantage6. Security roadmap tracking indicates that comprehensive directory isolation and volume mount hardening were scheduled for the major 5.0.x release.

To mitigate this risk immediately, administrators must configure algorithm whitelisting on all active nodes. This prevents the execution of arbitrary, untrusted container images. The node configuration should explicitly define the allowed algorithm registry and image tags, rejecting any task that specifies unverified code.