Default-Open Configuration

A security antipattern where a service runs in its most permissive configuration by default, on the assumption that operators will manually restrict it — typically resulting in many deployments that retain the permissive defaults indefinitely.

Default-Open Configuration is a security antipattern where a service runs in its most permissive configuration out of the box — open ports, no authentication required, full feature set enabled — on the implicit assumption that operators will manually restrict the configuration before any exposure matters. The antipattern is well-documented in classical software security and is increasingly common in AI agent and MCP development tooling, where the convenience of "just works locally" is prioritised over explicit security defaults.

The structural problem is empirical: most operators do not change defaults. Even sophisticated developers leave development tools in their installed configuration if the tool works. The published CVE record across decades of software contains many findings whose root cause is not a code bug but a configuration choice — bind 0.0.0.0 instead of bind 127.0.0.1, auth: none instead of auth: required, enable_shell: true instead of enable_shell: false. Each individual finding is fixable with a one-line config change. The aggregate pattern is fixable only by changing what defaults ship with the software.

How Default-Open Configuration Manifests in MCP Tools

CVE-2025-49596 in MCP Inspector is the worked example. Inspector shipped with its proxy bound to a local port, no authentication required, full spawn capability enabled — the most permissive configuration possible, on the implicit assumption that "developers will only run this locally on machines they trust." That assumption breaks under any of the now-common local-port routing primitives (DNS rebinding, malicious browser extensions, container-network sharing). The patch was not new code logic; it was a defaults change — authentication is now required, and operators must take an explicit action to disable it.

The pattern is repeated across MCP development tooling and a substantial fraction of agent-runtime defaults. Default-open is a property of MCP server distributions that ship with example configurations granting filesystem access to entire user home directories. It is a property of agent-host installations that auto-trust any server registered through the manifest. It is a property of cloud-hosted agent platforms that enable optional debug endpoints by default.

Defensive Posture

The fix at the design level is to ship with the most restrictive defaults that still let the software run usefully. Every additional capability — exec primitives, network exposure, credential access, debug endpoints — should require explicit operator opt-in rather than explicit operator opt-out. The cost is some friction during initial setup; the benefit is that operators who never look at defaults still ship safe configurations.

For consumers of software with default-open configuration, the operational fix is to audit every default before deployment and change any that grant unnecessary capability. The MCP Security Checklist lists the specific defaults that should be reviewed for every connected MCP component.

Need expert guidance on Default-Open Configuration?

Our team at Zealynx has deep expertise in blockchain security and DeFi protocols. Whether you need an audit or consultation, we're here to help.

Get a Quote