Presenton EUVD-2026-40414

Exploitation requires Presenton to be running in server or Docker deployment mode - the Electron desktop build is not affected. Session authentication must be enabled via the AUTH_USERNAME/AUTH_PASSWORD environment variables; deployments without these variables set (i.e., running without authentication) are not specifically affected by this bypass since there is no auth layer to bypass. The /mcp endpoint must be reachable from the attacker's network, which is the expected posture for publicly exposed Docker deployments. No authentication, user interaction, or special client software is required from the attacker's side - standard HTTP access suffices. Exploitation is bounded by: (1) server/Docker deployment mode only, (2) session auth must be configured, and (3) network reachability to /mcp.

The official CVSS 3.1 score of 6.5 with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L correctly captures the low-complexity, network-accessible, unauthenticated nature of the attack, but modestly understates the practical business impact: LLM API key consumption can result in significant financial harm and operational disruption to the operator beyond what A:L conventionally implies. The C:N assignment is defensible - the attacker does not read existing sensitive data - though the auto-minted token itself constitutes a credential exposure risk not reflected in the score. No EPSS score was provided in the input data, so exploitation probability cannot be quantitatively assessed. A publicly available PoC (GitHub issue #678) meaningfully raises the realistic exploitation likelihood relative to what the 6.5 base score alone would suggest; however, exploitation is NOT confirmed in CISA KEV, so this should not be characterized as actively exploited in the wild. The exploitability is constrained by deployment mode: only server and Docker instances with AUTH_USERNAME/AUTH_PASSWORD configured are vulnerable - the Electron build is not. This narrows the realistic at-risk population, but operators who have specifically enabled authentication (presumably because they are exposing the service publicly) are precisely the ones most impacted.

An attacker scans for internet-exposed Presenton Docker deployments and sends a crafted HTTP POST to /mcp without any credentials. The MCP server auto-mints a session token for the configured operator account and processes the request; the attacker calls generate_presentation with attacker-controlled parameters, causing the server to make repeated calls to the operator's configured LLM API (e.g., OpenAI), exhausting quota and accruing costs. A publicly available proof-of-concept demonstrating this flow exists at https://github.com/presenton/presenton/issues/678.