Impact
McpAuditLogger recorded MCP tool invocations verbatim. The tool arguments, the resolved request URL including its query string, the request body and the downstream response body were all stored and logged without any filtering.
Where a tool declares header, query or body parameters that carry credentials — Authorization, API keys, session cookies, passwords, tokens — those values were written in clear text into the application log and retained in the in-memory audit store served by GET /api/mcp-admin/audit. Personal data present in request or response bodies was retained the same way.
The exposure is twofold: credentials reach the application's log output, where they are typically shipped to a log aggregator with a much broader audience than the application itself; and they are readable through the audit endpoint, which in the affected versions was active by default and carries no authentication or authorization of its own.
An application is affected only if one of the MCP starters is on the classpath. In the affected versions the MCP surface was active by default once the starter was present.
Patches
Fixed in 3.1.1. Redaction is centralized in McpAuditLogger and applied before an audit event is logged or stored. Secret-shaped keys — authorization, password, token, api-key, cookie and similar — are masked across the tool arguments, the request URL query string, and the request and response bodies. The behaviour is controlled by the new springdoc.ai.mcp.audit.redact property, enabled by default.
The same release also makes the MCP surface opt-in, requiring springdoc.ai.mcp.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, or remove the MCP starter from the classpath. Rotate any credential that may have been captured in existing logs or audit stores.
References
28259c082 – redact secrets from MCP audit events
Credits
Reported by Scrutineer (Alpha-Omega).
Impact
McpAuditLoggerrecorded MCP tool invocations verbatim. The tool arguments, the resolved request URL including its query string, the request body and the downstream response body were all stored and logged without any filtering.Where a tool declares header, query or body parameters that carry credentials —
Authorization, API keys, session cookies, passwords, tokens — those values were written in clear text into the application log and retained in the in-memory audit store served byGET /api/mcp-admin/audit. Personal data present in request or response bodies was retained the same way.The exposure is twofold: credentials reach the application's log output, where they are typically shipped to a log aggregator with a much broader audience than the application itself; and they are readable through the audit endpoint, which in the affected versions was active by default and carries no authentication or authorization of its own.
An application is affected only if one of the MCP starters is on the classpath. In the affected versions the MCP surface was active by default once the starter was present.
Patches
Fixed in 3.1.1. Redaction is centralized in
McpAuditLoggerand applied before an audit event is logged or stored. Secret-shaped keys — authorization, password, token, api-key, cookie and similar — are masked across the tool arguments, the request URL query string, and the request and response bodies. The behaviour is controlled by the newspringdoc.ai.mcp.audit.redactproperty, enabled by default.The same release also makes the MCP surface opt-in, requiring
springdoc.ai.mcp.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, or remove the MCP starter from the classpath. Rotate any credential that may have been captured in existing logs or audit stores.References
28259c082– redact secrets from MCP audit eventsCredits
Reported by Scrutineer (Alpha-Omega).