Security Review

Integration: VictoriaMetrics
Repository: https://github.com/VictoriaMetrics-Community/mcp-victoriametrics
Commit: latest
Scan Date: 2026-03-15 04:37 UTC

Security Score

80 / 100

Tier Classification

Silver

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: none
• A03 Injection: none
• A04 Insecure Design: none
• A05 Security Misconfiguration: none
• A06 Vulnerable and Outdated Components: none
• A07 Identification and Authentication Failures: none
• A08 Software and Data Integrity Failures: none
• A09 Security Logging and Monitoring Failures: none
• A10 Server-Side Request Forgery: none

Static Analysis Findings (Bandit)

High Severity

None

Medium Severity

None

Low Severity

None

Build Status

SKIPPED

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

Tests

Not detected

Documentation

README: Present
Dependency file: Present

AI Security Review

Security Code Review — VictoriaMetrics (mcp-victoriametrics)

Reviewer: automated OWASP-aligned security code review
Date: 2026-03-15

Summary: I reviewed the MCP (Model Context Protocol) integration for VictoriaMetrics (cmd/mcp-victoriametrics) using an OWASP methodology: I inspected the main entrypoint, configuration parsing, HTTP client usage, tool implementations, logging/hooks, and utility helpers. I traced data flows from incoming MCP tool calls into HTTP requests to the VictoriaMetrics instance or VictoriaMetrics Cloud API, and I inspected how secrets and responses are handled and logged. Static scans included the vendorized client and mcp-go server code where relevant.

Contents
1. OWASP Review Methodology Applied
2. Findings mapped to OWASP Top 10 2021 categories
3. Critical vulnerabilities
4. High severity issues
5. Medium severity issues
6. Low severity issues
7. Key risk characteristics for each finding
8. Positive security practices observed
9. Concrete recommendations (file:line pointers where applicable)
10. Next tier upgrade plan (current tier and actions to reach next tier)

1) OWASP Review Methodology Applied
- Orientation: read cmd/mcp-victoriametrics/main.go and config/config.go to understand runtime modes and configuration sources (env vars). Reviewed prioritized tool files (cmd/mcp-victoriametrics/tools/*), utils, logging, hooks, and vendor client for cloud API.
- Entry points: main.go initializes MCP server and registers tools & prompts. Tools expose many HTTP-based operations which build internal HTTP requests to the configured VictoriaMetrics entrypoint or cloud API.
- Trust boundaries & inputs: MCP client-supplied tool arguments (mcp.CallToolRequest) are untrusted. Environment variables and cloud API responses are trusted at different levels (owner-provided config vs. remote API). I traced how tool args are used to build URLs, query params, and how request/response bodies and secrets flow into logs and caches.
- Data flow tracing: Followed tool handlers -> CreateSelectRequest/CreateAdminRequest -> getSelectURL/getRootURL -> getBearerToken -> http.NewRequestWithContext -> http.DefaultClient.Do -> response processing (GetTextBodyForRequest) and finally returning mcp.CallToolResult back to the client.
- Threat modeling: focused on SSRF, DoS/resource exhaustion, exposure of secrets in logs/responses, unbounded memory use, panics/DoS via slicing/indexing, insecure header handling, and dependency risk.
- Verification: inspected concrete source lines in files listed below and reproduced reasoning from code constructs to derive findings.

2) OWASP Top 10 2021 Category Mapping
- A01 Broken Access Control: Not observed as an immediate remote bypass, but caution recommended when returning cloud resources that may contain sensitive data (see logging and tool outputs).
- A02 Cryptographic Failures: Not directly observed (no custom crypto), but sensitive tokens are handled in memory and could be leaked (see A09/A06 overlaps).
- A03 Injection: Not applicable for traditional SQL/OS injection; no shell execution in primary integration code.
- A04 Insecure Design: Some design choices permit large responses to be fully read into memory and full request/response objects to be logged (design-level issues causing DoS and secret exposure).
- A05 Security Misconfiguration: Use of custom headers that may override Authorization header; lack of explicit maximum body size handling.
- A06 Vulnerable and Outdated Components: Dependency list present (go.mod); recommend regular vulnerability scanning and dependency updates.
- A07 Identification and Authentication Failures: Use of bearer tokens and cloud API keys is correct but needs careful handling to avoid exposure in logs and results.
- A08 Software and Data Integrity Failures: Not observed.
- A09 Security Logging and Monitoring Failures: Logging hooks log request and result payloads (could leak secrets and large payloads). Also lack of redaction/size limits.
- A10 Server-Side Request Forgery (SSRF): Low/medium risk due to building HTTP requests from a combination of config and user-supplied path/query values; entrypoint is primarily configured but some user-supplied path segments are appended.

3) Critical Vulnerabilities (RCE, unsafe deserialization, auth bypass)
- None discovered in the examined code.

4) High Severity Issues
1. Excessive/unbounded logging of request and result payloads (sensitive data leakage, information exposure)
- Files/locations:
- cmd/mcp-victoriametrics/hooks/hooks.go — AddBeforeAny logs full request message: slog.Info("MCP request received", ..., "message", toJSON(message))
(approx file lines around hooks.AddBeforeAny definition)
- cmd/mcp-victoriametrics/hooks/hooks.go — AddOnSuccess logs full result: slog.Info("MCP request succeeded", ..., "result", toJSON(result))
- cmd/mcp-victoriametrics/hooks/hooks.go — AddOnError logs error and message: slog.Error(..., "message", toJSON(message), "error", err.Error())
- Severity: High (A09 - Security Logging and Monitoring Failures)
- Why: toJSON() marshals the entire request/result object. These objects can include tool arguments and returned API payloads that may contain sensitive data (e.g., rule files, tokens revealed by cloud APIs, tenant identifiers, secrets embedded in config responses). Storing them in logs unredacted can leak secrets to any system consuming log output.
- Remediation: Redact sensitive fields and limit size. Replace toJSON() usage with a safe serializer that filters or redacts known sensitive keys (authorization headers, token secrets, access tokens, rule file contents), and enforce a maximum logged payload size (e.g., truncate > 4KB). Also add a configuration switch to disable request/response logging or switch to metadata-only logging.

1. Entire response body read into memory without limits (resource exhaustion / DoS)
2. Files/locations: cmd/mcp-victoriametrics/tools/utils.go — GetTextBodyForRequest reads full body using io.ReadAll(resp.Body) (function definition at ~lines 219-239 in that file)
3. Severity: High (A05/A04)
4. Why: Endpoints like /api/v1/export or other endpoints may return large responses. io.ReadAll will attempt to read the entire response into memory; a large response can cause excessive memory use, OOM or degraded service for the MCP process. Attackers with ability to control query params (match, start/end) or cloud deployment responses could trigger large payloads.
5. Remediation: Replace io.ReadAll with a bounded reader (io.LimitReader) and/or stream results to the client, and enforce a maximum acceptable response size (configurable), returning an error if exceeded. For export endpoints, prefer streaming results back to the MCP client, or implement paged requests on the upstream API. Also apply per-request timeouts and monitoring.

5) Medium Severity Issues
1. Slice bounds/Indexing panic in alerts pagination (DoS via panic)
- File/line: cmd/mcp-victoriametrics/tools/alerts.go, slice operation around: filteredAlerts = filteredAlerts[int(offset):int(offset+limit)] (approx lines 156–166)
- Severity: Medium (A04/DOS) — can lead to panic inside a tool handler
- Why: offset and limit are float64 parameters that may be missing bounds checks. If offset or offset+limit exceed len(filteredAlerts) or are negative, the explicit slice operation will panic. Although server.WithRecovery() is used in main.go to recover panics in tool handlers, causing the panic to be converted to an error, repeated triggering may cause log flooding and service instability.
- Remediation: Validate/normalize offset and limit before slicing: clamp to [0, len(filteredAlerts)], convert float64 safely to int after bounds checks, ensure limit==0 means no limit, and handle offset >= len -> return empty slice. Add mcp.Min(0) constraints on these parameters during tool definition (and treat limit==0 specially) or perform defensive code checks.

1. Large / unbounded API responses returned directly to clients (resource exhaustion & information exposure)
2. Files: many tools call GetTextBodyForRequest (tools/utils.go) and then return that content. Examples: cmd/mcp-victoriametrics/tools/export.go (export endpoint) and many other tools (query, query_range, series, etc.). See search results for GetTextBodyForRequest usage.
3. Severity: Medium (A04/A05)
4. Why: multiple tools will forward API responses without size checks or streaming. The export endpoint (CSV/JSON) could be very large.

5. Remediation: For endpoints that may return large content (export), implement streaming to the MCP client and/or put a read size limit and an explicit error/notice when response is larger than acceptable.

6. Path/parameter validation too permissive for some path segments

7. Files/lines:
   • cmd/mcp-victoriametrics/tools/labelvalues.go: label_name registered with mcp.Pattern(^.+$) and later used in CreateSelectRequest path (used as URL path segment). Pattern is too permissive (line where mcp.WithString("label_name", ...) is defined).
8. Severity: Medium (A10 / SSRF surface and path manipulation)
9. Why: An overly permissive pattern may allow unexpected characters in path segments. While the entrypoint URL is controlled by config and JoinPath is used, permitting arbitrary characters without encoding/validation could lead to malformed requests or unintended URLs.
10. Remediation: Restrict label_name to a safe character class (e.g., [A-Za-z0-9_:-]+) or properly url.PathEscape user-provided path segments before calling url.JoinPath. Prefer using query parameters when possible. Add tests to assert proper URL construction for edge characters.

6) Low Severity Issues
1. Custom headers are applied after Authorization header and can overwrite it
- File/line: cmd/mcp-victoriametrics/tools/utils.go — CreateSelectRequest and CreateAdminRequest: req.Header.Set("Authorization", ...) followed by loop adding cfg.CustomHeaders() (no check for overriding Authorization) (around lines 18–36 and 40–60)
- Severity: Low (A05)
- Why: If VM_INSTANCE_HEADERS contains Authorization header, it overwrites the bearer token set earlier. This may be intended but should be explicit/documented and/or prevented for accidental override.
- Remediation: Either apply custom headers first and then set Authorization last to enforce configured/bearer token, or explicitly detect and disallow overriding Authorization in custom headers, or log when overriding occurs (with redaction). Document behavior.

1. In-memory cache of cloud access tokens lacks eviction
2. File/line: cmd/mcp-victoriametrics/tools/utils.go — cloudAccessTokenCache map with RWMutex (lines where declared)
3. Severity: Low (resource/maintenance)
4. Why: The cache grows per-deployment id without TTL or eviction; a malicious or misconfigured system might cause it to grow unbounded.

5. Remediation: Add a TTL and/or bounded size and eviction policy to the cache.

6. Authorization header set even when bearer token is empty

7. File/line: CreateSelectRequest/CreateAdminRequest set Authorization without checking for empty token.
8. Severity: Low
9. Why: Adds header "Authorization: Bearer " when token missing; harmless but noisy and could confuse upstream servers and logs.

10. Remediation: Only set Authorization header when token is non-empty.

11. Minor: minor variable naming inconsistency in rule_file.go (ruleFilenames vs content), not a security issue but confusing.

7) Key Risk Characteristics (exploitability, impact, likelihood, preconditions)
- Excessive logging of payloads (hooks/hooks.go): Exploitability: trivial (attacker just triggers tools that return sensitive data or sends crafted requests). Impact: high (secrets can leak to logs). Likelihood: high if logs are collected centrally. Preconditions: attacker needs privileged access to call tools that return sensitive data (MCP client must be authorized to talk to server). Business context: logs may be aggregated and retained—big risk.

• ReadAll of response bodies (utils.GetTextBodyForRequest): Exploitability: moderate (attacker can trigger queries that result in large responses). Impact: medium/high (OOM or service disruption). Likelihood: moderate. Preconditions: attacker can send tool calls that cause large response (e.g., export with broad match).

• Alerts pagination panic (alerts.go): Exploitability: trivial (attacker passes offset/limit values causing out-of-bounds). Impact: medium (panic recovered but causes error, DoS of that tool, logs). Likelihood: moderate (parameters are tool args). Preconditions: none beyond ability to call the tool.

• Permissive path segment (label_name): Exploitability: low/moderate (could cause malformed requests or strange upstream behavior). Impact: low. Preconditions: control of label_name parameter.

• Custom headers override Authorization: Exploitability: low (requires environment override by deployer). Impact: low/medium (unexpected auth behavior). Preconditions: attacker with ability to set env VM_INSTANCE_HEADERS or operator misconfiguration.

8) Positive Security Practices Observed
- Use of context.Context when creating requests (http.NewRequestWithContext) — allows upstream cancellations and server timeouts.
- Use of url.Parse and url.JoinPath for constructing upstream URLs (safer than string concatenation).
- Use of mutexes (RWMutex) to protect token and deployment info caches.
- Use of server.WithRecovery() in main.go to recover tool handler panics (defensive programming to avoid process crash).
- Parameter pattern constraints for many tool parameters (mcp.Pattern used to constrain many IDs, timestamps, etc.).
- Tests exist for many utility behaviors (good test coverage for routines like GetToolReqParam and GetSelectURL). Tests demonstrate careful behavior in typical cases.

9) Recommendations — Specific fixes with file:line references and OWASP context
(Use the repository line numbers as approximate references where exact line numbers may vary.)

High priority (fix within days):
1. Reduce logging of raw request/result payloads and add redaction
- Files: cmd/mcp-victoriametrics/hooks/hooks.go — functions AddBeforeAny, AddOnSuccess, AddOnError (where toJSON(message) and toJSON(result) are used).
- Severity/Category: High / A09
- Remediation: Replace toJSON(...) with a safe serializer that:
- Removes or redacts known sensitive fields (e.g., Authorization headers, token secrets, file contents, big binary blobs, request/response bodies). Examples: any field names like "secret", "token", "authorization", "credentials", or rule file contents returned by cloud APIs.
- Limits the length of data to log (truncate at a safe limit, e.g., 4 KB), and log a size/indicator that content was truncated.
- Make request/response logging configurable (enable/disable) via env flags (e.g., MCP_LOG_REQUESTS=false) and default to disabled or metadata-only.
- Add automated tests that simulate responses with secrets to ensure they are redacted. (OWASP: A09)

1. Limit response body size and support streaming
2. Files: cmd/mcp-victoriametrics/tools/utils.go — GetTextBodyForRequest uses io.ReadAll (approx lines 219-239).
3. Severity/Category: High / A05, A04

4. Remediation: Implement a max read size and/or streaming path. Example remediation:

   • Replace io.ReadAll(resp.Body) with io.ReadAll(io.LimitReader(resp.Body, MaxResponseBytes)) where MaxResponseBytes is configurable (e.g., 5MB), and return an explicit error if the upstream response exceeds this. For export endpoints where large content is expected, implement streaming via a different tool path that streams back to the client (not buffer entire body in memory).
   • Ensure timeouts and request cancelation are enforced (the request uses context already—keep it).

5. Fix slice bounds/pagination panic in alerts tool

6. File/line: cmd/mcp-victoriametrics/tools/alerts.go — the line that slices filteredAlerts[int(offset):int(offset+limit)] (approx around where limit/offset handled).
7. Severity/Category: Medium / A04
8. Remediation: Validate offset and limit before slicing and clamp to len(filteredAlerts). Example logic:
   • Convert offset and limit safely: oi := max(0, int(offset)), li := int(limit)
   • If limit <= 0 => treat as no limit
   • Compute end := oi + li; if end > len(filteredAlerts) { end = len(filteredAlerts) }
   • If oi >= len(filteredAlerts) => filteredAlerts = []
   • Use these bounds to slice without risk of panic.
   • Add mcp.Min(0) when registering the limit/offset tool params if supported, and reject negative values in the handler.

Medium priority (fix within 1–2 weeks):
4. Restrict/encode path segments coming from user input
- Files/lines: cmd/mcp-victoriametrics/tools/labelvalues.go (mcp.WithString("label_name", pattern ^.+$)) and all tools that append user-provided values to URL path segments (search for CreateSelectRequest(..., path... where path components contain tool args)
- Severity/Category: Medium / A10
- Remediation: Restrict label_name and other path components to a safe character class (for labels: ^[A-Za-z0-9_:\-]+$), or explicitly call url.PathEscape on user-provided segments before using them in URL path construction. Add tests for characters such as /, .., spaces, large unicode.

1. Avoid allowing custom headers to accidentally override Authorization
2. Files: cmd/mcp-victoriametrics/tools/utils.go — CreateSelectRequest and CreateAdminRequest.
3. Severity/Category: Low / A05

4. Remediation: Either apply custom headers before setting Authorization (so Authorization wins), or explicitly filter out Authorization from custom headers and log (redacted) the override. Document behavior in README and env var parsing.

5. Add eviction/TTL to cloud access token cache

6. File/line: cmd/mcp-victoriametrics/tools/utils.go — cloudAccessTokenCache map (declaration area)
7. Severity/Category: Low
8. Remediation: Implement TTL and/or LRU/bounded cache for cloudAccessTokenCache to avoid unbounded growth. Consider using a lock-protected map with timestamps or a small 3rd-party bounded cache with TTL.

Other recommendations / hygiene
- Only set Authorization header when token non-empty: cmd/mcp-victoriametrics/tools/utils.go CreateSelectRequest/CreateAdminRequest.
- Add explicit per-tool parameter validation where mcp.Pattern is currently permissive (e.g., label_name uses ^.+$). Add mcp.Min/Max for numeric parameters where appropriate (offset/limit on alerts should have Min 0).
- Add monitoring/alerting for error rates and request sizes so the operator can detect attempted DoS via large responses.
- Run dependency vulnerability scanning (govulncheck, github dependabot already is present) and upgrade dependencies regularly. (A06)

10) Next Tier Upgrade Plan (security integration tier)
Interpretation: I use a small maturity model: Bronze = basic functionality with minimal security hygiene, Silver = reasonable protections (input validation, secret handling, logging hygiene), Gold = hardened (rate-limits, streaming, secrets redaction, secure defaults), Reject = critical issues.

• Current likely tier: Bronze/Silver boundary

• Rationale: The integration follows many good practices (use of context, validation patterns, recovery middleware, caching, mutexes) but contains high-impact issues (unredacted logs and unbounded response reads). These issues prevent confidently calling the integration Silver.

• Target next tier: Silver -> Gold

• Prioritized actions to reach Silver (short term)
  1. Implement logging redaction and size limits in hooks (hooks/hooks.go). This addresses the highest severity issue (secret exposure) quickly.
  2. Implement maximum response body size and streaming for export endpoints (tools/utils.go). This prevents OOM/DoS from large upstream responses.
  3. Fix alerts pagination bounds checks (tools/alerts.go) to remove panic risk.
  4. Add stricter input patterns / path-escape for user-provided path components (label names and filenames) and add tests around edge characters.
• Additional actions to reach Gold (medium term)
  1. Add TTL/eviction for cloud token cache and instrument cache metrics.
  2. Add configurable caps for per-request payload size and a server-wide resource limit per-request or per-session.
  3. Add optional server-side rate limiting and per-session quotas for expensive tools (export, query_range large ranges).
  4. Harden logging configuration defaults to metadata-only and make redaction default-on.
  5. Schedule regular dependency vulnerability scans and upgrade critical dependencies.

Appendix: Concrete code pointers
- main server initialization: cmd/mcp-victoriametrics/main.go — server.NewMCPServer(..., server.WithRecovery(), server.WithLogging(), ...). Recovery helps avoid process crash but does not prevent DoS (line near top of main.go).
- GetTextBodyForRequest: cmd/mcp-victoriametrics/tools/utils.go — io.ReadAll(resp.Body) and no size limit. (approx func start at line ~219)
- CreateSelectRequest/CreateAdminRequest: cmd/mcp-victoriametrics/tools/utils.go — NewRequestWithContext and header handling (Authorization then custom headers). (approx lines 18–36 and 40–60)
- getBearerToken: cmd/mcp-victoriametrics/tools/utils.go — cloud token discovery, RevealDeploymentAccessToken usage and in-memory caching. (approx lines 100–160)
- cloud cache declarations: cmd/mcp-victoriametrics/tools/utils.go — cloudAccessTokenCache and cloudDeploymentInfoCache declarations near top of file.
- Alerts pagination slice: cmd/mcp-victoriametrics/tools/alerts.go — filteredAlerts = filteredAlerts[int(offset):int(offset+limit)] (approx lines 156–166)
- Logging hooks: cmd/mcp-victoriametrics/hooks/hooks.go — AddBeforeAny/AddOnSuccess/AddOnError use toJSON(message) and toJSON(result). (around when hooks added)
- Label name pattern: cmd/mcp-victoriametrics/tools/labelvalues.go — mcp.WithString("label_name", mcp.Pattern(^.+$)) (pattern too permissive)

Closing summary
Overall the MCP integration is well-organized and uses many good practices (context on requests, parameter patterns, mutex-protected caches, recovery middleware). The most urgent issues are two high-severity problems: (1) logging of entire requests/results (which may leak secrets) and (2) reading upstream response bodies into memory without any size limit (risk of OOM/DoS). Medium severity issues (panic via slice indexing, permissive path segments) should also be addressed promptly. Fixing these issues along with modest enhancements (redaction, streaming, caching eviction) will raise the integration to a robust Silver/Gold posture.

If you would like, I can produce suggested code patches for the highest-priority fixes (safe logging/redaction wrapper and bounded read for GetTextBodyForRequest) including tests and small API changes.

Summary

Security Score: 80/100 (Silver)
Static analysis found 0 high, 0 medium, and 0 low severity issues.
Build step skipped for safety.
No automated tests detected.