An OTP-enabled authenticated user who cannot use the HTTP configuration mutation endpoints without a valid secure session can still mutate Nginx configuration through /mcp and /mcp_message using only ordinary authentication.
The HTTP configuration mutation surface is explicitly grouped behind middleware.RequireSecureSession(). By contrast, the MCP endpoints are exposed with only middleware.AuthRequired(). The MCP server exposes configuration mutation tools including nginx_config_add and nginx_config_modify, so OTP-enabled users gain an alternate path around the intended step-up requirement.
Relevant code paths:
This is a security-control bypass rather than a missing feature. The product already established that OTP-enabled users should complete a secure session before high-impact configuration mutations are accepted on the HTTP path.
I verified this locally in an isolated environment with a temporary end-to-end harness that exercised the real /mcp and /mcp_message routes.
What the executed test did:
true) to avoid touching the host./mcp and /mcp_message routes./mcp with the JWT and no X-Secure-Session-ID./mcp_message.nginx_config_add tool over /mcp_message.mcp-bypass.conf in the managed config directory without any secure-session step-up.Observed result from the actual local verification:
X-Secure-Session-ID.OTP-enabled accounts lose the intended step-up protection for high-impact Nginx configuration changes when MCP is enabled. A user who should be blocked until re-authenticating can still create or modify configuration files and trigger reload behavior through MCP.
{
"cwe_ids": [
"CWE-288"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-15T20:14:10Z",
"nvd_published_at": "2026-10-12T21:17:22Z",
"severity": "HIGH"
}