CVE-2026-39884
Argument Injection in mcp-server-kubernetes Port_Forward Enables Service Exposure
Publication date: 2026-04-15
Last updated on: 2026-04-23
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| suyogs | mcp-server-kubernetes | to 3.5.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-88 | The product constructs a string for a command to be executed by a separate component in another control sphere, but it does not properly delimit the intended arguments, options, or switches within that command string. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows unauthorized exposure of internal Kubernetes services to the network by injecting arbitrary kubectl flags, which can lead to unauthorized access to sensitive data or systems.
Such unauthorized exposure and potential data access could result in non-compliance with data protection regulations like GDPR and HIPAA, which require strict controls on access to sensitive information and systems.
By bypassing namespace restrictions and exposing internal services, the vulnerability increases the risk of data breaches and unauthorized data processing, which are critical compliance concerns under these standards.
Can you explain this vulnerability to me?
CVE-2026-39884 is an argument injection vulnerability in the port_forward tool of the mcp-server-kubernetes package (versions 3.4.0 and prior). The vulnerability occurs because the tool constructs a kubectl command by concatenating user-controlled inputs into a single string and then naively splitting it on spaces before passing it to the spawn() function. This approach treats every space in user inputs as an argument boundary, allowing an attacker to inject arbitrary kubectl flags.
Specifically, user-controlled fields such as namespace, resourceType, resourceName, localPort, and targetPort can contain spaces that lead to injection of additional kubectl command-line arguments. This differs from safer methods used elsewhere in the codebase that pass arguments as arrays, preventing injection.
How can this vulnerability impact me? :
This vulnerability can have several serious impacts:
- Exposure of internal Kubernetes services to the network by injecting flags like --address=0.0.0.0, which causes kubectl port-forward to bind to all network interfaces instead of just localhost.
- Bypassing namespace restrictions through injection of additional -n flags, allowing cross-namespace targeting and access to resources in other namespaces.
- Indirect exploitation via prompt injection attacks against AI agents connected to the MCP server, where malicious pod names or logs can cause unintended command execution.
Overall, the vulnerability can lead to unauthorized network exposure of internal Kubernetes services, compromising confidentiality, integrity, and availability.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by inspecting the usage of the port_forward tool in mcp-server-kubernetes versions 3.4.0 and prior, specifically looking for kubectl port-forward commands constructed via string concatenation with user-controlled inputs.
One way to detect exploitation attempts is to monitor for kubectl port-forward commands that include suspicious or unexpected flags such as '--address=0.0.0.0' or multiple '-n' namespace flags, which indicate argument injection.
Suggested commands to detect such activity include:
- Use process monitoring tools (e.g., ps, pgrep) to find running kubectl port-forward commands with unusual arguments.
- Run commands like `ps aux | grep 'kubectl port-forward'` and inspect for injected flags.
- Check logs or audit trails for invocations of port_forward with suspicious namespace or resourceName values containing spaces or additional flags.
- Network monitoring tools can be used to detect unexpected exposure of internal Kubernetes services on all interfaces (0.0.0.0). For example, `netstat -tuln | grep <port>` to check if port-forward is listening on external interfaces.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade mcp-server-kubernetes to version 3.5.0 or later, where the vulnerability has been fixed by replacing string concatenation with safe array-based argument passing.
Until the upgrade can be applied, restrict access to the port_forward tool and limit user inputs to trusted values to reduce the risk of argument injection.
Additionally, monitor and audit usage of kubectl port-forward commands to detect and respond to suspicious activity.
Consider applying network-level controls to prevent exposure of internal Kubernetes services to external networks.