Gitlab EE DoS by sending unauthenticated POST requests (with maliciously crafted data) to /-/collect_events endpoint

⚠️ 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 #3338151 by a92847865 on 2025-09-14, assigned to GitLab Team:

Report | Attachments | How To Reproduce

Report

NOTE! Thanks for submitting a report! Please note that initial triage is handled by HackerOne staff. They are identified with a HackerOne triage badge and will escalate to the GitLab team any. Please replace all the (parenthesized) sections below with the pertinent details. Remember, the more detail you provide, the easier it is for us to triage and respond quickly, so be sure to take your time filling out the report!

Summary
  • Event level monitoring data can be sent to Gitlab EE instance through /-/collect_events endpoint (see more here )
  • This endpoint is unauthenticated.
  • There's no size limit on the request's payload. Moreover, the payload is parsed consuming a lot of RAM. Parsing 5 payloads (~50MB each) concurrently would consume all available RAM in 16GB RAM Gitlab EE instance --> Gitlab EE instance is DoSed (see more in PoC video).
  • There's another attack path (emitting a very large number of bogus events into event log file).
  • Below PoC is for excessive memory consumption attack path only.
Steps to reproduce

(Step-by-step guide to reproduce the issue, including:)

  1. Register 2 VMs. VM1 (8 vCPU, 16 GB RAM) for Gitlab EE and VM2 (1 vCPU, 4GB RAM) for sending requests.
  2. Download and install Gitlab EE on VM1
  3. Upload <redacted malicious JSON payload> to VM2 and gunzip it: gunzip bad.json.gzip
  4. On VM2, send 5 requests to Gitlab EE web server (installed on VM1)
curl 'http://<Gitlab-host-name>/-/collect_events' \  
  -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36' \  
  -H 'Content-Type: application/json; charset=UTF-8' \  
  -d [@]bad.json
  1. After 2-3 minutes, all available RAM on VM1 is consumed --> Gitlab EE web server becomes unavailable to users.

PoC video:
<redacted malicious JSON payload>

Impact

Gitlab EE main app (Puma web server) becomes unavailable to normal users --> complete DoS.

Examples

(If the bug is project related, please create an example project and export it using the project export feature)

(If you are using an older version of GitLab, this will also help determine whether the bug has been fixed in a more recent version)

(If the bug can be reproduced on GitLab.com without violating the Rules of Engagement as outlined in the program policy, please provide the full path to the project.)

What is the current bug behavior? 
def forward  
      process_events  
      head :ok  
    end
  • Then the payload is parsed by Gitlab::Json class without prior size validation:
    def process_events  
      tracker = Gitlab::Tracking.tracker  
      event_eligibility_checker = Gitlab::Tracking::EventEligibilityChecker.new  
      payload = Gitlab::Json.parse(request.raw_post) // vulnerable line  
// ............ other unrelated codes  






    end
What is the expected correct behavior?

Should restrict payload size to 1MB (similarly to Snowplow Collector).

Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's very hard to read otherwise.)

Output of checks

(If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com)

Results of GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:env:info)

System information  
System:         Ubuntu 24.04  
Proxy:          no  
Current User:   git  
Using RVM:      no  
Ruby Version:   3.2.8  
Gem Version:    3.6.9  
Bundler Version:2.7.1  
Rake Version:   13.0.6  
Redis Version:  7.2.10  
Sidekiq Version:7.3.9  
Go Version:     unknown

GitLab information  
Version:        18.3.2-ee  
Revision:       1ffbed2ea94  
Directory:      /opt/gitlab/embedded/service/gitlab-rails  
DB Adapter:     PostgreSQL  
DB Version:     16.8  
URL:            http://<redacted>  
HTTP Clone URL: http://<redacted>/some-group/some-project.git  
SSH Clone URL:  git@<redacted:some-group/some-project.git  
Elasticsearch:  no  
Geo:            no  
Using LDAP:     no  
Using Omniauth: yes  
Omniauth Providers: 

GitLab Shell  
Version:        14.45.2  
Repository storages:  
- default:      unix:/var/opt/gitlab/gitaly/gitaly.socket  
GitLab Shell path:              /opt/gitlab/embedded/service/gitlab-shell

Gitaly  
- default Address:      unix:/var/opt/gitlab/gitaly/gitaly.socket  
- default Version:      18.3.2  
- default Git Version:  2.50.1.gl1

(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production)

Impact

Gitlab EE main app (Puma web server) becomes unavailable to normal users --> complete DoS.

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

  • <redacted malicious JSON payload>
  • <redacted POC video>

How To Reproduce

  1. As the victim, sign in victim's root account on self-hosted GitLab instance -> Go to Admin area -> Metrics and profiling -> Expand Event tracking setting -> Select Enable event tracking -> Save changes:
  2. As the attacker, download researcher's PoC file F4781694 on the attacker's machine -> Extract it
  3. As the attacker, run following command on the attacker's machine, where YOUR_GITLAB_HOST is your GitLab host:
while true; do curl 'http://YOUR_GITLAB_HOST/-/collect_events' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36'  -H 'Content-Type: application/json; charset=UTF-8' -d @bad.json; sleep 1; done
  1. As the victim, check htop. You can see memory usage is increasing. After 5 min, the host memory will be fully consumed:
  2. As the victim, visit the self-hosted GitLab site. You can see victim is not able to access the site:

Impact statement

Malicious actor can deny other user's access to the target GitLab host.

If you have any questions or concerns about this report, feel free to assign it to H1 Triage via the action picker with a comment indicating your request.

Edited by ADandy