CVE-2024-6685

What it actually does

The vulnerability exposes group runner registration tokens, descriptions, and configuration details through API responses and UI views to group members whose role lacks the required permissions to view runner infrastructure.

Why it matters to the business

Attackers who obtain low-privilege group membership can discover CI/CD execution environments, increasing the chance of targeted pipeline compromise or supply-chain attacks against build artifacts.

How an attack unfolds

An attacker joins a GitLab group with minimal permissions, issues requests to the runners listing endpoints or views the group runners page, and receives runner metadata that the authorization checks failed to filter.

How to fix it

Upgrade GitLab CE/EE to 17.1.7, 17.2.5, or 17.3.2 (or later) which contain the fix commit 84cf95d60d2691201b17bb4d41a95987ded847fb. Restrict group membership to trusted users until patches are applied.

How to confirm the fix worked

After upgrade, confirm that non-maintainer group members receive empty or permission-denied responses when querying group runners endpoints; review release notes for the listed fix versions.

Typical attack path

1. Obtain membership in the target GitLab group
2. Authenticate with a low-privileged token or session
3. Request the group runners API endpoint or load the runners UI
4. Parse the returned runner tokens, tags, and executor details

How to detect it

Review GitLab audit logs and access logs for repeated queries to /groups/*/runners or /api/v4/groups/*/runners from accounts whose role does not include runner administration; correlate with user creation or group membership events.

What your security team should do

• Apply the fixed versions immediately given the public disclosure date
• Audit current group memberships and runner visibility settings
• Enable audit logging for runner API access to detect anomalous queries
• Monitor EPSS and exploit maturity for any future increase in risk