CVE-2026-55640: Nextcloud MCP Server Auth Bypass Vulnerability

CVE-2026-55640 Overview

CVE-2026-55640 is a missing authentication vulnerability in Nextcloud MCP Server, a Model Context Protocol (MCP) server that connects AI assistants to Nextcloud instances. Versions prior to 0.117.2 expose the POST /webhooks/nextcloud endpoint without authentication because the WEBHOOK_SECRET environment variable defaults to None and startup validation does not require it. A remote unauthenticated attacker can submit forged webhook payloads that specify arbitrary user identifiers, triggering deletion or re-indexing of vector embeddings for any user and destroying the semantic search index. The issue is fixed in version 0.117.2.

Critical Impact
Unauthenticated network attackers can delete or corrupt Qdrant vector embeddings for any user and destroy the semantic search index by sending forged webhook events.

Affected Products

Nextcloud MCP Server versions prior to 0.117.2
Deployments where WEBHOOK_SECRET is unset (default configuration)
Instances with vector sync and Qdrant integration enabled

Discovery Timeline

2026-08-25 - CVE-2026-55640 published to NVD
2026-08-25 - Last updated in NVD database

Technical Details for CVE-2026-55640

Vulnerability Analysis

The vulnerability is a Missing Authentication for Critical Function issue [CWE-306] in nextcloud_mcp_server/vector/webhook_receiver.py. The handle_nextcloud_webhook() handler processes incoming webhook events but performs no authentication check when WEBHOOK_SECRET is unset. Because the default value is None and the application startup does not enforce that the secret be defined, production deployments can silently expose an unauthenticated endpoint to the network.

The payload parser at nextcloud_mcp_server/vector/webhook_parser.py reads the payload["user"]["uid"] field and passes it to Qdrant operations without cross-checking against an authenticated session identity. This trust boundary violation lets an attacker act as any Nextcloud user for vector-index operations.

Root Cause

The root cause is an insecure default: WEBHOOK_SECRET defaults to None, and the route mounts regardless. The receiver treats attacker-supplied fields inside the JSON body as authoritative user identity, coupling untrusted network input directly to backend index-mutation calls.

Attack Vector

An attacker with network reachability to the MCP server sends a crafted HTTP POST to /webhooks/nextcloud with a JSON body containing a chosen user.uid. The server then performs Qdrant delete or re-index operations against that user's embeddings. Repeated forged deletion events can wipe out the entire semantic search index.

text

# Security patch in env.sample (Source: https://github.com/cbcoutinho/nextcloud-mcp-server/commit/4fc2b10945108cf1008ec9698291de6706ffcb73)
 #
 # Max queued documents (default: 10000)
 #VECTOR_SYNC_QUEUE_MAX_SIZE=10000
+#
+# Webhook receiver authentication (REQUIRED for webhook-driven sync).
+# Security (GHSA-8vh3-g2qg-2h2c): the /webhooks/nextcloud receiver trusts the
+# user id in the payload and feeds it to Qdrant, so it must be authenticated.
+# When WEBHOOK_SECRET is unset the route is NOT mounted and vector sync falls
+# back to the polling scanner. When set, the receiver requires
+# `Authorization: Bearer <secret>` and webhook registration injects it.
+# Generate one with: python -c "import secrets; print(secrets.token_urlsafe(32))"
+#WEBHOOK_SECRET=

The patch changes behavior so that when WEBHOOK_SECRET is unset the route is not mounted at all, and when set the receiver requires an Authorization: Bearer <secret> header.

Detection Methods for CVE-2026-55640

Indicators of Compromise

HTTP POST requests to /webhooks/nextcloud lacking an Authorization: Bearer header on vulnerable deployments
Unexpected deletion or bulk re-indexing operations recorded in Qdrant logs against user collections
Sudden drops in semantic-search recall or empty query results after previously healthy indexes
Webhook payloads containing user.uid values not matching any known active Nextcloud user session

Detection Strategies

Inspect reverse-proxy and application logs for requests to /webhooks/nextcloud from sources outside the Nextcloud instance
Correlate webhook receipt timestamps with Qdrant collection mutation events to identify unauthorized index changes
Query the management API webhooks_enabled field introduced in the patch to confirm whether the receiver is gated on WEBHOOK_SECRET

Monitoring Recommendations

Alert on any request to /webhooks/nextcloud missing a valid bearer token
Track Qdrant delete operation volume and baseline against normal sync activity
Monitor MCP server version and startup configuration to ensure WEBHOOK_SECRET is defined in all environments

How to Mitigate CVE-2026-55640

Immediate Actions Required

Upgrade Nextcloud MCP Server to version 0.117.2 or later
Set WEBHOOK_SECRET to a strong random value generated with python -c "import secrets; print(secrets.token_urlsafe(32))"
Restrict network access to the /webhooks/nextcloud endpoint to trusted Nextcloud sources only
Audit Qdrant collections for evidence of unauthorized deletions and re-index affected users

Patch Information

The fix is in Nextcloud MCP Server v0.117.2. The security advisory GHSA-8vh3-g2qg-2h2c and remediation commit require WEBHOOK_SECRET for the receiver to be mounted and enforce Authorization: Bearer <secret> on all webhook requests.

Workarounds

If immediate upgrade is not possible, block external access to /webhooks/nextcloud at the reverse proxy or firewall layer
Disable vector sync and rely on the polling scanner until the patched version is deployed
Place the MCP server behind an authenticating gateway that enforces mutual TLS or bearer token validation

bash

# Configuration example - set a strong webhook secret before starting the MCP server
export WEBHOOK_SECRET="$(python -c 'import secrets; print(secrets.token_urlsafe(32))')"

# Verify the receiver is gated correctly via the management API
curl -s http://localhost:8000/api/management/status | jq '.webhooks_enabled'
# Expected output: true