fix(security): block MINIMAX_API_HOST workspace env injection and remove env-driven URL routing [AI-assisted]

[pgondhi987]

Summary

• Problem: Workspace .env files could set MINIMAX_API_HOST, which was not covered by the _BASE_URL suffix blocklist in src/infra/dotenv.ts. This allowed an attacker-controlled workspace to silently redirect credentialed MiniMax requests (including VLM and TTS paths that honor trusted runtime env) to an arbitrary origin, exfiltrating the operator's MiniMax API key via the Authorization: Bearer header.
• Why it matters: The exploit required only a .env file in the current working directory — no shared gateway, no adversarial co-tenant, no trusted local state. Any repository could carry this file and trigger credential exfiltration on openclaw startup.
• What changed: MINIMAX_API_HOST is now explicitly blocked from workspace .env loading. The fix is at the trust boundary: attacker-controlled workspace dotenv values no longer flow into process.env for this key.
• What did NOT change: Trusted runtime/env behavior is preserved. MiniMax VLM, MiniMax TTS, and the CN-vs-global routing helpers in provider-catalog.ts and minimax-web-search-provider.ts still honor MINIMAX_API_HOST when it comes from operator-controlled runtime env rather than workspace .env.

Change Type (select all)

• Bug fix
• Security hardening

Scope (select all touched areas)

• Auth / tokens
• Integrations

Linked Issue/PR

• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: MINIMAX_API_HOST did not match the _BASE_URL suffix blocklist rule, so loadWorkspaceDotEnvFile() accepted it and wrote it into process.env. MiniMax request paths and routing helpers already trusted process.env.MINIMAX_API_HOST, which is appropriate for operator-controlled runtime env but unsafe when populated from an attacker-controlled workspace .env.
• Missing detection / guardrail: No explicit entry for MINIMAX_API_HOST in BLOCKED_WORKSPACE_DOTENV_KEYS; no test asserting the env var is rejected from workspace .env.
• Contributing context: Similar pattern to prior workspace .env trust-boundary issues where _HOST-suffixed vars were left uncovered.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
• Target test or file: src/agents/minimax-vlm.normalizes-api-key.test.ts, extensions/minimax/speech-provider.test.ts, src/infra/dotenv.test.ts
• Scenario the test should lock in:
  • VLM: trusted MINIMAX_API_HOST env fallback still routes MiniMax VLM requests when present in runtime env.
  • TTS: trusted MINIMAX_API_HOST env fallback still resolves the MiniMax TTS base URL.
  • dotenv: MINIMAX_API_HOST is blocked from workspace .env and appears in the workspace blocklist completeness test.
• Why this is the smallest reliable guardrail: The fix is at the dotenv trust boundary, so the direct guardrail is proving the key is rejected there while confirming trusted runtime-env behavior remains intact.
• Existing test that already covers this (if any): MiniMax env fallback behavior existed already; this PR updates/extends the coupled tests so they align with the trust-boundary fix.

User-visible / Behavior Changes

MINIMAX_API_HOST is no longer accepted from workspace .env. Trusted operator-controlled runtime env behavior is unchanged: operators can still use MINIMAX_API_HOST from their normal runtime environment for MiniMax VLM, MiniMax TTS, and existing CN/global routing behavior.

Diagram (if applicable)

Before:
workspace .env (MINIMAX_API_HOST=attacker) -> process.env -> MiniMax request/routing code -> attacker origin + Bearer token

After:
workspace .env (MINIMAX_API_HOST=attacker) -> BLOCKED by dotenv blocklist
trusted runtime env (MINIMAX_API_HOST=operator value) -> MiniMax request/routing code -> operator-selected origin

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? Yes — workspace-injected MINIMAX_API_HOST can no longer steer credentialed MiniMax requests
• New/changed network calls? No direct request-construction behavior change in the MiniMax callers; the security fix prevents untrusted workspace dotenv from influencing the existing runtime-env-based routing
• Command/tool execution surface changed? No
• Data access scope changed? No
• Risk + mitigation: Workspace .env can no longer override MINIMAX_API_HOST. Trusted runtime env behavior remains unchanged, so legitimate operator CN/private endpoint routing continues to work.

Repro + Verification

Environment

• OS: Linux x86_64
• Runtime/container: Node.js v22 / Bun
• Model/provider: MiniMax VLM + TTS
• Integration/channel: N/A
• Relevant config: temporary workspace .env with MINIMAX_API_HOST=http://127.0.0.1:<port>

Steps

1. Run pnpm test src/agents/minimax-vlm.normalizes-api-key.test.ts — includes the updated trusted-env fallback case for MiniMax VLM.
2. Run pnpm test extensions/minimax/speech-provider.test.ts — the MiniMax TTS env-fallback case remains covered and is renamed to reflect trusted runtime-env behavior.
3. Run pnpm test src/infra/dotenv.test.ts — blocklist completeness coverage includes MINIMAX_API_HOST and asserts it is not loaded from workspace .env.

Expected

• MINIMAX_API_HOST from workspace .env is not loaded into process.env.
• Trusted runtime/env use of MINIMAX_API_HOST for MiniMax routing still works.

Actual

• The changed tests align with that behavior: workspace dotenv loading is blocked for MINIMAX_API_HOST, while trusted runtime-env fallback remains covered for MiniMax VLM/TTS.

Evidence

• Failing test/log before + passing after (workspace dotenv blocklist coverage now includes MINIMAX_API_HOST; MiniMax VLM/TTS regression coverage is aligned with preserving trusted runtime-env fallback rather than removing it)

Human Verification (required)

• Verified scenarios: workspace dotenv blocklist coverage for MINIMAX_API_HOST; MiniMax VLM trusted env fallback test coverage; MiniMax TTS trusted env fallback test coverage.
• Edge cases checked: trusted runtime MINIMAX_API_HOST remains honored; workspace .env no longer injects the key.
• What you did not verify: live MiniMax API round-trip; end-to-end proof with a live malicious listener in this PR branch.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes for trusted runtime env behavior; the only blocked surface is workspace .env.
• Config/env changes? Yes — MINIMAX_API_HOST is no longer accepted from workspace .env.
• Migration needed? No — operators using trusted runtime env do not need to change configuration.

Risks and Mitigations

• Risk: Minimal compatibility risk because the fix blocks only the untrusted workspace dotenv surface for MINIMAX_API_HOST.
  • Mitigation: Trusted runtime env behavior is preserved for MiniMax VLM, TTS, and existing CN/global routing paths.

[greptile-apps]

Greptile Summary

This PR closes a workspace .env injection vector where MINIMAX_API_HOST was not covered by the _BASE_URL suffix blocklist, allowing an attacker-controlled workspace file to redirect credentialed MiniMax VLM and TTS requests to an arbitrary origin. The fix is three-layered: the key is added to BLOCKED_WORKSPACE_DOTENV_KEYS in dotenv.ts, coerceApiHost() in minimax-vlm.ts drops its process.env.MINIMAX_API_HOST fallback, and normalizeMinimaxProviderConfig() in speech-provider.ts does the same — with targeted tests locking in each path.

Confidence Score: 5/5

Safe to merge — the security fix is correct, well-tested, and no regressions are introduced on the critical paths.

All three fix sites (blocklist, VLM, TTS) are correct and independently tested. The only remaining finding is a P2 unexplained type loosening in readMinimaxOverrides that does not affect runtime behavior or security. No P0/P1 issues remain.

extensions/minimax/speech-provider.ts — unexplained SpeechProviderOverrides → Record<string, unknown> type change in readMinimaxOverrides (P2 only).

Prompt To Fix All With AI

This is a comment left during a code review.
Path: extensions/minimax/speech-provider.ts
Line: 75-76

Comment:
**Unexplained type loosening**

The parameter type of `readMinimaxOverrides` was widened from `SpeechProviderOverrides | undefined` to `Record<string, unknown> | undefined`. This change isn't mentioned in the PR description and isn't directly needed by the security fix. Inside the function body, `overrides.model` etc. now resolve to `unknown` rather than `string | undefined`, which silently weakens the compile-time contract. If the intent was to decouple this helper from the SDK type, a comment explaining the reason would help, and the explicit SDK type is generally preferable here for type-safety.

```suggestion
function readMinimaxOverrides(
  overrides: SpeechProviderOverrides | undefined,
): MinimaxTtsProviderOverrides {
```

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

_{Reviews (1): Last reviewed commit: "fix: finalize issue changes" | Re-trigger Greptile}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4b4444f6de

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[pgondhi987]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep them coming!

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[pgondhi987]

@copilot resolve the merge conflicts in this pull request