CVE-2024-25632

Executive Summary

CVE-2024-25632 is a critical privilege escalation vulnerability in eLabFTW, an open-source electronic lab notebook (ELN) used extensively in research labs. The flaw allows a user who is a regular member of a team to escalate their privileges to become an administrator of that same team. Under certain configurations (e.g., when local user registration is enabled or SAML team creation is allowed), an initially unauthenticated attacker can exploit this to gain administrative control over an arbitrary team. The vulnerability stems from improper validation of team-level administrative privileges during user role assignment, effectively bypassing the intended separation between team administrator and regular user roles. The CVSS score of 8.6 (High) reflects the low attack complexity, low privileges required, and the high impact on confidentiality, integrity, and availability of the affected team’s data.

Supply Chain & Package Security

eLabFTW is a PHP application distributed via GitHub and Docker. The vulnerability is introduced in the application’s own codebase, not in a third-party dependency. However, the risk is amplified by the common deployment pattern in research environments where eLabFTW is exposed to the internet or internal networks with weak authentication controls. The lack of a public exploit or PoC at the time of analysis reduces immediate weaponization risk, but the high severity and ease of exploitation make it a prime target for threat actors targeting academic and research institutions.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – Exploitable remotely.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): Low (L) – Attacker needs a valid user account in the target team.
• User Interaction (UI): None (N) – No victim action needed.
• Scope (S): Unchanged (U) – The vulnerable component is the only affected component.
• Confidentiality (C): High (H) – Full read access to all team data.
• Integrity (I): High (H) – Full write access to team data and configurations.
• Availability (A): High (H) – Ability to delete or lock team resources.

Threat Level: Critical for research environments. The vulnerability is trivial to exploit once an attacker has a foothold (e.g., via phishing or weak credentials). The EPSS score of 0.0% suggests low current exploitation, but this is likely due to the recent disclosure and lack of public PoC.

Deep Dive & Mechanics

The vulnerability resides in the team membership and role assignment logic. In eLabFTW, a user can belong to multiple teams, with different roles (e.g., admin in Team A, user in Team B). The flaw occurs when the application processes a request to change a user’s role within a team. The code fails to properly verify that the requesting user has administrative privileges in the target team before allowing the role change. Instead, it may check only if the user is an admin in any team, or it may rely on a flawed context-switching mechanism.

Specifically, the vulnerable code path is triggered when an authenticated user sends a POST request to an endpoint like /api/v2/teams/{team_id}/users/{user_id} with a payload to modify the user’s role (e.g., {"role": "admin"}). The server-side validation checks if the requester is an admin, but due to a missing or incorrect team context check, a user who is an admin in Team A can elevate their own role in Team B (where they are a regular user) to admin. In versions after 5.0.0, the registration flow also allows an unauthenticated user to create an account and immediately exploit this flaw if SAML team creation is enabled.

The root cause is a classic Improper Privilege Management (CWE-269) – the application does not enforce the principle of least privilege across team boundaries.

Vulnerable vs. Patched Code

The following is a simplified representation of the vulnerable and patched logic.

Vulnerable Code (eLabFTW < 5.1.0):

// In a controller or service handling user role updates
public function updateUserRole(Request $request, $teamId, $userId) {
    $currentUser = Auth::user();
    // BUG: Only checks if user is admin in ANY team, not the target team
    if (!$currentUser->isAdmin()) {
        return response()->json(['error' => 'Unauthorized'], 403);
    }
    // ... proceed to update role
    $user = User::find($userId);
    $user->setRole($request->input('role'), $teamId);
    return response()->json(['success' => true]);
}

Patched Code (eLabFTW >= 5.1.0):

public function updateUserRole(Request $request, $teamId, $userId) {
    $currentUser = Auth::user();
    // FIX: Explicitly check admin status in the target team
    if (!$currentUser->isAdminInTeam($teamId)) {
        return response()->json(['error' => 'Unauthorized'], 403);
    }
    // ... proceed to update role
    $user = User::find($userId);
    $user->setRole($request->input('role'), $teamId);
    return response()->json(['success' => true]);
}

The patch introduces a new method isAdminInTeam($teamId) that queries the team membership table to verify the user’s role specifically for that team.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A running eLabFTW instance (version < 5.1.0) with at least two teams.
• A valid user account that is a regular member of the target team (Team B) but an admin in another team (Team A), OR an unauthenticated user if SAML team creation is enabled.

Exploitation Steps:

1. Authenticate to the eLabFTW instance as the attacker user.
2. Identify the target team ID (e.g., via the /api/v2/teams endpoint).
3. Send a crafted POST request to escalate privileges:

   POST /api/v2/teams/2/users/1 HTTP/1.1
   Host: elabftw.example.com
   Cookie: PHPSESSID=attacker_session
   Content-Type: application/json
   
   {"role": "admin"}
   

   (Where 2 is the target team ID and 1 is the attacker’s user ID.)
4. Verify escalation by accessing team admin features (e.g., user management, team settings).

For unauthenticated exploitation (post-5.0.0):

1. Register a new account via the public registration form.
2. Immediately exploit the same endpoint as above, as the new user will have no admin privileges in any team, but the flawed check may still pass if the code incorrectly treats the user as an admin due to a default role bug.

Blue Team

Detection:

• Monitor for unusual POST requests to /api/v2/teams/*/users/* with a JSON body containing "role": "admin".
• Alert on any role change event where the requesting user is not already an admin of the target team.
• Correlate with authentication logs to identify users who suddenly gain admin privileges.

Hunting:

• Query database for users with is_admin = 1 in the teams_users table but who were previously regular users.
• Review audit logs for user_role_updated events with suspicious patterns (e.g., rapid succession of role changes).

Prevention:

• Apply the patch immediately (upgrade to 5.1.0).
• As a workaround, disable local user registration and SAML team creation.
• Restrict API access to trusted IPs or require MFA for admin actions.

Indicators of Compromise (IOCs)

• Network:
  • POST requests to /api/v2/teams/*/users/* with {"role": "admin"} payload.
  • Unusual number of failed authentication attempts followed by successful role changes.
• Host:
  • Audit log entries showing user_role_updated with new_role: admin for non-admin users.
  • Database entries in teams_users where is_admin is set to 1 for users who were previously 0.
• File:
  • Modified configuration files (e.g., .env) if the attacker gains full admin access.
• User Agent:
  • Automated scripts (e.g., Python requests, curl) used for exploitation.

Detection Engineering

YARA Rule

rule Detect_eLabFTW_PrivEsc_Attempt {
    meta:
        description = "Detects HTTP requests attempting to exploit CVE-2024-25632"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "CVE-2024-25632"
    strings:
        $endpoint = "/api/v2/teams/" nocase
        $role_admin = "\"role\":\"admin\"" nocase
        $method_post = "POST" nocase
    condition:
        $endpoint and $role_admin and $method_post
}

Sigma Rule

title: eLabFTW Privilege Escalation Attempt
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects HTTP POST requests to eLabFTW API attempting to set a user role to admin
author: Valters IT
date: 2024/10/27
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains: '/api/v2/teams/'
        cs-uri-query|contains: '/users/'
        cs-request-body|contains: '"role":"admin"'
    condition: selection
falsepositives:
    - Legitimate admin actions (should be rare and from known admin IPs)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-25632 eLabFTW Privilege Escalation Attempt"; flow:to_server; content:"POST"; http_method; content:"/api/v2/teams/"; http_uri; content:"/users/"; http_uri; content:"\"role\":\"admin\""; http_client_body; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

1. Upgrade to eLabFTW version 5.1.0 or later.
2. Disable local user registration (local_register = 0 in configuration).
3. Disable SAML team creation (saml_team_create = 0).
4. Restrict API access to internal networks or VPN.

Long-term:

• Implement strict role-based access control (RBAC) with team-scoped permissions.
• Enforce multi-factor authentication (MFA) for all admin actions.
• Regularly audit user roles and team memberships.
• Monitor for anomalous API calls using the provided detection rules.

Workaround (if patching is delayed):

• Manually review and harden the isAdmin() function to accept a team ID parameter.
• Add a web application firewall (WAF) rule to block POST requests to /api/v2/teams/*/users/* with role=admin unless the requester is already an admin of that team.

Valters IT