Security Issue: Untrusted Prompt Forwarding Enables Arbitrary File Modification via CLI Integration

[lilmingwa13]

Project Version

latest

Bug Description

Description

I identified a security issue in the clink tool where untrusted user input is forwarded directly to an external AI CLI with file editing capabilities enabled.
This issue allows a remote MCP client to influence a locally executed CLI with filesystem write capabilities.

Affected Code Paths

• pal-mcp-server/tools/clink.py

  • CLinkTool.execute() → forwards user-controlled prompt to CLI agent

• pal-mcp-server/clink/agents/base.py

  • BaseCLIAgent.run() → executes CLI with provided prompt via subprocess

• pal-mcp-server/clink/agents/claude.py

  • CLI command construction including system prompt injection

• pal-mcp-server/conf/cli_clients/claude.json

  • CLI configured with --permission-mode acceptEdits

Root Cause

• Untrusted prompt is passed directly from:

  CLinkRequest.prompt → _prepare_prompt_for_role → agent.run(...)
  

• CLI is executed with file-edit permissions enabled:

  --permission-mode acceptEdits
  

• No validation, sandboxing, or path restrictions are enforced before execution

• No trust boundary enforcement between remote input and local CLI execution context

Impact

• Arbitrary file creation/modification on host filesystem
• Potential code injection into repository
• Risk of downstream execution (CI/CD, imports, scripts)
• No authentication required beyond access to the MCP tool

Why this is a security issue (not expected behavior)

The vulnerability crosses a trust boundary:

• Remote MCP client → local CLI with filesystem access

The application assumes the CLI is safe, but allows attacker-controlled input to drive it without restrictions.
This behavior violates the principle of least privilege and allows untrusted input to control a privileged local execution context.

Recommendation

• Disable acceptEdits by default
• Add explicit allow-list for editable paths
• Introduce sandboxing or restricted execution mode
• Validate or constrain prompt capabilities before execution

Disclosure

I have submitted this issue to MITRE for CVE consideration and can provide a working PoC and reproduction steps privately if needed.

Note

Note: This issue is unrelated to API provider configuration.
The security reporting channel referenced in SECURITY.md appears to be non-functional (returns 404).
See issue #393.
Because of this, this issue is reported publicly with limited details.
Full technical details and PoC can be shared privately upon request.

Relevant Log Output

No relevant logs. This is a design-level security issue, not a runtime error.

Operating System

Windows

Sanity Checks

• I have searched the existing issues and this is not a duplicate.
• I am using GEMINI_API_KEY
• I am using OPENAI_API_KEY
• I am using OPENROUTER_API_KEY
• I am using CUSTOM_API_URL

[lilmingwa13]

I’ve submitted a PR addressing this issue.

The fix enforces safe-by-default behavior and requires explicit opt-in for filesystem edits.

Happy to provide additional details or PoC privately if needed.

[lilmingwa13]

Hi maintainers,

Following up on this security issue.

I previously attempted to report this via the SECURITY.md advisory link, but it returned 404 (#393), so I was unable to use the GitHub Security Advisory flow.

I have also submitted this issue to MITRE for CVE assignment, but was advised to coordinate with the project maintainers first.

Could you confirm whether:

• this issue can be tracked via GHSA, or
• you would prefer me to submit details privately once the advisory channel is restored?

If I don’t hear back, I may proceed with CVE assignment via MITRE based on disclosure attempts.

Thanks!

[lilmingwa13]

Hi @izzoa, thanks for the ebe4f9c commit referencing #417.

Could you please confirm whether this commit is intended to address the security issue reported here, whether it has been or will be included in a release, and whether the project plans to open a GitHub Security Advisory / request a CVE for it?

I previously attempted to follow the repository security policy and also contacted the maintainers directly, so I’m trying to understand the expected coordination path for this issue.

[izzoa]

Hi @lilmingwa13 - it does address it and works - however, as I'm not sure if this project has been abandoned (haven't heard anything from maintainers in a while either) so I created my own fork here with several enhancements on top of the base pal (auto-updating to the latest models through litellm; persistent convo storage in sqlite db, streaming output, etc). Overview of improvements / differences here.