Security Review

Integration: Zen
Repository: https://github.com/beehiveinnovations/zen-mcp-server
Commit: latest
Scan Date: 2026-03-13 13:03 UTC

Security Score

35 / 100

Tier Classification

Reject

OWASP Alignment

OWASP Rubric

• Standard: OWASP Top 10 (2021) aligned review
• Core methodology: architecture context, trust boundaries, data-flow tracing, threat modeling, control verification, and evidence-backed validation
• Key characteristics considered: exploitability, impact, likelihood, attacker preconditions, and business context

OWASP Security Category Mapping

• A01 Broken Access Control: none
• A02 Cryptographic Failures: 4 finding(s)
• A03 Injection: 1 finding(s)
• A04 Insecure Design: none
• A05 Security Misconfiguration: 21 finding(s)
• A06 Vulnerable and Outdated Components: 1 finding(s)
• A07 Identification and Authentication Failures: none
• A08 Software and Data Integrity Failures: none
• A09 Security Logging and Monitoring Failures: 87 finding(s)
• A10 Server-Side Request Forgery: none

Static Analysis Findings (Bandit)

High Severity

• Use of weak MD5 hash for security. Consider usedforsecurity=False in tests/http_transport_recorder.py:326 (confidence: HIGH)
• Use of weak MD5 hash for security. Consider usedforsecurity=False in tests/http_transport_recorder.py:389 (confidence: HIGH)
• Use of weak MD5 hash for security. Consider usedforsecurity=False in tests/test_cassette_semantic_matching.py:75 (confidence: HIGH)
• Use of weak MD5 hash for security. Consider usedforsecurity=False in tests/test_cassette_semantic_matching.py:76 (confidence: HIGH)

Medium Severity

• Probable insecure usage of temp file/directory. in tests/conftest.py:17 (confidence: MEDIUM)
• Possible binding to all interfaces. in tests/pii_sanitizer.py:98 (confidence: MEDIUM)
• Probable insecure usage of temp file/directory. in tests/test_auto_mode.py:211 (confidence: MEDIUM)
• Probable insecure usage of temp file/directory. in tests/test_chat_simple.py:62 (confidence: MEDIUM)
• Probable insecure usage of temp file/directory. in tests/test_chat_simple.py:71 (confidence: MEDIUM)
• Probable insecure usage of temp file/directory. in tests/test_chat_simple.py:79 (confidence: MEDIUM)
• Probable insecure usage of temp file/directory. in tests/test_chat_simple.py:109 (confidence: MEDIUM)
• Probable insecure usage of temp file/directory. in tests/test_chat_simple.py:127 (confidence: MEDIUM)
• Probable insecure usage of temp file/directory. in tests/test_chat_simple.py:306 (confidence: MEDIUM)
• Probable insecure usage of temp file/directory. in tests/test_chat_simple.py:316 (confidence: MEDIUM)
• Probable insecure usage of temp file/directory. in tests/test_docker_claude_desktop_integration.py:190 (confidence: MEDIUM)
• Probable insecure usage of temp file/directory. in tests/test_path_traversal_security.py:51 (confidence: MEDIUM)
• Probable insecure usage of temp file/directory. in tests/test_path_traversal_security.py:52 (confidence: MEDIUM)
• Probable insecure usage of temp file/directory. in tests/test_path_traversal_security.py:57 (confidence: MEDIUM)
• Probable insecure usage of temp file/directory. in tests/test_path_traversal_security.py:58 (confidence: MEDIUM)
• Possible binding to all interfaces. in tests/test_pii_sanitizer.py:96 (confidence: MEDIUM)
• Possible SQL injection vector through string-based query construction. in tools/docgen.py:348 (confidence: LOW)
• Audit url open for permitted schemes. Allowing use of file:/ or custom schemes is often unexpected. in tools/version.py:97 (confidence: HIGH)

Low Severity

• Consider possible security implications associated with the subprocess module. in communication_simulator_test.py:74 (confidence: HIGH)
• subprocess call - check for execution of untrusted input. in communication_simulator_test.py:448 (confidence: HIGH)
• Consider possible security implications associated with the subprocess module. in docker/scripts/healthcheck.py:7 (confidence: HIGH)
• Starting a process with a partial executable path in docker/scripts/healthcheck.py:22 (confidence: HIGH)
• subprocess call - check for execution of untrusted input. in docker/scripts/healthcheck.py:22 (confidence: HIGH)
• Try, Except, Pass detected. in providers/gemini.py:401 (confidence: HIGH)
• Try, Except, Continue detected. in providers/openai_compatible.py:84 (confidence: HIGH)
• Try, Except, Pass detected. in providers/openai_compatible.py:797 (confidence: HIGH)
• Try, Except, Pass detected. in server.py:580 (confidence: HIGH)
• Try, Except, Pass detected. in server.py:583 (confidence: HIGH)
• Try, Except, Pass detected. in server.py:662 (confidence: HIGH)
• Try, Except, Pass detected. in server.py:756 (confidence: HIGH)
• Try, Except, Pass detected. in server.py:772 (confidence: HIGH)
• Try, Except, Pass detected. in server.py:872 (confidence: HIGH)
• Try, Except, Pass detected. in server.py:1062 (confidence: HIGH)
• Try, Except, Pass detected. in server.py:1285 (confidence: HIGH)
• Consider possible security implications associated with the subprocess module. in simulator_tests/base_test.py:11 (confidence: HIGH)
• subprocess call - check for execution of untrusted input. in simulator_tests/base_test.py:169 (confidence: HIGH)
• subprocess call - check for execution of untrusted input. in simulator_tests/base_test.py:276 (confidence: HIGH)
• Consider possible security implications associated with the subprocess module. in simulator_tests/log_utils.py:10 (confidence: HIGH)

Hardcoded Secrets

3 potential hardcoded secret(s) detected.

Build Status

SKIPPED

Build step was skipped to avoid running untrusted build commands by default.

Tests

Detected (pytest)

Documentation

README: Present
Dependency file: Present

AI Security Review

Security Code Review Report for repository: Zen

1) OWASP Review Methodology Applied
- Orientation: I inspected repository layout, the main server entry (server.py), providers, tools, clink agents, and utilities. I reviewed static analysis notes and prioritized files flagged by the scanner.
- Entry Points: I examined server.py (MCP stdo server & tool registry), tools (SimpleTool / BaseTool), provider implementations (providers/openai_compatible.py, providers/custom.py), clink agent execution (clink/agents/base.py and clink/registry.py), and file access & path validation utilities (utils/file_utils.py and utils/security_config.py).
- Data flows: Traced user-supplied/external inputs (MCP tool arguments including absolute_file_paths, CUSTOM_API_URL, CLI client config files) through validation and into sinks (file I/O, subprocess execution, network calls).
- Trust boundaries & entry points: MCP stdio messages -> server.call_tool -> tool code (SimpleTool/BaseTool) -> provider/client resolvers -> provider network calls (OpenAI/OpenRouter/Custom) and clink -> subprocess exec of configured CLIs.
- Threat modelling: Focused on path traversal, arbitrary command execution, SSRF, secret leakage in logs, insecure configuration loading, and unsafe deserialization in tests.
- Verification: Confirmed behavior by reading critical code implementing validation, path handling, provider base URL validation, CLI command execution, and logging sanitization.

2) OWASP Top 10 2021 Category Mapping
- A01: Broken Access Control: clink registry/agent executing configured local commands (clink/registry.py, clink/agents/base.py)
- A02: Cryptographic Failures: not directly observed.
- A03: Injection: potential command execution / CLI injection based on configured commands (clink).
- A04: Insecure Design: permissive acceptance of absolute paths in various config resolution functions; design choices allow operators to configure execution of arbitrary local commands.
- A05: Security Misconfiguration: .env override (utils/env.py) and logging configuration may leak sensitive information if mishandled; default debug logging enabled.
- A06: Vulnerable and Outdated Components: dependency review not exhaustively performed here; but code uses httpx, OpenAI SDK; pinned versions should be validated in pyproject/requirements.
- A07: Identification and Authentication Failures: not prominent in code reviewed (relying on environment-provided API keys), but operator-configured keys may be accidentally exposed in logs if not sanitized.
- A08: Software and Data Integrity Failures: no runtime plugin signing / integrity verification for custom provider endpoints; ModelProviderRegistry allows custom provider factories.
- A09: Security Logging and Monitoring Failures: some try/except:pass swallowing in critical shutdown/cleanup code that could hide failures (server.py cleanup_providers); however proper mcp_activity logging exists.
- A10: Server-Side Request Forgery (SSRF): provider base_url (_validate_base_url/_is_localhost_url) validation is limited; custom endpoints (CUSTOM_API_URL) can point to internal hosts and will be used (providers/openai_compatible.py, providers/custom.py).

3) Critical Vulnerabilities (RCE, injection, auth bypass, unsafe deserialization)
- No immediate unauthenticated remote RCE was found in code executed on MCP server directly from untrusted network inputs. The critical risks are configuration-driven local command execution that can run arbitrary local programs when CLI clients are configured.
- Unsafe deserialization: I found test code using pickle (simulator_tests/test_secaudit_validation.py), but only in tests. No production code unpickling untrusted data was found.

4) High Severity Issues
1. Arbitrary local command execution via CLINk configuration (potential local RCE / command injection)
- Files: clink/agents/base.py (create_subprocess_exec usage) and clink/registry.py (configuration parsing)
- Evidence: clink/registry.py -> _resolve_executable returns shlex.split(command) (no whitelist or strict validation) and configs are loaded from conf/cli_clients and user config directories (ClinkRegistry._iter_config_files). clink/agents/base.py then resolves the executable via shutil.which and executes the full command via asyncio.create_subprocess_exec (safe from shell=True injection, but will run whatever the configured executable+args are). See clink/agents/base.py at the process.launch call (search result: clink/agents/base.py:111) and clink/registry.py:_resolve_executable (search result reference).
- Severity: High (A01/A03)
- Exploitability: High if attacker can influence config files (e.g., user config dir or environment that points to config) or if operator config contains malicious/untrusted values. An attacker who can write a config JSON can cause arbitrary local execution with operator privileges.
- Remediation:
- Restrict CLIs that can be executed to a configured allow-list in code or config (whitelist of allowed executables/paths), or require executables to be absolute paths under an allowed directory.
- Validate and canonicalize executable paths and arguments during config load; disallow dangerous flags or redirections and disallow arbitrary output flag templates that may write to arbitrary paths without checks.
- Require operator confirmation / secure deployment process for CLI client definitions and treat them as high privilege.
- Consider running CLI agents in a sandboxed process / chroot or under reduced privileges.
- Suggested code changes:
- clink/registry.py::_resolve_executable: validate against a whitelist and force absolute/realpath checks. E.g. replace shlex.split(command) with parsing + validation. Add logging when config overrides occur.
- clink/agents/base.py: before executing, re-validate resolved_executable is under a safe directory and that role.args/config_args are within allowed set. (clink/agents/base.py around create_subprocess_exec call at line ~111)

1. Server allowed to call arbitrary CUSTOM_API_URL (SSRF-like / internal network access)
2. Files: providers/openai_compatible.py (base_url validation uses urlparse but does not perform DNS resolution to ban internal addresses), providers/custom.py (initialization) and server.py (configure_providers accepts CUSTOM_API_URL from env). Specifically, _validate_base_url (providers/openai_compatible.py) checks scheme/hostname/port only; _is_localhost_url detects localhost/private IPs but does not block them.
3. Evidence: providers/openai_compatible.py: _validate_base_url only checks scheme, hostname, and port (search match). clients are then created with base_url assigned to OpenAI client (client_kwargs['base_url']). CUSTOM_API_URL is used without network isolation. Search results: providers/openai_compatible.py:_validate_base_url and _is_localhost_url.
4. Severity: High (A10 SSRF)
5. Exploitability: Medium - requires attacker control of CUSTOM_API_URL environment variable (or for multi-tenant deployments where an attacker can influence it). If that is possible, attacker can route model calls to internal services or exfiltrate data.
6. Remediation:
   • Harden URL validation: perform DNS resolution and block internal/private IP ranges by default unless explicitly whitelisted. Validate against e.g., ip.is_private, ip.is_loopback, link-local ranges, and also disallow IPv6 internal ranges unless explicitly allowed.
   • Add an explicit operator opt-in to allow local/private addresses for CUSTOM_API_URL, and log/alert when such addresses are configured.
   • Consider adding an allowlist of safe hostnames or require HTTPS with certificate verification for remote endpoints.

5) Medium Severity Issues
1. Potential log leakage of sensitive data
- Files: server.py logging calls, providers/openai_compatible.py _sanitize_for_logging mitigates API key logging but other fields may leak (server.py uses debug/info extensively); env override loads .env and enables overriding system env (utils/env.py). There are many spots where large prompt content or client_info are logged. Example: server.py logs incoming client info to mcp_activity.
- Severity: Medium (A09/A05)
- Remediation:
- Ensure all logs strip or mask potential API keys or sensitive tokens beyond 'api_key' and 'authorization' keys. Consider a centralized sanitizer for any dict logged.
- Default log level to INFO in production (server code uses LOG_LEVEL env that defaults to DEBUG) and document safe settings in README. Ensure log files are created with secure file permissions (600) and rotate/lock files appropriately.

1. Path resolution trusts absolute paths in config and prompt files
2. Files: clink/registry.py:_resolve_prompt_path/_resolve_path allows absolute candidate paths to be returned directly (no dangerous path checks). server uses BaseTool.get_input_schema and tools call read_file_content which enforces absolute paths and checks with resolve_and_validate_path.
3. Evidence: clink/registry.py:_resolve_prompt_path -> _resolve_path simply returns absolute Path directly; no cross-check to disallow system prompt_path pointing to sensitive system files. (clink/registry.py:_resolve_prompt_path/_resolve_path documented in file.)
4. Severity: Medium (A04/A01)

5. Remediation:

   • Validate prompt_path is within expected configuration directories or ensure it doesn’t point to system-critical files. When accepting absolute paths from config, do explicit allow-listing or canonicalization checks.

6. Greedy JSON extraction from exception strings and parsing heuristics

7. Files: providers/openai_compatible.py around line ~770: code searches exception text via re.search(r"{.*}", str(error)) and then uses ast.literal_eval(json_like_str) followed by fallback of replacing single quotes to double quotes and json.loads. The regex is greedy and may capture trailing content; literal_eval is safer than eval but feeding untrusted arbitrary string from remote model/provider exceptions may still cause unexpected parsing failures.
8. Severity: Medium-Low (A03/A09)
9. Remediation:
   • Use a non-greedy regex and robust JSON extraction (e.g., use a small parser or try to find balanced braces), and prefer json.loads with strict validation. If literal_eval use is retained, ensure the string is strictly validated to be a literal.
   • Add exception handling and avoid depending on heuristics that may silently mask the root error.

6) Low Severity Issues / Best-practice gaps
1. Swallowed exceptions and “except: pass” in cleanup code
- Files: server.py cleanup_providers (atexit handler) and various try/except: pass patterns reported by static analysis. Swallowing errors at shutdown can hide resource closure issues.
- Severity: Low (A09)
- Remediation: Log exceptions at debug level instead of silently passing.

1. Test-only insecure code flagged by static analysis (subprocess usage, pickle)
2. Files: simulator_tests and tests contain subprocess usage and pickle.loads in test code. These are test-only and not part of production; confirm they remain confined to test suites and are not used in production endpoints.
3. Severity: Low (test-only)
4. Remediation: Keep these in test suites and do not enable in production.

7) Key Risk Characteristics (Exploitability, Impact, Likelihood, Preconditions)
- Arbitrary local CLI execution (clink): Exploitability: High if attacker can modify CLI config or place files in the user config path. Impact: High (local code execution as service user, exfiltrate secrets, modify workspace). Likelihood: Medium in an environment where multiple users can drop files into user config directories; Low in single-operator deployments. Preconditions: Ability to write or modify CLI client config JSON (USER_CONFIG_DIR, conf/cli_clients or environment override path).
- SSRF via CUSTOM_API_URL: Exploitability: Medium (requires ability to set env var or influence env). Impact: Moderate-High (information disclosure from internal services, lateral movement). Likelihood: Low in secure deployments; Higher in ephemeral/containerized CI or misconfigured deployments that pull env from untrusted sources. Preconditions: Ability to set CUSTOM_API_URL in environment or .env file.
- Log leakage: Exploitability: Medium (an attacker who can read logs). Impact: Moderate (exposure of API keys, prompts). Likelihood: Medium (debug logs default). Preconditions: Access to logs or ability to craft data that gets logged.
- Path access from configs: Exploitability: Medium-Low (requires config modification). Impact: Moderate (leakage of system files used as prompts). Preconditions: ability to specify absolute prompt files in CLI config or to place prompt files in registries.

8) Positive Security Practices Observed
- File access hardening: utils/file_utils.resolve_and_validate_path enforces absolute paths, forbids dangerous system roots and home-root scanning, resolves symlinks, and checks against DANGEROUS_PATHS (utils/security_config.py). This is a strong defense in depth for file access from MCP tool requests. (utils/file_utils.py: resolve_and_validate_path, utils/security_config.py: is_dangerous_path)
- Logging sanitization: providers/openai_compatible.py implements _sanitize_for_logging to remove api_key and authorization entries and truncate long text before logging. This reduces risk of credential leakage in many API call logs.
- Timeout and proxy hardening: OpenAI-compatible provider avoids proxy env vars when creating HTTP client and configures reasonable timeouts, reducing some SSRF/proxy abuse risk.
- Prompt size validation: BaseTool._validate_token_limit enforces MCP_PROMPT_SIZE_LIMIT for user content crossing MCP boundary.

9) Recommendations (concrete fixes with file:line references)
NOTE: Line numbers are approximate and come from code locations discovered during review; follow references by file and function names below.

Critical / High priority fixes
- Harden CLINK command execution
- Files: clink/registry.py::_resolve_executable (where shlex.split is used); clink/agents/base.py (process creation at asyncio.create_subprocess_exec near line ~111).
- Fix: Implement a whitelist of allowed executables or require absolute path and validate it against a safe directory. Validate and sanitize arguments in registry load instead of executing them blindly. Example: on registry load, validate resolved_executable = Path(shutil.which(executable_name)).resolve(); ensure it is under /usr/bin or an operator-defined safe list; otherwise reject config with explicit error.
- OWASP mapping: A01 (Broken Access Control), A03 (Injection)

• Harden provider base_url handling (SSRF)
• Files: providers/openai_compatible.py:_validate_base_url and _is_localhost_url; server.py configure_providers (CUSTOM_API_URL handling at server.py:~479).
• Fix: Extend _validate_base_url to perform DNS resolution and reject addresses in private / link-local / loopback ranges by default, unless an explicit opt-in is set (e.g., CUSTOM_API_ALLOW_PRIVATE=true). Example: resolve hostname to IP(s) and for each ip do ipaddress.ip_address(ip).is_private or is_loopback checks; if so, require opt-in setting.
• OWASP mapping: A10 (SSRF)

Medium priority fixes
- Improve logging sanitization and default log level
- Files: server.py (logging setup), providers/openai_compatible.py:_sanitize_for_logging
- Fix: Ensure all logged dictionaries pass through a sanitizer that strips common secrets (API tokens, Authorization headers, environment secrets) and avoid logging full prompts or user-provided files at DEBUG in production. Default LOG_LEVEL to INFO in production or detect CI.
- OWASP mapping: A05 / A09

• Avoid fragile JSON extraction from exception text
• File: providers/openai_compatible.py (regex extraction around line ~770)
• Fix: Replace the greedy re.search(r"{.*}", ...) with a robust parser: try json.loads directly on candidate substrings, use a stack-based brace matching to find the first balanced JSON object, and do not attempt ast.literal_eval fallback unless absolutely necessary. Surround with try/except and log parsing failures, not silently converting malformed text.
• OWASP mapping: A03

Low priority fixes / best-practices
- Replace silent except: pass with logged debug exceptions in server cleanup
- Files: server.py cleanup_providers and other swallowed-exception sites
- Fix: Log exception stacktrace at DEBUG when cleanup fails to aid troubleshooting.

• Document operator responsibilities for CLI config and .env
• Files: README.md, SECURITY.md
• Fix: Add explicit warnings that CLI client configurations are powerful and must be managed as high-privilege config; document secure defaults for LOG_LEVEL and file permissions of logs and .env.

10) Next Tier Upgrade Plan (integration security posture)
- Current likely tier: Silver
- Rationale: The codebase demonstrates many strong security practices (robust file path validation, prompt-size checks, logging sanitization hooks, timeout/proxy hardening). However, the ability to execute configured CLIs without whitelisting and permissive handling of custom provider endpoints and config-sourced absolute paths are significant configuration-driven risks.
- Target next tier: Gold
- Required prioritized actions to reach Gold (highest priority first):
1. Harden CLINK execution path (whitelist executables, validate args, sandbox execution). (High priority)
2. Harden CUSTOM_API_URL and provider base_url validation (DNS resolution, reject internal ranges by default, opt-in for localhost). (High priority)
3. Centralize logging sanitization and default to INFO in production; ensure logs are created with secure permissions. (Medium)
4. Validate configuration file paths and disallow using absolute system file paths as prompts or CLI role files unless explicitly allowed. (Medium)
5. Add operational documentation and deployment security checks (CI scanning of env and config files). (Low)

Summary of concrete file:line remediation pointers (as discovered during review):
- clink/agents/base.py (around line ~111): validate resolved_executable and sanitize arguments before asyncio.create_subprocess_exec. Implement whitelist and sandboxing.
- clink/registry.py::_resolve_executable (function): do not accept arbitrary commands via shlex.split without validation; enforce absolute paths or whitelisted names.
- providers/openai_compatible.py (around lines ~752-780): replace greedy JSON extraction, avoid ast.literal_eval heuristics; improve _validate_base_url to resolve hostnames and block internal IPs by default.
- utils/file_utils.py: resolve_and_validate_path (start at function def around utils/file_utils.py:282) is a strong control — ensure all code paths that read files call this function (clink registry when resolving prompt paths should call resolve_and_validate_path or similar check).
- server.py cleanup_providers: remove silent suppression of exceptions; log at debug level.

Final notes & actionable next steps for maintainers
- Short-term (1-2 days): Implement quick hardening steps: (a) prevent CLI configs from referencing absolute prompt files outside config directories; (b) default LOG_LEVEL to INFO and ensure API keys are removed from logs.
- Medium-term (1-2 weeks): Implement CLIAgent allow-list or sandboxing; implement DNS-based validation for CUSTOM_API_URL and flag/risk when internal addresses are configured.
- Long-term (1-2 months): Perform dependency CVE scan (pyproject/requirements), add runtime tests for SSRF and clink configuration safety, adopt signed configuration or RBAC for config editing in multi-user contexts.

If you want I can produce small code patches / diff suggestions for the highest-priority items (CLINK command validation, provider base_url DNS checks, logging sanitization) referencing exact lines and proposed code.

-- End of review --

Summary

Security Score: 35/100 (Reject)
Static analysis found 4 high, 18 medium, and 2851 low severity issues.
Build step skipped for safety.
Tests detected.