SQL injection in SVX Portal v.2.7A via unsafe update of Settings table in admin/update_setings.php

Product: SVXportal (source tree: SVXportal-master)

Affected file: admin/update_setings.php

Affected lines (example):

foreach ($_POST as $define => $value ) {
    $define = $link->real_escape_string($define);
    $value = $link->real_escape_string($value);
    $link->query("UPDATE `Settings` SET `value` = '$value' WHERE `Settings`.`Define` = '$define'; ");
}

• CWE: CWE-89 Improper Neutralization of Special Elements used in an SQL Command
• Severity: High (business impact), CVSS v3.1 base score: 5.9 (MEDIUM) - vector: AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:L
  • Rationale: Attackable over the network but requires a high privileged authenticated admin session. The vulnerability directly modifies database state which can have high integrity impact and may enable wider attack chains.

Overview

This is a classic SQL injection vulnerability where the application constructs SQL statements by interpolating POST-supplied keys and values directly into SQL strings. Although the code applies real_escape_string to inputs, relying on string escaping alone is fragile and can be bypassed in several realistic scenarios, for example when the connection charset is misconfigured, multibyte encodings are present, or application code later concatenates strings in different contexts. Furthermore, the code accepts POST keys as setting names and applies them directly to the WHERE clause, making the set of writable columns configurable by user input. This creates a mass-assignment like pathway combined with SQL injection: an attacker can control both the column selector and the updated value within the same request.

High-level impact is that an attacker who can send POST requests to this endpoint can alter configuration settings stored in the Settings table, inject SQL payloads to read or modify other tables, and cause persistent application misconfiguration. Changing settings could disable security controls, alter feature flags, leak credentials, or otherwise pivot to further compromise.

Technical Details

The endpoint’s intended purpose is to iterate over submitted form fields and update the corresponding Settings rows; each POST key corresponds to a Settings.Define entry and the value is written into Settings.value. The code loops through $_POST, escapes each key and value with real_escape_string, and issues an UPDATE per key. This design assumes every POST key is a valid, allowed setting and that escaping is sufficient to prevent injection.

In practice, the implementation fails in two ways. First, treating POST keys as dynamic identifiers without a server-side allowlist permits clients to target arbitrary Settings.Define values. Second, building SQL via string interpolation and relying solely on escaping produces fragile protection. If the database connection uses an unexpected charset or the escaping is not applied uniformly to every code path, a crafted input can break out of the quoted literal or manipulate the SQL grammar. Because both the column selector (Define) and the value are attacker-controlled, it's possible to craft inputs that alter the WHERE clause semantics or inject additional SQL statements (depending on server configuration) or cause logical updates to other rows. The cumulative result is that an attacker can tamper with application configuration or leverage the vector to extract or change additional data.

Backend weaknesses enabling the issue include: no server-side allowlist of permitted setting names, dynamic SQL construction with user-supplied identifiers, absence of prepared/parameterized queries, and lack of per-endpoint authorization checks and audit logging to detect unexpected configuration changes.

If the vulnerability exposes sensitive data in JSON responses elsewhere, critical data at risk includes administrative flags, feature toggles, API keys, and any configuration values persisted in Settings. Because settings often control authentication, integration keys, or security toggles, the impact extends beyond a single record to system-level behavior.

Steps to Reproduce

1. Authenticate as a user that can reach admin/update_setings.php (for example an admin UI session), or craft a CSRF-assisted POST from a victim browser if CSRF defenses are missing.
2. Intercept or craft an HTTP POST to the endpoint with a POST body that includes a malicious POST key or value (examples below).
3. Send the request and observe that the Settings table has been modified or that unexpected SQL behavior occurs.

Proof of Concept (PoC)

Test only in a controlled environment or against systems you are authorized to test. The PoC demonstrates the vector; do not run destructive payloads against production.

Example HTTP request (replace host, session cookie, and path accordingly):

• POST /admin/update_setings.php HTTP/1.1 Host: example.com User-Agent: curl/7.86.0 Content-Type: application/x-www-form-urlencoded Cookie: PHPSESSID=<valid_session_with_access> normal_setting=normalValue&new_setting=someValue

Malicious example to demonstrate mutation of a different setting name (payload encoded form):

POST /admin/update_setings.php HTTP/1.1 
Host: example.com 
Content-Type: application/x-www-form-urlencoded 
Cookie: PHPSESSID=<session> 

dummy=1&' OR '1'='1'-- =1

Observe database changes or errors in application logs that indicate the SQL text was malformed or executed. A safe, read-only test can attempt to cause a predictable SQL error to confirm injection without altering data.

Impact

An attacker can alter application configuration values system-wide, persist malicious configuration, and potentially escalate an initial foothold. Because many applications store keys, flags, and security toggles in configuration tables, an attacker can disable security controls, change redirect URIs, or expose secrets. The scope can be tenant-wide (affecting all users) and can be automated to target many settings at scale. If chained with weak DB user permissions or additional injection vectors, the issue can lead to data exfiltration, persistent application compromise, or denial of service.

References

• OWASP SQL Injection Prevention Cheat Sheet.
• CWE-89: Improper Neutralization of Special Elements used in an SQL Command.