DoS via Collaborative Document in outline/outline


Reported on

Aug 15th 2022


An attacker can send an enormous payload via the WebSockets collaborative document feature, without any proper size restriction, leading to the unresponsiveness of every user browser that visits the target document, and even worse, if the payload is bigger enough, in the demonstration below is 100MB, it will cause the server crash due to the incapacity of the application to handle such large amounts of data in one time and update the original document. After the server crashes, it is also necessary to restart the service manually to restore its normal function.

An additional problem is the storage resource usage, that could be filled up totally in a short time, since such payloads will be stored inside of the documents. The final document of the demonstration below takes up alone 100MB of the server storage. storage

This is only possible via the WebSockets because the /api/documents.update API endpoint is protected by nginx, that throws the 413 - Request Entity Too Large error.

Proof of Concept

  1. 1 - Login in the application
  2. 2 - Create a new document or open an existing one.
  3. 3 - Generate the payload that consists of an Markdown Link: [sometext](/AAAA...(100000000 tines)).
  4. 4 - Paste the payload in the document.(This requires from the attacker machine a great amount of RAM. An optimal way to do it, would be to generate the document with the payload automatically and send it directly to the WebSockets document service).
  5. 5 - Wait for the payload to be sent. Once the server receives it, it will start to consume an abnormal quantity of computing resources, being them eventually exhausted leading to the server crash.
  6. 6 - The application becomes unavailable for all its users.

    PoC Video


A user can cause a full denial of service attack in the application server, making the application unavailable to all its users.

We are processing your report and will contact the outline team within 24 hours. a month ago
outline/outline maintainer has acknowledged this report a month ago
Tom Moor
a month ago


Thanks for the report, I've put a couple of initial mitigations in place – one at the database level and one on websocket payload size:

let me know if you feel these cover the vulnerability? Also should go without saying but just to be clear – do not test this against the production servers.

a month ago


Hi, no worries all the tests and the demonstrations were run in a self-hosted environment.

I just tested the new mitigations and I can confirm that I can't no longer send a payload bigger than 1.5MB, neither can the document total size exceed 1MB in total.

Tom Moor validated this vulnerability a month ago
vultza has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
Tom Moor
a month ago


I do wish that we could reduce the payload size further but unfortunately the largest size is the size of the CRDT binary itself

We have sent a fix follow up to the outline team. We will try again in 7 days. a month ago
We have sent a second fix follow up to the outline team. We will try again in 10 days. a month ago
Tom Moor confirmed that a fix has been merged on ed8176 23 days ago
The fix bounty has been dropped
to join this conversation