Impact
Every MCP auto-configuration gate was declared with @ConditionalOnProperty(matchIfMissing = true), while the backing fields on SpringDocAiProperties — enabled and dashboardEnabled — defaulted to false.
The practical consequence is that simply adding an MCP starter to the classpath activated the entire MCP surface, with no configuration and no explicit decision by the integrator:
/mcp, the MCP transport, with every operation of the application's OpenAPI document registered as a callable tool
/api/mcp-admin/**, including the tool-execution and audit routes
/mcp-ui/**, the dashboard
None of these routes carries authentication or authorization of its own; securing them is the integrating application's responsibility, and an integrator who never enabled the feature has no reason to know they exist. The property getters compounded this by returning false, so an operator inspecting configuration would be told the MCP surface was off while it was in fact serving requests.
This insecure default is the precondition that made the other MCP issues fixed in this release remotely reachable.
Patches
Fixed in 3.1.1. All MCP auto-configuration gates — SpringDocAiAutoConfiguration, SpringDocAiProperties, McpDashboardAutoConfiguration, McpWebMvcAiAutoConfiguration and McpWebFluxAiAutoConfiguration — moved to matchIfMissing = false, so the conditionals now agree with the property defaults. SpringDocAiEnvironmentPostProcessor likewise only forces springdoc.pre-loading-enabled when MCP is explicitly enabled.
Upgrade note. MCP is now opt-in. To keep using it, set:
springdoc.ai.mcp.enabled=true
springdoc.ai.mcp.dashboard-enabled=true
The Spring Boot 3 line (2.x) is not affected: the MCP starters do not exist on that branch.
Workarounds
Set springdoc.ai.mcp.enabled=false explicitly, or restrict /mcp, /mcp-ui/** and /api/mcp-admin/** in your SecurityFilterChain.
References
Credits
Reported by Scrutineer (Alpha-Omega).
Impact
Every MCP auto-configuration gate was declared with
@ConditionalOnProperty(matchIfMissing = true), while the backing fields onSpringDocAiProperties—enabledanddashboardEnabled— defaulted tofalse.The practical consequence is that simply adding an MCP starter to the classpath activated the entire MCP surface, with no configuration and no explicit decision by the integrator:
/mcp, the MCP transport, with every operation of the application's OpenAPI document registered as a callable tool/api/mcp-admin/**, including the tool-execution and audit routes/mcp-ui/**, the dashboardNone of these routes carries authentication or authorization of its own; securing them is the integrating application's responsibility, and an integrator who never enabled the feature has no reason to know they exist. The property getters compounded this by returning
false, so an operator inspecting configuration would be told the MCP surface was off while it was in fact serving requests.This insecure default is the precondition that made the other MCP issues fixed in this release remotely reachable.
Patches
Fixed in 3.1.1. All MCP auto-configuration gates —
SpringDocAiAutoConfiguration,SpringDocAiProperties,McpDashboardAutoConfiguration,McpWebMvcAiAutoConfigurationandMcpWebFluxAiAutoConfiguration— moved tomatchIfMissing = false, so the conditionals now agree with the property defaults.SpringDocAiEnvironmentPostProcessorlikewise only forcesspringdoc.pre-loading-enabledwhen MCP is explicitly enabled.Upgrade note. MCP is now opt-in. To keep using it, set:
The Spring Boot 3 line (
2.x) is not affected: the MCP starters do not exist on that branch.Workarounds
Set
springdoc.ai.mcp.enabled=falseexplicitly, or restrict/mcp,/mcp-ui/**and/api/mcp-admin/**in yourSecurityFilterChain.References
fba941bc9– make the MCP surface opt-inCredits
Reported by Scrutineer (Alpha-Omega).