Vantage6 is a widely used open-source infrastructure designed for privacy-preserving data analysis. Hospitals, research centers, and other organizations often use Vantage6 to collaborate without directly sharing raw data. Instead, insights are generated using distributed computation. However, in early 2024, a critical vulnerability—CVE-2024-32969—was found that could undermine the trust boundaries between organizations collaborating through Vantage6.

In this long read, we'll take a close look at how CVE-2024-32969 worked, show some simplified code snippets to illustrate the vulnerability, and discuss both its impact and the patch that fixed it. Everything here is explained simply, for clarity—no PhDs in cryptography needed.

What Is Vantage6, and How Do Collaborations Work?

Vantage6 lets multiple organizations work together on computations over data, all while keeping that data private. To make this happen, someone sets up a "collaboration" (think of it as a project) and adds organizations to it. Each organization can then register users who are allowed to access the system and submit or manage analysis jobs (called "tasks").

Admins who manage collaborations are trusted to some extent, but there are supposed to be boundaries. One admin shouldn't be able to access data/results from another collaboration they're not involved in.

The Core Vulnerability

CVE-2024-32969 boils down to permission leakage: a collaboration administrator can add extra organizations to their collaboration, and through this process, extend their influence more than intended.

For example

- When an admin adds a new organization to their collaboration, they can create new user accounts for that organization.

Since the admin sets the account passwords, they can login as those users.

- If this organization is involved in *other* collaborations, those same credentials work there too—potentially giving unintended access to sensitive data or results hosted by those other collaborations.

This means, in practice, if you control Collaboration A but Organization X is also involved in Collaboration B, you can register a user for Organization X, set the password, and then access data/results in Collaboration B as if you were Organization X's user.

Simple Code Example

Here's a stripped-down, illustrative snippet showing why this is a problem.

# A collaboration admin adds Organization X to their collaboration
collab.add_organization(org_x)

# The admin sets up a new user for Organization X
org_x.add_user(username='malicious_user', password='supersecret')

# 'malicious_user' logs in - but now has rights in *all* collaborations Organization X is a part of
session = login(username='malicious_user', password='supersecret')

# Access results in a different collaboration (B), which Organization X also joined
results = session.get_task_results(collaboration='CollaborationB')
print(results)  # Data meant for a different group, now exposed

In this example, the initial intent is to allow Organization X to have users in Collaboration A, but any user created is valid *for all collaborations* that Organization X is involved in. The admin of Collaboration A gets a backdoor into Collaboration B.

Why Is This a Problem?

In most situations, collaboration admins are relatively trusted. But Vantage6 is used in scenarios where multiple institutions might trust each other only partially, and the privacy of shared results is critical.

Sensitive analysis results might be exposed, risking privacy breaches

This can seriously undermine the privacy guarantees Vantage6 is designed to provide, particularly in research or healthcare contexts.

To summarize the exploit process

1. Become a Collaboration Admin: The attacker must have admin rights in one collaboration, say, Collaboration A.
2. Add an Existing Organization: The attacker adds Organization X (which is also in Collaboration B) to Collaboration A.
3. Create a User Account: The attacker creates a user for Organization X, choosing username and password.

Log In as Organization X's User: The attacker logs in with those credentials.

5. Switch Context: The attacker now has access to any other collaboration where Organization X is a member, such as Collaboration B.

Read Task Results: They retrieve analysis results or data, breaking the intended boundaries.

Key Point: The user's context isn't limited to the original collaboration; it's organization-wide.

The attacker must also have the authority to add organizations and create users

- The scope is limited, but still serious, especially if collaborations host data that is expected to be private from each other

The Patch: How Was It Fixed?

The vulnerability was patched in Vantage6 version 4.5.rc3.

Restricting the ability for collaboration admins to add organizations they do not control

- Adjusting user creation workflows so that admins can't set passwords for users in organizations outside their own scope—or that user rights are strictly scoped to the relevant collaboration

If you're running Vantage6, update immediately to version 4.5.rc3 or newer.

References

- Vantage6 GitHub repository
- Vantage6 - Release v4.5.rc3 notes
- CVE-2024-32969 at NVD (National Vulnerability Database)

Final Thoughts

While CVE-2024-32969 doesn't give remote attackers total access, it highlights the subtle ways trust boundaries can break down in federated, privacy-focused infrastructures. Even with mostly trusted admins on board, enforcing *clear* boundaries at the software level is crucial.

If you use Vantage6, verify your version, check your admin user permissions, and update now. For collaborative systems everywhere, this CVE is a reminder: trust, but verify—and architect for strict boundary enforcement.

Stay safe, and keep your federated analysis private!


*This post is an exclusive, simplified overview of CVE-2024-32969, based on public sources and the author's security research.*

Timeline

Published on: 05/23/2024 09:15:09 UTC
Last modified on: 06/04/2024 17:50:23 UTC