Nextcloud MCP Server CVE-2026-55640

Requires that the webhook receiver be active and reachable AND that WEBHOOK_SECRET be unset - which is the default in versions <= 0.117.1, so no special configuration is needed beyond the endpoint being network-reachable to the attacker (advisory cites port 8000). No credentials, no user interaction, and no authenticated session are needed: the attacker fully controls the target identity via the payload's user.uid field. What LIMITS exploitation: the /webhooks/nextcloud endpoint must actually be exposed to the attacker's network path, and deployments that never mounted the webhook receiver (polling-only) or that sit behind a proxy restricting the endpoint to the Nextcloud host are not exploitable. On patched 0.117.2 the condition is closed entirely because an unset secret un-mounts the route and a set secret enforces Bearer auth.

This is a genuine high-priority issue for anyone who has enabled webhook-based vector sync, but its blast radius is bounded to search-index integrity/availability rather than data confidentiality. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:N/I:H/A:H, score 9.1) is internally consistent with the description: no authentication, low complexity, no user interaction, and impact limited to corrupting/destroying vector data - confidentiality is correctly N since the attacker cannot read embeddings, only delete or re-queue them. The published PoC (no credentials, works against the default configuration) makes weaponization trivial, so real-world exploitability tracks the high CVSS rather than discounting it. No EPSS score, SSVC decision, or KEV entry was supplied; absent EPSS I cannot quantify exploitation probability, and absence from KEV means no confirmed active exploitation - treat exploitation likelihood as inferred-high from PoC availability, not measured. A key limiting factor tempers the raw score: exploitation requires that the webhook receiver actually be reachable and, in vulnerable versions, that WEBHOOK_SECRET was left unset (the default) AND the endpoint exposed to the attacker's network (advisory cites port 8000), so hardened or polling-only deployments are not exposed. Because impact is destructive to a rebuildable index (recoverable via full re-scan) rather than to primary user data, operators who expose the endpoint should patch urgently while those relying solely on the polling scanner are unaffected.

An attacker who can reach the MCP server's webhook port (default 8000) sends an unauthenticated POST /webhooks/nextcloud with a forged BeforeNodeDeletedEvent payload setting user.uid to any target user and a chosen document id, and the server passes that identity straight to Qdrant, deleting the victim's embeddings. Scripting the request across a range of document IDs and user IDs destroys the entire semantic-search index, forcing a full re-scan to recover. A no-credentials PoC demonstrating exactly this is published in the GHSA advisory.