Topic starter
02/08/2026 11:42 am
TL;DR: Arguments in MCP stdio workflows can still reach OS-level commands after sanitisation, OXSecurity found, leaving command execution and server takeover possible in Flowise and Upsonic. MCP runtimes need tighter isolation because filtering alone does not contain delegated execution paths.
Editorial analysis by NHI Mgmt Group, based on content published by OXSecurity: “Flowise (CVE-2026-40933) & Upsonic (CVE-2026-30625): What to do when best practice isn’t enough?”.
Key questions
Q: Why do command-enabled MCP servers increase risk for API keys and host access?
A: Because the server often inherits the privileges of the host process that runs it.
Q: What are the signs that MCP credential handling is too exposed?
A: The warning signs are API keys, tokens and session details stored in config files, on laptops or in shared environment variables, especially when key management is not separated from data storage.
Q: What breaks when MCP STDIO input sanitisation is the only control in place?
A: Sanitisation breaks because it only filters the string presented to the application, not the later execution path created by language runtimes and subprocess calls.
Practitioner guidance
- Isolate MCP STDIO servers in a sandbox Run any code-executing MCP STDIO component in a restricted environment that cannot read broad host secrets, reach the wider network, or inherit unnecessary filesystem access.
- Disable command execution by default Remove STDIO command execution unless a business case explicitly requires it, then re-enable only for approved use cases with documented ownership.
- Require authentication before STDIO access Place strong authentication and access controls in front of any MCP endpoint that can invoke commands so unauthorised users cannot reach the execution path.
Bottom line: MCP STDIO command paths can remain exploitable even after sanitisation, because arguments may still resolve into OS-level execution.
Glossary terms: MCP stdio, Command execution boundary, Runtime Isolation, Delegated Execution
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/08/2026 12:54 pm
Command sanitisation is a syntax control, not an execution control: This article shows that approving characters and command names does not guarantee safety when runtime arguments can still resolve into OS commands. That means the control boundary was drawn around the wrong layer. For identity and access teams, the practical conclusion is that execution authority must be governed where it is exercised, not where the text first arrives.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams decide whether to keep STDIO command execution enabled?
A: Keep it disabled unless the use case genuinely requires command execution and the server can be isolated, authenticated, and tightly scoped. If the feature is not operationally necessary, the safer decision is to remove the attack surface rather than try to police every input edge case.
👉 Read our full editorial: MCP stdio sanitization fails when arguments reach OS commands