Summary

• Context: The get_sandbox_for_repository Temporal activity provisions sandbox environments for task runs, including fetching and applying user-defined environment variables from SandboxEnvironment records.
• Bug: The "agent hardening" refactor (commit 48e7429e29) replaced ctx.get_sandbox_environment() with a direct database query that bypasses the private environment access control check.
• Actual vs. expected: Any team member can access another user's private sandbox environment secrets; private environments should only be accessible to their creator.
• Impact: A malicious team member can exfiltrate secrets stored in private sandbox environments (API keys, tokens) by creating a task run that references the victim's private environment ID.

Code with Bug

# get_sandbox_for_repository.py lines 112-125
sandbox_environment = None
if ctx.sandbox_environment_id:
    sandbox_environment = SandboxEnvironment.objects.filter(
        id=ctx.sandbox_environment_id, team=task.team
    ).first()  # <-- BUG 🔴 No privacy check; private envs become accessible to any team member
    if sandbox_environment and sandbox_environment.environment_variables:
        skipped_keys: list[str] = []
        added_keys = 0
        for key, value in sandbox_environment.environment_variables.items():
            if key in RESERVED_SANDBOX_ENVIRONMENT_VARIABLE_KEYS:
                skipped_keys.append(key)
                continue
            environment_variables[key] = value  # <-- BUG 🔴 Injects secrets from another user's private env
            added_keys += 1

Explanation

• Private sandbox environment access control is implemented in TaskRun.get_sandbox_environment() (via ctx.get_sandbox_environment()), which returns None when env.private and the environment creator differs from task.created_by.
• The refactor replaced this helper with a direct SandboxEnvironment query filtered only by id and team, dropping the private/created_by check.
• Because get_sandbox_for_repository reads and injects sandbox_environment.environment_variables, this becomes an authorization bypass that exposes stored secrets to other team members.
• The API layer also accepts sandbox_environment_id without enforcing privacy, so an attacker can supply a victim’s private environment ID and have its secrets injected into the attacker’s sandbox.

Codebase Inconsistency

• Another activity still uses the privacy-aware helper:

  # create_sandbox_from_snapshot.py
  sandbox_env = ctx.get_sandbox_environment()  # <-- Privacy check applied

  while get_sandbox_for_repository.py performs a direct query, indicating a regression/oversight rather than intended behavior.
• Existing model test codifies intended privacy behavior:

  self.assertIsNone(run.get_sandbox_environment())  # <-- Privacy enforced

Failing Test

Add this test to products/tasks/backend/tests/test_api.py:

def test_run_endpoint_rejects_private_environment_from_other_user(self):
    """
    Private sandbox environments should NOT be usable by other team members.
    This test proves the vulnerability exists at the API layer.
    """
    # Create User A with a private sandbox environment
    other_user = User.objects.create_user(email="victim@example.com", first_name="Victim", password="password")
    self.organization.members.add(other_user)
    private_env = SandboxEnvironment.objects.create(
        team=self.team,
        name="Victim's Private",
        private=True,
        created_by=other_user,
        environment_variables={"SECRET_KEY": "secret_value"}
    )
    task = self.create_task()
    # Current user (User B, same team) tries to run with User A's private environment
    response = self.client.post(
        f"/api/projects/@current/tasks/{task.id}/run/",
        {"sandbox_environment_id": str(private_env.id)},
        format="json",
    )
    # SHOULD return 403 Forbidden - user cannot use another's private environment
    # ACTUALLY returns 200 OK - the vulnerability allows this
    self.assertEqual(response.status_code, status.HTTP_403_FORBIDDEN)

Expected result: 403 returned (privacy enforced) Actual result: 200 OK (privacy bypass)

Exploit Scenario

1. User A creates a private sandbox environment with secrets in environment_variables.
2. User B (same team) discovers sandbox_environment_id from task run state.
3. User B starts a run using the victim’s private sandbox_environment_id.
4. The activity injects User A’s secret env vars into User B’s sandbox, allowing exfiltration from within the run.

Recommended Fix

Restore the privacy-aware lookup in the activity:

sandbox_environment = ctx.get_sandbox_environment()

and only read/apply environment_variables from that result.

History

This bug was introduced in commit 48e7429e294. The "agent hardening" commit refactored environment variable handling by replacing ctx.get_sandbox_environment() (which delegated to the privacy-aware TaskRun.get_sandbox_environment() method) with a direct database query that only filters by team. The original code path included a check that denied access to private environments unless task.created_by_id == env.created_by_id; the new inline query silently dropped this check, allowing any team member to read secrets from private sandbox environments belonging to other users.