CVE CyberSecurity Database News

CVE-2024-1211 - GitLab JWT OmniAuth CSRF Vulnerability Explored

Poster -

If your organization uses GitLab for source control and has enabled JWT as an OmniAuth provider, you may be at risk of a newly disclosed security vulnerability - CVE-2024-1211. In this post, we break down the details and possible risks, show how an exploit might look, and discuss practical steps to protect your systems. Everything is explained in simple terms for developers, sysadmins, and security folks who need a clear understanding.

What is CVE-2024-1211?

CVE-2024-1211 is a Cross-Site Request Forgery (CSRF) issue in GitLab Community Edition (CE) and Enterprise Edition (EE) — one of the most popular DevOps platforms today.

16.11 _up to_ 16.11.2

Specifically: the bug is only present if you’ve configured JWT (JSON Web Token) as an OmniAuth provider for sign-in.

What Could Go Wrong?

If someone can trick a logged-in GitLab user into visiting a crafted malicious web page, they may be able to forge authentication-related requests on the user’s behalf. The attacker could gain access to the victim’s session or perform actions as them, depending on how authentication is set up.

How JWT OmniAuth Works in GitLab

GitLab supports OmniAuth, making it possible to allow users to sign in using third-party providers, like Google, GitHub, or in this case, custom services with JWT.

You might see a config like this in your GitLab gitlab.rb or inside the Rails application’s Omniauth block:

# gitlab.rb (CE/EE)
gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_providers'] = [
  {
    "name" => "jwt",
    "args" => {
      "secret" => "<myjwtsecret>",
      "algorithm" => "HS256",
      "uid_field" => "email"
    }
  }
]

When a user logs in, GitLab expects a JWT token coming from a trusted identity provider, then authenticates the user accordingly.

How Could the CSRF Exploit Work?

Normally, CSRF is blocked by making sure that any sensitive HTTP call requiring a user’s identity (like authenticating via JWT) also includes a secret token (CSRF token), making it hard for a malicious web page to guess or replicate.

Prior to the fixed versions above, GitLab wasn’t enforcing this protection when JWT was configured as an OmniAuth provider.

This means: if a victim is already signed in on the target GitLab instance, visiting a malicious page could make their browser send unwanted OAuth or authentication requests (via JWT) to the GitLab instance and possibly log them in as someone else, or perform other actions.

Here is what an attacker might try

1. Craft a malicious web page that sends a POST request to the vulnerable GitLab’s OmniAuth JWT login URL.
2. Embed a valid, attacker-controlled JWT in the request (crafted using knowledge of the secret or from a trusted JWT provider).
3. The victim, while logged in on GitLab, visits this page and unknowingly sends the request with their cookies.

Log the victim into a different account or

- Perform actions as the victim by exploiting confusion over user identities/authentication sessions.

Example Attack Code (for Research/Education Only)

Below is a simplified HTML+JavaScript snippet an attacker might use. Do NOT use this in production or for illegal purposes!

<!DOCTYPE html>
<html>
  <body>
    <form id="jwt-login" method="POST" action="https://gitlab.example.com/users/auth/jwt/callback">;
      <input type="hidden" name="jwt" value="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6ImFdGFja2VyQGVtYWlsLmNvbSJ9.s3cr3ts1gn4tur3">
    </form>
    <script>
      document.getElementById('jwt-login').submit();
    </script>
  </body>
</html>

If the user is authenticated in their browser with GitLab, this page could send a JWT authentication payload (crafted by the attacker) and GitLab would process it _without_ checking for a CSRF token — before the bug was fixed.

More Information and References

- GitLab CVE-2024-1211 Security Release Details
- GitLab JWT OmniAuth docs
- NVD Entry for CVE-2024-1211
- OmniAuth Project

Upgrade to 16.9.7, 16.10.5, or 16.11.2 (or any version newer).

2. Audit your config: If you do NOT use JWT as an OmniAuth provider, you are *not* affected by this specific CSRF flaw.

Conclusion

CVE-2024-1211 is one more strong reminder to carefully secure authentication handlers, especially in developer tools like GitLab. If your company relies on OmniAuth with JWT—and especially if your GitLab instance is accessible over the internet—patch as soon as possible.

Stay safe, and keep your DevOps tooling up to date!


Feel free to share this guide or ask questions at GitLab forums or the GitLab security contact page.

Timeline

Published on: 01/31/2025 00:15:08 UTC