← Back to results
Vulnerability record · public intelligence
CVE-2025-53355
HIGH

MCP Server Kubernetes vulnerable to command injection in several tools

Published Jul 8, 2025 · Updated Oct 23, 2026 · Also known as GHSA-gjv4-ghm7-q58q

Severity · CVSSHIGH · 7.5
Known exploitationNot listed
EPSS / likelihood2.16%
QFinch risk score10 / 100

Original summary

Normalized public record · Updated Oct 23, 2026

MCP Server Kubernetes vulnerable to command injection in several tools

Publisher and source text is retained separately from QFinch interpretation.

QFinch assessment

A command injection vulnerability exists in the mcp-server-kubernetes MCP Server. The vulnerability is caused by the unsanitized use of input parameters within a call to childprocess.execSync, enabling an attacker to inject arbitrary system commands. Successful exploitation can lead to remote code execution under the server process's privileges. The server constructs and executes shell commands using unvalidated user input directly within command-line strings. This introduces the possibility of shell metacharacter injection (|, >, &&, etc.).

Potential impact

Command Injection / Remote Code Execution (RCE)

Technical context

The MCP Server exposes tools (kubectlscale, kubectlpatch , explainresource, etc) to perform several kubernetes operations. An MCP Client can be instructed to execute additional actions for example via prompt injection when asked to read pod logs. Below some example of vulnerable code and different ways to test this vulnerability including a real example of indirect prompt injection that can lead to arbitrary command injection.

Evidence: public source records

Affected products

Affected scope reported by the available public evidence
Affected package, product or rangeFix status
Consult the referenced vendor advisory for affected versions.Consult source advisory

Matching a version is only one part of assessing exposure. QFinch has not assessed your environment on this public page.

Remediation

Apply the vendor-supported fixed release or mitigation, then verify the affected component is no longer reachable.

  1. Confirm the affected product and reachable code path exist in your environment.
  2. Apply the vendor-supported patch or mitigation from the primary advisory.
  3. Rescan the exact deployed revision and retain verification evidence.
Review primary references

Evidence coverage

CVENVDOSVEPSSGHSA
SSVC priority
MEDIUM
Confidence
10%
Aliases
GHSA-gjv4-ghm7-q58q

Scores appear only when corresponding evidence exists. Missing data is never interpreted as zero risk.

Sources and record history

  1. Security advisory ↗
  2. Patch commit ↗
  3. Patch commit ↗

Record history

Published Jul 8, 2025 · Last refreshed Oct 23, 2026