☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
[ VENDOR STATS ]
SOON 🐛 CWE-281
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2024-57439

CVE-2024-57439 Denial of Service in Ruoyi
📅 PUBLISHED: 2025-01-29 00:00 UTC 🔄 UPDATED: 2026-08-28 11:35 UTC
⏳ SCORE PENDING — ANALYSIS IN PROGRESS [ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.58%
👁️
0.58% probability
14.5× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
VULNERABLE: UNKNOWN / CHECK VENDOR
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
SOON
PENDING NVD
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2024-57439 is a security advisory affecting Ruoyi v4.8.0, a popular Java-based rapid development framework. The vulnerability resides in the password reset interface, where an attacker with Admin privileges can cause a Denial of Service (DoS) by duplicating the login name of an existing account. This flaw allows a privileged user to disrupt system availability, potentially locking out legitimate administrators or causing service instability. The vulnerability has a CVSS score of 0.0, indicating incomplete scoring data, but the impact is clear: a DoS condition triggered by a simple input manipulation. No public exploit code or patch details are available at this time.

⚡ 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

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, which typically indicates that the scoring vector has not been fully assigned or published. Based on the description, a plausible vector would be:

  • Attack Vector (AV): Network (the reset password interface is network-accessible)
  • Attack Complexity (AC): Low (duplicating a login name is straightforward)
  • Privileges Required (PR): High (requires Admin privileges)
  • User Interaction (UI): None
  • Scope (S): Unchanged
  • Confidentiality (C): None
  • Integrity (I): None
  • Availability (A): High (DoS impact)

Estimated CVSS v3.1 Score: 4.9 (Medium) – based on AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H.

Threat Level: Medium. The vulnerability requires Admin privileges, limiting the attack surface to already trusted users. However, a malicious or compromised admin could easily disrupt operations.

Deep Dive & Mechanics

The vulnerability exists in the password reset functionality of Ruoyi v4.8.0. The interface likely accepts a username or login name to initiate a password reset. The flaw occurs when an Admin user submits a request with a login name that already exists in the system, but the application fails to properly handle the duplicate entry. This could lead to:

  • Resource Exhaustion: The system may attempt to process multiple reset requests for the same user, consuming CPU, memory, or database connections.
  • State Corruption: The password reset logic might enter an infinite loop or deadlock, causing the service to become unresponsive.
  • Account Lockout: The duplicate processing could corrupt the user's account state, preventing future logins.

The root cause is likely a lack of input validation or improper handling of duplicate entries in the reset password workflow. The application should check for existing reset requests or enforce uniqueness constraints.

Vulnerable vs. Patched Code

Since no patch details are available, we can only hypothesize the vulnerable code pattern. A typical vulnerable implementation might look like:

// Vulnerable code (Ruoyi v4.8.0)
public void resetPassword(String loginName) {
    // No check for existing reset request
    User user = userDao.findByLoginName(loginName);
    if (user != null) {
        // Process reset - could be called multiple times
        processReset(user);
    }
}

A patched version would include a check to prevent duplicate processing:

// Patched code (hypothetical)
public void resetPassword(String loginName) {
    // Check if a reset request is already in progress
    if (resetRequestDao.existsByLoginName(loginName)) {
        throw new DuplicateResetRequestException("Reset already in progress");
    }
    User user = userDao.findByLoginName(loginName);
    if (user != null) {
        // Create a unique reset request
        resetRequestDao.create(loginName);
        processReset(user);
    }
}

Exploitation & Lab Setup

Red Team

Prerequisites:

  • Admin credentials for a Ruoyi v4.8.0 instance.
  • Network access to the password reset endpoint (e.g., /system/user/resetPwd).

Exploitation Steps:

  1. Log in as an Admin user.
  2. Identify the password reset API endpoint (e.g., via browser developer tools or API documentation).
  3. Send multiple concurrent requests to the reset password interface with the same login name (e.g., admin).
  4. Observe the system behavior: service slowdown, unresponsiveness, or crash.

Example cURL command:

for i in {1..100}; do
  curl -X POST "https://target.com/system/user/resetPwd" \
    -H "Authorization: Bearer <admin_token>" \
    -d "loginName=admin" &
done
wait

Blue Team

Detection:

  • Monitor for multiple password reset requests from the same Admin user within a short time window.
  • Alert on high CPU or memory usage correlated with reset password API calls.
  • Review logs for duplicate login name entries in reset requests.

Mitigation:

  • Implement rate limiting on the reset password endpoint.
  • Add input validation to reject duplicate reset requests.
  • Apply the principle of least privilege: restrict Admin access to trusted users only.

Indicators of Compromise (IOCs)

  • Network: Multiple POST requests to /system/user/resetPwd with the same loginName parameter from a single Admin session.
  • Logs: Repeated entries like Reset password requested for user: admin within seconds.
  • System: High CPU usage by the Java application process, database connection pool exhaustion, or application crash.

Detection Engineering

YARA Rule

rule Detect_Ruoyi_DoS_ResetPassword {
    meta:
        description = "Detects potential DoS attack via duplicate password reset in Ruoyi v4.8.0"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-57439"
    strings:
        $s1 = "resetPwd" ascii wide nocase
        $s2 = "loginName" ascii wide nocase
        $s3 = "admin" ascii wide nocase
    condition:
        all of ($s1, $s2, $s3) and #s1 > 10
}

Sigma Rule

title: Ruoyi Password Reset DoS Attempt
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects multiple password reset requests with the same login name in Ruoyi v4.8.0
author: Valters IT
date: 2025-04-10
logsource:
    category: application
    product: ruoyi
detection:
    selection:
        EventID: 1001  # Example event ID for password reset
        loginName: 'admin'
    timeframe: 5m
    condition: selection | count() > 10
falsepositives:
    - Legitimate admin testing
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-57439 Ruoyi Password Reset DoS Attempt"; flow:to_server; content:"POST"; http_method; content:"/system/user/resetPwd"; http_uri; content:"loginName=admin"; http_client_body; threshold:type both, track by_src, count 10, seconds 300; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

  1. Restrict Admin Access: Limit the number of users with Admin privileges to only essential personnel.
  2. Implement Rate Limiting: Use a reverse proxy (e.g., Nginx) or application-level middleware to limit requests to the reset password endpoint.
  3. Monitor Logs: Enable detailed logging for password reset operations and set up alerts for anomalies.

Long-term Fix:

  • Apply a vendor patch if/when released. Contact Ruoyi support for an update.
  • Modify the source code to prevent duplicate reset requests (see Vulnerable vs. Patched Code section).
  • Upgrade to a patched version of Ruoyi once available.

Workaround:

  • Disable the password reset functionality for Admin users if not critical, or implement a manual approval process.

Valters IT

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2024-57439/ · 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.