Denial-of-Service via /-/edit/ endpoint loading full blob into memory

⚠️ Please read the process on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror.

HackerOne report #3161756 by pwnie on 2025-05-25, assigned to @fvpotvin:

Report | How To Reproduce

Report

Summary

/-/edit/<branch>/<file> streams the entire blob into memory on every request. An attacker can upload a very large file (≥ 1 GB) and repeatedly hit this endpoint to exhaust RAM/CPU, forcing Puma workers to crash-loop.

Steps to Reproduce

Upload a large file (e.g., 3 GB) to any repository you control.
Run a parallel flood (100 requests, 20 concurrent):

seq 100 | xargs -P20 -n1 -I{} \  
  curl 'https://<gitlab-host>/<namespace>/<repo>/-/edit/main/a_1GB.bin?ref_type=heads' \  
       -b '_gitlab_session=<valid_session_cookie>' \  
       --insecure

Watch server memory spike → OOM → worker restarts → site outage.

Impact

Any authenticated user with Developer-level (write) access can repeatedly crash all web workers, causing a persistent DoS for every GitLab user on the instance (GitLab.com included, since free personal projects are allowed).

Impact

How To Reproduce

Please add reproducibility information to this section: