CVE-2024-58358

Executive Summary

This report details CVE-2024-58358, a denial of service (DoS) vulnerability in SurrealDB versions prior to 2.1.0. The flaw resides in the role conversion logic, allowing a privileged owner user to define users with nonexistent roles. When an attacker signs in with a user account assigned such an invalid role, the server triggers an uncaught panic, causing a crash and resulting in a denial of service.

Business Impact: Organizations using SurrealDB as a backend database for critical applications are at risk. A successful attack can cause service disruption, impacting application availability, data access, and potentially leading to financial loss or reputational damage. The likely attacker is a malicious insider or an external attacker who has compromised an owner-level account.

Vulnerability Class & Attack Vector: This is a Denial of Service (DoS) vulnerability. The attack vector is network-accessible, requiring authentication with owner-level privileges to create the malicious user. The actual crash is triggered by a subsequent login attempt with the crafted user account.

Urgency Assessment: The CVSS score is 4.9 (Medium), and the EPSS probability is 0.0%, indicating no known active exploitation in the wild as of the report date. Despite the low EPSS, the vulnerability is unpatched in older versions and can be reliably triggered by an authenticated owner, making it a significant risk for environments where owner credentials are not tightly controlled.

Key Facts:

• Vendor: SurrealDB
• Affected Versions: All versions before 2.1.0
• Patch Status: Unpatched in versions < 2.1.0. Upgrade to 2.1.0 is required.
• CISA KEV: Not listed.

CVSS Breakdown & Threat Level

CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H

• AV:N (Network): The vulnerability can be exploited remotely over the network. An attacker does not need physical or local access to the server.
• AC:L (Low): The attack complexity is low. The steps to exploit are straightforward: create a user with a nonexistent role and then log in as that user. No special conditions or race conditions are required.
• PR:H (High): The attacker must have high-level privileges (owner role) to create the malicious user account. This significantly reduces the attack surface, as it requires a privileged account.
• UI:N (None): No user interaction is required. The attacker can automate the entire process.
• S:U (Unchanged): A successful exploit does not affect resources beyond the vulnerable component. The crash is contained within the SurrealDB server process.
• C:N (None): There is no impact on data confidentiality.
• I:N (None): There is no impact on data integrity.
• A:H (High): The vulnerability causes a complete denial of service. The server crashes and becomes unavailable, requiring a restart to restore service.

Qualitative Severity: Medium. The high privileges required (PR:H) lower the overall severity, but the complete availability impact (A:H) and network exploitability make it a serious concern for environments with compromised or untrusted owner accounts.

EPSS Interpretation: An EPSS score of 0.0% means that, based on current threat intelligence, the probability of this CVE being exploited in the wild within the next 30 days is negligible. This is common for newly published vulnerabilities or those requiring high privileges.

Comparison to Similar CVEs: This vulnerability is similar to other DoS flaws in database systems caused by improper input validation or state handling. For example, CVE-2023-30839 in PrestaShop allowed a DoS via a crafted cart. The key differentiator here is the requirement for owner-level privileges.

Temporal & Environmental Scores: The temporal score is currently at the base score due to no patch or exploit being available. The environmental score can be adjusted based on the organization's specific context. For example, if the SurrealDB server is not exposed to the internet and owner accounts are strictly controlled, the risk is lower. If the server is publicly accessible and owner credentials are weak, the risk is higher.

Technical Deep Dive & Attack Mechanics

Step-by-Step Technical Explanation:

1. Privileged User Creation: An attacker with an owner-level account authenticates to the SurrealDB server.
2. Role Manipulation: The attacker uses the owner's privileges to define a new user account. Instead of assigning a valid, existing role (e.g., viewer, editor, admin), the attacker specifies a role name that does not exist (e.g., nonexistent_role_xyz).
3. Triggering the Crash: The attacker (or a different user) then attempts to authenticate to the SurrealDB server using the credentials of the newly created user with the invalid role.
4. Uncaught Panic: During the authentication process, the server attempts to resolve the user's role. When it encounters the nonexistent role, the code path does not handle this exceptional condition gracefully. Instead, it triggers an uncaught panic (a runtime error in Rust, the language SurrealDB is written in).
5. Denial of Service: This uncaught panic causes the SurrealDB server process to crash immediately, making the database unavailable to all users until the process is manually restarted.

Root Cause Analysis: The root cause is a lack of input validation and error handling in the role assignment and authentication logic. The developer assumed that a user's role would always exist, failing to check for the case where a role is defined but does not correspond to any valid role definition. This is a classic example of CWE-754: Improper Check for Unusual or Exceptional Conditions.

Attack Surface: The attack surface is the SurrealDB network port (default 8000) used for client connections. The exploit requires two authenticated requests: one to create the user (owner-level) and one to log in (any user level).

Pre-conditions for Exploitation:

• Network access to the SurrealDB server.
• Valid owner-level credentials to create the malicious user.
• The ability to authenticate as the newly created user.

Attack Variants: The primary variant is the one described. An attacker could also potentially create multiple users with invalid roles to cause repeated crashes.

Why Standard Defenses May Fail:

• WAF/IDS: A Web Application Firewall (WAF) or Intrusion Detection System (IDS) may not detect this attack because the initial request to create a user with a nonexistent role appears to be a legitimate administrative action. The subsequent login request is also standard. The malicious payload is the role name itself, which may not match typical attack signatures.
• Authentication Controls: Standard authentication controls will not prevent this because the attacker is using valid credentials for both steps.

Vulnerable vs. Patched Code Analysis

Vulnerable Code (Pseudocode):

// Vulnerable: Assumes role always exists
fn authenticate_user(username: String, password: String) -> Result<Session, Error> {
    let user = db.get_user(username)?;
    // Directly unwrap or assume role exists
    let role = db.get_role(user.role_id).unwrap(); // PANIC if role doesn't exist
    // ... rest of authentication logic
}

Patched Code (Pseudocode):

// Patched: Checks for role existence
fn authenticate_user(username: String, password: String) -> Result<Session, Error> {
    let user = db.get_user(username)?;
    // Check if the role exists
    let role = match db.get_role(user.role_id) {
        Some(role) => role,
        None => return Err(Error::InvalidRole), // Graceful error handling
    };
    // ... rest of authentication logic
}

Specific Component: The bug resides in the authentication module, specifically in the function that resolves a user's role during login.

What the Patch Changes: The patch replaces the unwrap() call (which causes a panic on None) with a match statement that checks if the role exists. If the role does not exist, it returns a proper error instead of crashing the server.

Regression Considerations: The patch is a minimal change that should not introduce regressions. It simply adds a safety check. Teams should ensure that their application logic can handle the new InvalidRole error gracefully.

Timeline & Disclosure History

• CVE Publication Date: 2026-07-18T14:17:08.643
• Estimated Discovery Timeline: The exact discovery date is unknown. The vulnerability was likely discovered through internal security research or responsible disclosure.
• Disclosure Process: The CVE was published by the CNA (CVE Numbering Authority) for SurrealDB. The details suggest a coordinated disclosure, as a fix (version 2.1.0) was released prior to or concurrently with the CVE publication.
• Known Exploitation in the Wild: No known active exploitation as of 2026-07-18.
• CISA KEV Addition Date: Not applicable.

Threat Intelligence Context

Threat Actor Profile: This vulnerability is most likely to be exploited by:

• Malicious Insiders: A disgruntled employee or contractor with owner-level access could easily trigger this DoS to disrupt operations.
• Script Kiddies: If a simple exploit script is released, script kiddies could use it to take down vulnerable SurrealDB instances.
• Ransomware Operators: While not a direct ransomware vector, a DoS could be used as a distraction or as part of a multi-stage attack to disrupt backups or monitoring before deploying ransomware.

Attack Campaign Context: There are no known campaigns specifically targeting this CVE.

Geographic Targeting Patterns: None known.

Industry Verticals Most at Risk: Any industry using SurrealDB for critical applications, including:

• Technology: Startups and companies using SurrealDB as their primary database.
• Finance: Applications requiring high availability.
• E-commerce: Online stores relying on SurrealDB for product catalogs and user data.

Connection to Similar Vulnerability Classes: This is a classic example of a DoS vulnerability caused by improper error handling, a common class of bugs in software written in languages like Rust that use panic! for unrecoverable errors.

Exploitation & Lab Setup

Red Team Section

Lab Setup:

1. Environment: Use Docker to run a vulnerable version of SurrealDB.

   docker run --name surreal-db-vuln -p 8000:8000 surrealdb/surrealdb:v2.0.0 start
   

2. Prerequisites: Install the SurrealDB CLI (surreal) on your attack machine.
3. Exploitation Walkthrough:
   • Step 1: Authenticate as Owner. Use the default root credentials to log in.

     surreal sql --conn http://localhost:8000 --user root --pass root --ns test --db test
     

   • Step 2: Create a User with a Nonexistent Role. Inside the SQL shell, execute:

     DEFINE USER attacker_user ON DB PASSWORD 'password' ROLES nonexistent_role;
     

   • Step 3: Trigger the Crash. Exit the SQL shell and attempt to log in as the new user.

     surreal sql --conn http://localhost:8000 --user attacker_user --pass password --ns test --db test
     

   • Expected Output: The SurrealDB server will crash. The Docker container will stop. You will see an error message like Connection refused or the command will hang and eventually time out.

Post-Exploitation: After the crash, the database is completely unavailable. An attacker would need to wait for an administrator to restart the server. They could repeat the process to maintain the DoS.

Blue Team Section

How to Detect Active Exploitation Attempts:

• Monitor for DEFINE USER statements that assign a role name that does not match any existing DEFINE ROLE statement.
• Look for repeated authentication failures followed by a server crash.
• Monitor server logs for uncaught panic messages.

Log Entries That Indicate Exploitation:

• SurrealDB logs may contain a panic message similar to: thread 'main' panicked at 'called Option::unwrap()on aNone value', src/auth.rs:LINE:COL
• Authentication logs showing a successful login for a user with an unusual role name.

Network Traffic Signatures:

• The attack traffic will consist of standard SurrealDB protocol messages. There is no specific malicious payload in the network packets beyond the role name.

Endpoint Behavioral Indicators:

• The SurrealDB process (surreal) will terminate unexpectedly.
• A core dump file may be generated if the system is configured to do so.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Repeated connections from a single IP address performing DEFINE USER and SIGNIN operations.
• HTTP Request Patterns:
  • POST requests to the SurrealDB endpoint containing a DEFINE USER statement with a ROLES parameter set to a value that is not a known role.
• File System Artifacts:
  • Core dump files from the crashed surreal process.
• Process Execution Anomalies:
  • The surreal process exiting with a non-zero exit code or being killed by a signal.
• Log Entries:
  • Server logs containing the string panicked at 'called Option::unwrap()on aNone value'.

STIX-like IOC List:

Detection Engineering

YARA Rule

rule CVE_2024_58358_Surrealdb_Panic_Log {
    meta:
        description = "Detects SurrealDB log entries indicating the CVE-2024-58358 panic"
        author = "Valters IT Hub"
        date = "2026-07-18"
        reference = "https://www.valtersit.com/cve/cve-2024-58358"
    strings:
        $panic_string = "panicked at 'called `Option::unwrap()` on a `None` value'"
        $auth_file = "src/auth.rs" nocase
    condition:
        $panic_string and $auth_file
}

Sigma Rule (SIEM)

title: CVE-2024-58358 Surrealdb Denial of Service via Role Conversion
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: experimental
description: Detects a SurrealDB server crash caused by a user with a nonexistent role.
author: Valters IT Hub
date: 2026-07-18
references:
    - https://www.valtersit.com/cve/cve-2024-58358
logsource:
    category: application
    product: surrealdb
detection:
    selection:
        EventID: 1000  # Example: Application Error Event ID
        Provider_Name: 'Application Error'
        Faulting_Application: 'surreal.exe' or 'surreal'
        Exception_Code: '0xc0000005' # Example: Access Violation
    condition: selection
falsepositives:
    - Other application crashes unrelated to this CVE.
level: high

Suricata IDS Rule

alert tcp $EXTERNAL_NET any -> $HOME_NET 8000 (msg:"CVE-2024-58358 Surrealdb Potential DoS - User Creation with Invalid Role"; content:"DEFINE USER"; content:"ROLES"; pcre:"/ROLES\s+[a-zA-Z_]+[^;]*[^a-zA-Z_]/i"; classtype:attempted-dos; sid:1000001; rev:1;)

Note: This rule is a heuristic and may generate false positives. It looks for DEFINE USER statements where the role name might be unusual.

Elastic (EQL) Query

process where event.type == "termination" and
  process.name == "surreal" and
  exit_code != 0

Note: This is a generic detection for a crashed SurrealDB process. It should be correlated with other logs.

Splunk SPL Query

index=main sourcetype="surrealdb:log" "panicked at 'called `Option::unwrap()` on a `None` value'"
| table _time, host, source, message

Wazuh Rule

<group name="surrealdb,">
  <rule id="100001" level="12">
    <decoded_as>json</decoded_as>
    <field name="message">panicked at 'called `Option::unwrap()` on a `None` value'</field>
    <description>SurrealDB CVE-2024-58358: Server crash due to invalid role.</description>
    <options>no_full_log</options>
  </rule>
</group>

Remediation & Mitigation

Immediate Actions (0-24 hours)

• Apply Patch: Upgrade SurrealDB to version 2.1.0 or later.

  # For Docker
  docker pull surrealdb/surrealdb:latest
  docker stop <container_name>
  docker run --name surreal-db-patched -p 8000:8000 surrealdb/surrealdb:latest start
  

• Compensating Controls (If No Patch):
  • Restrict Owner Access: Strictly limit the number of users with the owner role. Use strong, unique passwords and enforce multi-factor authentication (MFA) for these accounts.
  • Network Segmentation: Place the SurrealDB server behind a firewall and restrict access to only trusted IP addresses.
  • Monitoring: Implement the detection rules above to alert on any attempts to create users with unusual roles or any server crashes.

Short-term (1-7 days)

• Configuration Hardening: Review all existing user accounts and roles. Ensure no users are assigned to roles that do not exist.
• Monitoring Implementation: Deploy the YARA, Sigma, and Splunk rules provided in this report to monitor for exploitation attempts.
• Vulnerability Scanning: Use a vulnerability scanner to confirm that the SurrealDB version is 2.1.0 or later.

  surreal version
  

Long-term

• Architecture Changes: Consider implementing a principle of least privilege for database access. Avoid using the owner role for routine operations.
• Security Control Improvements: Implement a Web Application Firewall (WAF) with custom rules to inspect SurrealDB queries for suspicious patterns.
• Developer Training: Educate developers on the importance of proper error handling and avoiding unwrap() calls on potentially None values in Rust.

Validation

To confirm the patch has been applied:

1. Check the SurrealDB version:

   surreal version
   

   The output should be 2.1.0 or higher.
2. Attempt to reproduce the vulnerability in a test environment. If the server no longer crashes when logging in with a user assigned a nonexistent role, the patch is effective.

References & Resources

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2024-58358
• CVE.org: https://www.cve.org/CVERecord?id=CVE-2024-58358
• Vendor advisory: See vendor security page
• OSV: https://osv.dev/vulnerability/CVE-2024-58358 (if applicable)
• Related CWE: https://cwe.mitre.org/data/definitions/754.html
• MITRE ATT&CK: https://attack.mitre.org/techniques/T1499/

Report generated by Valters IT Hub Neural Engine v25 | 2026-07-18 | https://www.valtersit.com/cve/cve-2024-58358