CVE-2026-55640 is a critical-severity (CVSS 9.1) Missing Authentication vulnerability in nextcloud-mcp-server. A fix is available for nextcloud-mcp-server — see the affected versions and patch details below.
Nextcloud MCP Server: Unauthenticated `POST /webhooks/nextcloud` allows arbitrary vector data deletion when `WEBHOOK_SECRET` is unset ( default )
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-55640.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-55640 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 384,993 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
nextcloud-mcp-serverReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The POST /webhooks/nextcloud endpoint has no authentication by default: WEBHOOK_SECRET defaults to None and is never required by startup validation. When unset, the receiver accepts any unauthenticated POST. The user_id is taken directly from the attacker-supplied payload and passed to Qdrant, allowing an unauthenticated attacker to delete or corrupt vector embeddings for any user.
Details
Vulnerable file: nextcloud_mcp_server/vector/webhook_receiver.py, function handle_nextcloud_webhook(), lines 55-67
Root cause 1: Auth check is guarded by if secret: - skipped entirely when WEBHOOK_SECRET is unset.
Root cause 2: webhook_secret: str | None = None in config - no startup validator enforces it, even when vector sync is enabled.
Trusted field: payload["user"]["uid"] in webhook_parser.py is used as-is for all Qdrant operations - no cross-check against an authenticated session.
webhook_receiver.py, lines 55-67:
secret = get_settings().webhook_secret # None by default
if secret: # skipped entirely when unset
... validate Bearer header ...
else:
_warn_missing_secret_once() # just logs, still processes
webhook_parser.py, line 57:
user_id = payload["user"]["uid"] # attacker-controlled
PoC
No credentials required. Works on any deployment where WEBHOOK_SECRET is not explicitly set (the default).
POST /webhooks/nextcloud
Content-Type: application/json
{
"event": {
"class": "OCP\\Files\\Events\\Node\\BeforeNodeDeletedEvent",
"node": { "path": "/victim/files/Notes/any.md", "id": 12345 }
},
"user": { "uid": "victim" },
"time": 0
}
Result: Qdrant deletes all vector embeddings for victim doc 12345 with no authentication. Attacker can loop over doc IDs for mass deletion. All user targets accepted.
Impact
- Anyone on the network with access to port
8000- no credentials needed. - Attacker can delete or trigger re-index of any user's vector embeddings in Qdrant by spoofing
user.uidin the payload. - Mass-sending delete events for all doc IDs destroys the entire semantic search index for all users, requiring a full re-scan to recover.
Recommend Fix
- Enforce
WEBHOOK_SECRETat startup ( fileconfig_validators.py)
if vector_sync_enabled and not settings.webhook_secret:
raise ConfigurationError(
"WEBHOOK_SECRET must be set when vector sync is enabled"
)
- Reject requests when secret is unset ( file
webhook_receiver.py)
secret = get_settings().webhook_secret
if not secret:
return JSONResponse({"status": "unavailable"}, status_code=503)
provided = request.headers.get("authorization", "").encode()
if not hmac.compare_digest(provided, f"Bearer {secret}".encode()):
return JSONResponse({"status": "unauthorized"}, status_code=401)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | nextcloud-mcp-server | all versions | 0.117.2pip install --upgrade 'nextcloud-mcp-server==0.117.2' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for nextcloud-mcp-server, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update nextcloud-mcp-server to 0.117.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-55640 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is CVE-2026-55640 in your dependencies?
Find it across PyPI, including transitive dependencies.