Please report security issues through GitHub Security Advisories — the private-disclosure channel integrated with this repository:

https://github.com/EdouardVanbelle/OxiCloud/security/advisories/new

If GitHub isn't a viable channel for you (organisational policy, no GH account, etc.), email a maintainer directly at opensource+security@edouard.vanbelle.fr. Please include the word security in the subject line so it routes ahead of general project mail.

Please do NOT open public GitHub issues for security vulnerabilities. A public issue makes the finding available to attackers before the fix ships, which is exactly what we're trying to avoid.

A short, specific report is far more useful than a long generic one. If you can share:

• A concise description of the issue and its impact
• Steps to reproduce, or a proof-of-concept if one exists
• Affected component (REST API, WebDAV, NextCloud DAV, CalDAV, CardDAV, WOPI, auth, frontend, …)
• Affected version or commit hash
• Any remediation you've already identified

Both executed exploits AND code-review findings are welcome — mention which one it is (e.g. "I found this pattern in the source but couldn't build the service to verify runtime") so we know what to expect.

If you're not sure whether something is a vulnerability, err on the side of reporting; we'd rather triage a false positive than miss a real issue.

OxiCloud is maintained by a small volunteer team. Realistic timelines:

• Acknowledgement: within 5 business days
• Initial triage and severity assessment: within 14 days
• Fix on main: timeline depends on complexity, communicated during triage
• Public disclosure: coordinated with the reporter, typically after the fix has been available on main long enough for downstream users to update

If you don't hear back within 5 business days, please ping the private advisory or resend the email — reports occasionally get missed.

In scope:

• Server (src/) — anything reachable via the HTTP surface (REST API, WebDAV, NextCloud DAV, CalDAV, CardDAV, WOPI) or via authentication / authorization / session management
• Frontend (frontend/) — client-side issues (XSS, CSRF gaps, insecure client-side storage, DOM sinks)
• Build artifacts and release tarballs — supply-chain and packaging integrity
• The migration and background-job surfaces — anything an authenticated user or admin can trigger

Out of scope (please don't spend your time on these):

• Missing security headers on non-authenticated public endpoints (already tracked)
• Rate-limit tuning suggestions
• Denial-of-service via resource exhaustion at scales beyond the documented deployment guidance
• Findings that require attacker-controlled physical or root access to the server host
• Vulnerabilities in third-party dependencies that don't have a reachable path from OxiCloud code (report those upstream)

We won't pursue legal action against researchers acting in good faith under this policy — that means:

• Not accessing or modifying data belonging to other users beyond the minimum needed to demonstrate the issue
• Not degrading service for others (no volumetric testing without coordination)
• Reporting the issue privately before any public disclosure
• Giving us reasonable time to fix before publishing

Testing against your own self-hosted instance is always fine. Testing against a third-party OxiCloud deployment requires explicit permission from that deployment's operator.

We're happy to credit reporters in the fix commit, release notes, and this file's history. Tell us your preferred name or handle when you report, or say if you'd rather stay anonymous.

Coordinated disclosures we've received and resolved:

• 2026-09-05 — Timing side-channel in WebDAV lock-token comparison (evaluate_if_header in src/interfaces/api/handlers/webdav_handler.rs used plain == on state-tokens, byte-wise with early exit). Fixed by routing lock-token comparisons through a subtle::ConstantTimeEq helper. Practical exploitability was marginal (ns-scale signal buried in ms-scale network jitter, ~5×10⁸ samples required within the lock's default 60 s–1 h lifetime), but the fix is small and matches the constant-time-compare hygiene applied elsewhere in the codebase. Reported by Abdurazzoqov Javohir (@abdurazzoqovjavohir700-dev) via responsible disclosure; fix landed in PR #712. Thanks for the clear report and the specific remediation suggestion.