CVE-2025-58448: Rathena MMORPG Server SQLi Vulnerability

CVE-2025-58448 Overview

CVE-2025-58448 is a critical SQL Injection vulnerability affecting rAthena, an open-source cross-platform massively multiplayer online role playing game (MMORPG) server. The vulnerability exists in the PartyBooking component and can be exploited through the WorldName parameter, allowing attackers to inject malicious SQL queries that could compromise the integrity, confidentiality, and availability of the underlying database.

Critical Impact

This SQL Injection vulnerability allows unauthenticated remote attackers to execute arbitrary SQL commands against the rAthena database, potentially leading to complete database compromise, data exfiltration, data manipulation, or denial of service.

Affected Products

• rAthena MMORPG Server (versions prior to commit 0d89ae0)
• All rAthena deployments using the PartyBooking functionality without the security patch

Discovery Timeline

• 2025-09-09 - CVE-2025-58448 published to NVD
• 2025-09-17 - Last updated in NVD database

Technical Details for CVE-2025-58448

Vulnerability Analysis

This SQL Injection vulnerability (CWE-89) stems from improper input validation in the PartyBooking component of rAthena. The WorldName parameter is directly concatenated into SQL queries without proper sanitization or parameterization, creating a classic injection vector that attackers can exploit remotely without authentication.

The vulnerable code path exists in src/web/partybooking_controller.cpp, where user-supplied world_name values are passed directly to SQL DELETE statements. This allows an attacker to manipulate the query structure by crafting malicious input containing SQL metacharacters or commands.

Root Cause

The root cause of this vulnerability is the failure to properly escape or parameterize user-controlled input before incorporating it into SQL queries. The original code directly inserted the world_name.c_str() value into the SQL query string, enabling attackers to break out of the intended query context and inject arbitrary SQL commands.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by sending specially crafted requests to the PartyBooking component containing malicious SQL payloads in the WorldName parameter. Successful exploitation could allow:

• Extraction of sensitive database contents including user credentials and game data
• Modification or deletion of database records
• Potential execution of database administrative operations
• Complete database server compromise depending on database permissions

The security patch addresses this by implementing proper SQL escaping using Sql_EscapeString():

 	return;
 }

+	char world_name_escaped[WORLD_NAME_LENGTH * 2 + 1];
+
+	Sql_EscapeString( nullptr, world_name_escaped, world_name.c_str() );
+
 	SQLLock sl( MAP_SQL_LOCK );
 	sl.lock();
 	auto handle = sl.getHandle();

-	if( SQL_ERROR == Sql_Query( handle, "DELETE FROM `%s` WHERE `world_name` = '%s' AND `account_id` = '%d'", partybookings_table, world_name.c_str(), account_id ) ){
+	if( SQL_ERROR == Sql_Query( handle, "DELETE FROM `%s` WHERE `world_name` = '%s' AND `account_id` = '%d'", partybookings_table, world_name_escaped, account_id ) ){
 		Sql_ShowDebug( handle );

 		sl.unlock();

Source: GitHub Commit 0d89ae0

Detection Methods for CVE-2025-58448

Indicators of Compromise

• Unusual or malformed requests to the PartyBooking API endpoint containing SQL metacharacters (', ", ;, --, /*)
• Database query logs showing unexpected SQL syntax errors or injection patterns in queries involving the partybookings table
• Abnormal database access patterns such as bulk data extraction or unauthorized table access
• Web server logs containing encoded or obfuscated SQL injection payloads in the WorldName parameter

Detection Strategies

• Deploy Web Application Firewall (WAF) rules to detect and block SQL injection patterns in HTTP requests targeting the PartyBooking component
• Implement database query logging and monitor for anomalous queries containing injection indicators
• Configure intrusion detection systems (IDS) to alert on SQL injection signature patterns in network traffic
• Review application logs for requests with unusually long WorldName values or special characters

Monitoring Recommendations

• Enable verbose logging on the rAthena web server to capture all incoming requests to the PartyBooking endpoint
• Set up real-time alerting for database errors related to SQL syntax in the partybookings table queries
• Monitor database connection patterns for unusual activity such as data exfiltration or privilege escalation attempts
• Implement audit logging for all database modifications to the partybookings table

How to Mitigate CVE-2025-58448

Immediate Actions Required

• Update rAthena to commit 0d89ae0 or later immediately to apply the security patch
• If immediate patching is not possible, disable or restrict access to the PartyBooking component until the fix can be applied
• Review database access logs for any signs of prior exploitation
• Rotate database credentials if exploitation is suspected or cannot be ruled out

Patch Information

The vulnerability has been addressed in commit 0d89ae0. The fix implements proper SQL escaping using the Sql_EscapeString() function to sanitize the world_name parameter before it is used in SQL queries. Server administrators should update their rAthena installations to this commit or any subsequent version.

• Security Patch Commit
• GitHub Security Advisory GHSA-x99j-36m7-4vv7

Workarounds

• Implement network-level restrictions to limit access to the PartyBooking API endpoint to trusted IP addresses only
• Deploy a reverse proxy or WAF with SQL injection filtering rules in front of the rAthena web server
• Disable the PartyBooking feature entirely if it is not critical to operations until the patch can be applied
• Apply principle of least privilege to database accounts used by rAthena to limit potential damage from exploitation

# Example: Restrict PartyBooking access via iptables (temporary workaround)
# Replace <TRUSTED_IP> with your trusted IP address and <RATHENA_PORT> with the actual port
iptables -A INPUT -p tcp --dport <RATHENA_PORT> -s <TRUSTED_IP> -j ACCEPT
iptables -A INPUT -p tcp --dport <RATHENA_PORT> -j DROP