Outline IDOR lets authenticated users exfiltrate private docs via share links

TL;DR - In Outline >= 0.86.0, < 1.7.0, any authenticated user can call shares.create with a collectionId they can access plus any documentId they cannot. The auth check only covers the collection. The result is a valid public share link for a document the caller was never supposed to read - including documents in other workspaces. Retrieve the contents via documents.info. Patched in 1.7.0.

What happened

Outline is a self-hostable team wiki and documentation platform built around collections, documents, and public share links.

CVE-2026-41649 is an insecure direct object reference in the shares.create API endpoint. When a request includes both collectionId and documentId, the authorisation logic validates access to the collection but skips the document entirely. An authenticated user can point that endpoint at any document ID - including ones in workspaces they have no business touching - and get back a working public share link.

From there, documents.info hands over the full document contents.

This is the classic share-link and ACL mismatch failure mode. Once "create share link" can be aimed at arbitrary object IDs, a normal collaboration feature becomes a cross-tenant data exfiltration path. The pattern is common enough that it deserves a checklist item whenever you're reviewing APIs that issue shareable tokens or links.

Who is impacted

• Any Outline deployment running versions >= 0.86.0, < 1.7.0.
• Multi-team and multi-workspace setups where low-trust authenticated users exist - exactly the environments Outline is built for.
• Installations where users can reach shares.create and documents.info via the API and where public share links are treated as proof of authorisation to read content.

What to do now

• Upgrade to 1.7.0 or any later release. The CVE record states:

  "Version 1.7.0 contains a patch."

• Inventory Outline versions across every environment - production, staging, and internal sandboxes. Target anything in the >= 0.86.0, < 1.7.0 range.
• Treat affected instances as potentially having leaked document contents:
  • Audit share link creation activity for unexpected or anomalous entries.
  • Enumerate existing public shares and verify each one maps to a document the link creator should have accessed.
• If you suspect abuse:
  • Rotate any secrets or credentials stored inside documents.
  • Review documents.info access patterns for lookups that correlate with freshly created shares from low-privilege accounts.