You are comparing two bug findings from code review tools on the same codebase.

An engineer only has time to investigate one. Pick the one that is more important for them to see.

Finding A: {finding_a}

Finding B: {finding_b}

Use the select_winner tool to pick a or b.

Summarize this code review finding in one sentence.

{finding}

Loading rank data…

Loading rank data…

Detail bugs average 88th percentile importance vs CR bots.

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.

1. claude uptime, last 90 days  ↩︎

2. This is downstream of a product form factor difference that gave Detail an unfair advantage in our first attempt at comparing bug reports: most people don’t want page-long code review comments, so code review bots don’t generate them, but engineers do prefer bug reports to be thorough, so the reports from Detail are more complete. ↩︎

3. Fix rate is another option, and we track that as well. This measurement includes other factors beyond intrinsic importance, e.g. easier bugs are more likely to be fixed. ↩︎