Greptile Summary

This PR extends the host exec environment variable blocklist with seven new injection vectors (follow-up to #49025): six JVM/glibc/dotnet direct-injection vars added to blockedKeys, and GRADLE_USER_HOME added to blockedOverrideKeys to mirror the HOME/OPENSSL_CONF path-redirect pattern. The JSON policy, its generated Swift counterpart, and the test suite are all updated in sync.

Changes:

• src/infra/host-env-security-policy.json / HostEnvSecurityPolicy.generated.swift: Correctly categorizes MAVEN_OPTS, SBT_OPTS, GRADLE_OPTS, ANT_OPTS alongside the existing JAVA_TOOL_OPTIONS group; GLIBC_TUNABLES (CVE-2023-4911) and DOTNET_ADDITIONAL_DEPS fill gaps not caught by existing prefix rules. GRADLE_USER_HOME placement in blockedOverrideKeys is well-reasoned.
• src/infra/host-env-security.test.ts: Assertions for all new entries with case-insensitive coverage are present and correct. Two test-quality issues exist: a duplicate describe("isDangerousHostEnvOverrideVarName") block is added instead of extending the existing one, and there is no sanitizeHostExecEnv integration test exercising the "preserve inherited GRADLE_USER_HOME, drop agent override" behavior — the principal behavioral guarantee of the blockedOverrideKeys placement.
• CHANGELOG.md: Entry is accurate and references the correct PR number.

Confidence Score: 4/5

• Safe to merge; all policy changes are correct and the generated Swift file is in sync — two minor test quality gaps remain but do not affect runtime behavior.
• The security policy additions are well-researched and correctly categorized. The JSON source and Swift generated file are in sync. Case-insensitive unit test coverage exists for every new entry. The score is 4 rather than 5 only because of two test-quality gaps: a duplicate describe block for isDangerousHostEnvOverrideVarName and the absence of an integration-level sanitizeHostExecEnv test that verifies the key behavioral guarantee for GRADLE_USER_HOME (inherited value preserved, override dropped).
• src/infra/host-env-security.test.ts — duplicate describe block and missing sanitizeHostExecEnv integration test for GRADLE_USER_HOME.

This is a comment left during a code review.
Path: src/infra/host-env-security.test.ts
Line: 79-84

Comment:
**Duplicate `describe` block for `isDangerousHostEnvOverrideVarName`**

A second `describe("isDangerousHostEnvOverrideVarName", ...)` block is created here (lines 79–84), but an existing comprehensive block for the same function already lives at line 212. Test runners like Vitest will execute both, so the tests pass, but having two `describe` blocks with the same name in the same file is confusing and fragmented.

The new `GRADLE_USER_HOME` assertions (both the positive case and the negative case in `isDangerousHostEnvVarName` at line 75) are better placed inside the existing block at line 212, keeping all `isDangerousHostEnvOverrideVarName` coverage in one place:

```suggestion
  it("blocks GRADLE_USER_HOME as override-only (path redirect, not direct injection)", () => {
    expect(isDangerousHostEnvOverrideVarName("GRADLE_USER_HOME")).toBe(true);
    expect(isDangerousHostEnvOverrideVarName("gradle_user_home")).toBe(true);
  });
```
…moved into the block at line 212 instead.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/infra/host-env-security.test.ts
Line: 105-141

Comment:
**No `sanitizeHostExecEnv` integration coverage for `GRADLE_USER_HOME`**

The core behavioral claim of placing `GRADLE_USER_HOME` in `blockedOverrideKeys` — "the user's inherited value is trusted, only an agent-supplied override is dropped" — is not exercised through `sanitizeHostExecEnv`. The existing test here already validates this exact pattern for `HOME` and `ZDOTDIR`, making it the natural place to extend coverage.

Without this, a future refactor that accidentally moves `GRADLE_USER_HOME` from `blockedOverrideKeys` to `blockedKeys` (stripping it from `baseEnv` too) would silently break CI users who rely on a custom Gradle home, and the test suite would not catch it.

Suggested addition alongside the `HOME`/`ZDOTDIR` assertions:

```typescript
// inside the "blocks PATH and dangerous override values" test or as its own case:
const env2 = sanitizeHostExecEnv({
  baseEnv: {
    PATH: "/usr/bin:/bin",
    GRADLE_USER_HOME: "/home/user/.gradle",   // user-set; should be preserved
  },
  overrides: {
    GRADLE_USER_HOME: "/tmp/attacker-gradle", // agent override; should be dropped
  },
});
expect(env2.GRADLE_USER_HOME).toBe("/home/user/.gradle");
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: "add ANT_OPTS to bloc..."}

🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

1. 🟠 Blocked override env vars (e.g., GRADLE_USER_HOME) not enforced in gateway exec path

Description

src/infra/host-env-security-policy.json adds GRADLE_USER_HOME to blockedOverrideKeys, and isDangerousHostEnvOverrideVarName() correctly detects it. However, the primary gateway/local host execution path for the exec tool does not consult the override blocklist at all.

As a result, an untrusted caller that can supply params.env to the exec tool can still set blockedOverrideKeys (including the newly-added GRADLE_USER_HOME) and influence execution of otherwise-allowlisted tools.

Impact examples:

• GRADLE_USER_HOME can redirect Gradle’s user home to an attacker-controlled directory, enabling malicious init scripts or poisoned caches/plugins depending on tooling/config.
• The same gap applies to other existing blockedOverrideKeys (e.g., HOME, GIT_SSH_COMMAND, SSH_ASKPASS, PAGER, EDITOR, etc.), which can lead to command execution/exfiltration in downstream tools.

Vulnerable code (override blocklist is ignored):

​// src/agents/bash-tools.exec-runtime.ts
export function validateHostEnv(env: Record<string, string>): void {
  for (const key of Object.keys(env)) {
    const upperKey = key.toUpperCase();
    if (isDangerousHostEnvVarName(upperKey)) { /* ... */ }
    if (upperKey === "PATH") { /* ... */ }
  }
}

And this validation is the only guard before merging user-provided env overrides for host execution:

​// src/agents/bash-tools.exec.ts
if (host !== "sandbox" && params.env) {
  validateHostEnv(params.env);
}
const mergedEnv = params.env ? { ...baseEnv, ...params.env } : baseEnv;

So GRADLE_USER_HOME (and other override-blocked keys) is accepted and propagated.

Recommendation

Enforce the override blocklist for host execution paths that accept user-supplied env (e.g., tools.exec on gateway).

Option A (minimal change): extend validateHostEnv to reject override-blocked keys/prefixes:

import {
  isDangerousHostEnvVarName,
  isDangerousHostEnvOverrideVarName,
} from "../infra/host-env-security.js";

export function validateHostEnv(env: Record<string, string>): void {
  for (const rawKey of Object.keys(env)) {
    const key = rawKey.trim();
    const upper = key.toUpperCase();

    if (isDangerousHostEnvVarName(upper) || isDangerousHostEnvOverrideVarName(upper)) {
      throw new Error(`Security Violation: Environment variable '${rawKey}' is forbidden.`);
    }

    if (upper === "PATH") {
      throw new Error("Security Violation: Custom 'PATH' variable is forbidden during host execution.");
    }
  }
}

Option B (preferred): reuse the centralized sanitizer for consistency:

• Build the execution env via sanitizeHostExecEnv({ baseEnv: process.env, overrides: params.env, blockPathOverrides: true }).

Also add regression tests ensuring tools.exec rejects/strips keys from blockedOverrideKeys (including GRADLE_USER_HOME).

Analyzed PR: #49702 at commit e2508ac

_{Last updated on: 2026-03-18T12:10:48Z}

CI note: the three persistent failures (contracts, channels, extensions) are pre-existing across all open PRs right now - confirmed on #48805, #48804, #48851 which have the same TS1360 type errors in channelContentConfig.ts. Nothing to do with this PR's JSON/Swift/test changes.

All code-relevant checks pass: check (lint/typecheck), both test shards, bun test, startup-memory, secrets, check-docs.