Description

Nextcloud MCP Server is a production-ready MCP server that connects AI assistants to a Nextcloud instance. Prior to 0.117.2, the POST /webhooks/nextcloud endpoint in nextcloud_mcp_server/vector/webhook_receiver.py has no authentication by default because WEBHOOK_SECRET defaults to None and startup validation does not require it. When WEBHOOK_SECRET is unset, handle_nextcloud_webhook() accepts unauthenticated requests. The payload["user"]["uid"] field parsed in nextcloud_mcp_server/vector/webhook_parser.py is attacker-controlled and is used without an authenticated-session cross-check for Qdrant operations, allowing a network attacker to delete or trigger re-indexing of vector embeddings for any user and to destroy the semantic search index by sending forged deletion events. This issue is fixed in version 0.117.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-08-25T16:16:55.810Z",
  "pubdate": "2026-08-25T16:16:55.810Z",
  "executiveSummary": "Nextcloud MCP Server versions prior to 0.117.2 contain a critical authentication bypass vulnerability in the webhook processing endpoint.\nThe vulnerability originates from a failure to enforce the WEBHOOK_SECRET configuration, causing the POST /webhooks/nextcloud endpoint to default to an unauthenticated state upon service startup.\nA remote, unauthenticated attacker can exploit this to perform arbitrary operations on the vector database by crafting malicious webhook payloads.\nImpact includes the unauthorized deletion of vector embeddings, forced re-indexing operations, and the corruption or destruction of semantic search indexes for any user within the Nextcloud instance.\nThis flaw allows unauthorized manipulation of sensitive data stored in Qdrant, potentially leading to a complete denial-of-service for the semantic search functionality.\nThe risk is significant due to the lack of required authentication, allowing any network-adjacent attacker to perform administrative-level operations on the vector storage component without prior knowledge of system credentials.",
  "technicalDetails": "The vulnerability is located in the nextcloud_mcp_server/vector/webhook_receiver.py file within the handle_nextcloud_webhook() function. The root cause is a permissive default configuration where the WEBHOOK_SECRET environment variable defaults to None. Because the server's startup validation logic does not mandate the presence of a secret, the authentication mechanism is effectively bypassed for all incoming POST requests to the /webhooks/nextcloud endpoint.\nExploitation is achieved by transmitting a crafted JSON payload to the unauthenticated webhook receiver. The application logic utilizes the payload['user']['uid'] field, which is parsed by nextcloud_mcp_server/vector/webhook_parser.py, to facilitate operations within the Qdrant vector database. Critically, the implementation fails to perform an authenticated-session cross-check between the incoming webhook request and the associated user identity.\nThe attack flow follows these steps: 1) The attacker identifies a target Nextcloud MCP Server instance with an unset WEBHOOK_SECRET. 2) The attacker crafts an arbitrary webhook event containing a target user's UID. 3) The attacker sends this payload to the /webhooks/nextcloud endpoint. 4) The application processes the payload, trusting the attacker-supplied UID. 5) The application executes backend commands against Qdrant, such as index deletions or re-indexing triggers, using the context of the spoofed user. 6) The semantic search index is subsequently corrupted or purged based on the malicious event instructions.\nThis vulnerability effectively grants an external actor the ability to interact with the Qdrant backend as if they were a legitimate, privileged user, bypassing all internal access controls. The reliance on unvalidated, user-controlled input for administrative backend operations introduces a high-severity flaw in data integrity and availability.\nThe vulnerability affects all versions prior to 0.117.2 and requires no specific authentication or authorization, as the system fails to verify the identity of the webhook source entirely."
}