GitLab Under Active Attack: Critical SAML Bypass (CVE-2024-45409), Account Takeover & Modern Upgrade Paths

Executive Technical Briefing: Active Exploitation Overview

Security operations centers (SOCs) and global telemetry networks have recorded sustained automated exploitation campaigns targeting self-hosted GitLab Community Edition (CE) and Enterprise Edition (EE) deployments. Threat actors are weaponizing CVE-2024-45409 (CVSS 10.0 Critical)—an unauthenticated Security Assertion Markup Language (SAML) authentication bypass originating within underlying omniauth-saml and ruby-saml libraries—alongside persistent reconnaissance for CVE-2023-7028 (CVSS 10.0 unverified password reset account takeover) and CVE-2024-5655 (CVSS 9.6 GraphQL arbitrary pipeline execution).

Active Attack Evidence & Recent 2026 Threat Campaign Reports

Threat intelligence agencies and independent cybersecurity research organizations have confirmed active, in-the-wild weaponization across public internet infrastructure:

• Censys & Shadowserver Internet Telemetry: Current scan data from Censys and the Shadowserver Foundation reveals that over 5,000 publicly exposed GitLab IPv4 instances worldwide continue to operate without critical security patches. Threat actor scanning engines continuously probe ports 80 and 443 with automated SAML callback payloads and password reset injections.
• CISA KEV Mandatory Binding: The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added both CVE-2024-45409 and CVE-2023-7028 to its Known Exploited Vulnerabilities (KEV) Catalog, mandating emergency remediation under Binding Operational Directive (BOD) 22-01.
• Weaponized Botnet Payloads & Lateral Movement: Real-world incident response investigations confirm that automated threat actors utilize these vulnerabilities to clone proprietary Git repositories, harvest embedded CI/CD secrets (AWS access keys, SSH deploy keys, production tokens), deploy XMRig cryptocurrency miners, and establish persistent reverse proxy tunnels into internal corporate networks.

Architectural Breakdown & Root Cause Mechanics

1. SAML Cryptographic Signature Verification Bypass (CVE-2024-45409)

In self-hosted GitLab environments configured with SAML Single Sign-On (SSO) via identity providers (such as Okta, Microsoft Entra ID, or PingFederate), authentication assertions are evaluated by the ruby-saml dependency. A vulnerability in XML signature wrapping allows an unauthenticated remote attacker who captures or crafts an XML signature to forge an arbitrary SAML response. Because signature verification does not strictly validate the cryptographic signature against the parent assertion element, the attacker can authenticate as any arbitrary GitLab administrator without possessing valid user credentials or passing through Identity Provider (IdP) authentication challenges.

2. Cascading Vector: Account Takeover via CVE-2023-7028

Automated threat reconnaissance scripts frequently pair SAML probes with tests for CVE-2023-7028. In unpatched installations, password reset emails could be directed to an arbitrary secondary email address provided within the HTTP request payload. This enables instant, zero-interaction takeover of administrator accounts, allowing immediate generation of personal access tokens with api and sudo scopes.

3. GraphQL Pipeline Manipulation & Execution (CVE-2024-5655)

Once initial access is established, attackers leverage exposed GraphQL endpoints (/api/graphql) via CVE-2024-5655 (CVSS 9.6). This flaw allows a threat actor to trigger CI/CD pipeline runs under the identity of arbitrary users, executing unreviewed pipeline scripts on internal runner daemons to bypass branch protection rules and pivot deeper into staging and production clusters.

Incident Telemetry & Vulnerability Impact Matrix

To evaluate the operational risk across self-hosted deployments, review the technical impact matrix below, cross-referenced against primary NIST NVD and vendor security advisories:

Hands-On Verification & Forensic Audit Commands

Systems administrators must immediately execute the following forensic commands on host machines to verify whether their self-hosted GitLab server has been targeted or compromised:

# 1. Audit GitLab production logs for anomalous SAML SSO login callbacks
sudo grep -Ei "(saml|omniauth)" /var/log/gitlab/gitlab-rails/production_json.log   | grep -Ei '("status":200|callback)'   | jq -r '{time: .time, ip: .remote_ip, user: .username, status: .status}'   | tail -n 25

# 2. Check for unauthorized administrative account creation or privilege changes
sudo gitlab-rails runner "User.where(admin: true).pluck(:id, :username, :email, :created_at, :current_sign_in_at)"

# 3. Inspect recent password reset requests for secondary email injection
sudo grep -i "sent_reset_password_instructions" /var/log/gitlab/gitlab-rails/production_json.log   | jq -r '{time: .time, ip: .remote_ip, params: .params}'   | tail -n 20

# 4. Verify runner daemon socket integrity and flag outbound reverse connections
sudo lsof -i -n -P | grep gitlab-runner | grep ESTABLISHED

Enterprise Hardening & Remediation: Modern vs Historical Paths

1. Historical Emergency Patches vs Modern 2026 Production Targets

When GitLab originally patched CVE-2024-45409 in September 2024, emergency backports were published across legacy minor versions (17.3.3, 17.2.7, 17.1.8, 17.0.8, and 16.11.10).

However, in 2026, administrators must not leave systems pinned to historical release versions. Deployments must upgrade to the latest supported stable release (GitLab 17.8+ or the latest active maintenance stream) to maintain security compliance and patch subsequent memory corruption and GraphQL vulnerabilities.

2. Mandatory Upgrade Path Architecture (Intermediate Stop Versions)

GitLab utilizes complex PostgreSQL database migrations and batched background jobs. Direct cross-major or distant minor upgrades are strictly prohibited and will corrupt the database schema.

Administrators must traverse mandatory intermediate "stop versions" using the official GitLab Upgrade Path Tool. For example, an instance on 16.11.x cannot jump directly to 17.8+; it must follow a staged sequence:

$$ ext{16.11.10} \longrightarrow ext{17.0.8} \longrightarrow ext{17.3.5} \longrightarrow ext{17.7.x} \longrightarrow ext{17.8+ (Latest)}$$

# Update repository package lists
sudo apt-get update

# Install the latest stable production release (or target intermediate stop version):
sudo apt-get install gitlab-ee

# Execute database migrations and restart services
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Before advancing to each subsequent stop version, verify that all background migrations have finished:

sudo gitlab-rails runner "puts Gitlab::Database::BackgroundMigration::BatchedMigration.queued.count"

Primary Sources & Recent Threat Campaign Reports

1. Censys Threat Intelligence: Internet-Wide GitLab Vulnerability Exposure
2. Shadowserver Foundation: Vulnerable GitLab Server Scanning Dashboard
3. CISA Known Exploited Vulnerabilities Catalog: BOD 22-01 CVE-2024-45409 Directive
4. GitLab Official Security Advisory: Patch Release 17.3.3 / Critical SAML Advisory
5. GitLab Upgrade Path Tool: Official Upgrade Path Calculator
6. NIST National Vulnerability Database: CVE-2024-45409 Detail

Editorial Review & Standards

This security advisory has been independently compiled and reviewed by the Zero Hour Tech Editorial Desk in accordance with our editorial standards and responsible disclosure principles (ISO/IEC 29147). For ongoing threat intelligence and Linux server hardening playbooks, explore our authoritative cybersecurity advisories and technical guides.

For ongoing threat intelligence and Linux server hardening playbooks, explore our authoritative cybersecurity advisories and technical guides.