CVE-2026-35168: Authenticated Remote Code Execution via SQL Injection in OpenSTAManager Aggiornamenti Module

OpenSTAManager is an open-source management software for technical assistance and invoicing. The application includes an Aggiornamenti (Updates) module designed to handle system upgrades and resolve database schema conflicts. This module contains a critical vulnerability in how it processes administrative actions related to database synchronization.

The specific flaw exists within the op=risolvi-conflitti-database endpoint. This feature is intended to apply structural changes to the database to resolve schema disparities. The implementation fails to enforce boundaries between data and control planes, trusting client-side input to dictate the exact SQL commands executed by the backend.

An authenticated attacker with access to the updates module can exploit this design flaw. By supplying a crafted payload, the attacker dictates the precise queries executed by the application database driver. The vulnerability constitutes an Improper Neutralization of Special Elements used in an SQL Command (CWE-89).

The vulnerability is localized within the modules/aggiornamenti/actions.php script. When a user sends a POST request with the operation parameter set to risolvi-conflitti-database, the application parses a JSON-encoded array from the queries POST parameter. The application decode this payload into a standard PHP array of strings.

The application iterates over this array and executes each string as a direct SQL query via the $dbo->query() method. The backend applies zero validation, sanitization, or allowlist checks to the strings prior to execution. The parameter is entirely user-controlled and treated as a sequence of trusted instructions.

Furthermore, the application explicitly executes SET FOREIGN_KEY_CHECKS=0 before initiating the query loop. This command disables referential integrity checks across the entire database session. The application executes SET FOREIGN_KEY_CHECKS=1 only after the loop concludes. This state change removes structural protections, allowing attackers to delete or mutate records that would normally be protected by relational constraints.

The vulnerable code path implemented a direct pipeline from the HTTP request to the database driver. The original implementation extracted the queries parameter, decoded it, and passed it to the database object without scrutiny.

$queries = json_decode($_POST['queries'], true);
$dbo->query('SET FOREIGN_KEY_CHECKS=0');
foreach ($queries as $query) {
    try {
        $dbo->query($query);
    } catch (Exception $e) {
        $errors[] = $query.' - '.$e->getMessage();
    }
}
$dbo->query('SET FOREIGN_KEY_CHECKS=1');

The maintainers addressed this vulnerability in commit 43970676bcd6636ff8663652fd82579f737abb74 by introducing a regular expression allowlist. The updated logic validates each query string against predefined safe patterns before execution.

$allowed_patterns = [
    '/^ALTER\s+TABLE\s+`?[\w]+`?\s+(ADD|MODIFY|CHANGE|DROP)\s+(COLUMN\s+)?`?[\w]+`?/i',
    '/^CREATE\s+(UNIQUE\s+)?INDEX\s+`?[\w]+`?\s+ON\s+`?[\w]+`?\s*\(/i',
    '/^DROP\s+INDEX\s+`?[\w]+`?\s+ON\s+`?[\w]+`?$/i',
    '/^UPDATE\s+`?zz_views`?\s+SET\s+/i',
    '/^INSERT\s+INTO\s+`?zz_\w+`?\s*\(/i',
    '/^DELETE\s+FROM\s+`?zz_\w+`?\s+WHERE\s+/i',
];

While the patch significantly reduces the attack surface, the regular expressions validate only the prefix of the queries. The UPDATE and INSERT regex patterns do not inspect the right-hand side of the query. Attackers can still inject subqueries into the SET or VALUES clauses of permitted tables to exfiltrate data.

Exploitation requires an active user session with authorization to access the Aggiornamenti module. The attacker intercepts or crafts an HTTP POST request directed at the actions.php endpoint. The attacker structures the payload as a JSON array of malicious SQL statements.

The attacker constructs the queries POST variable. An example payload designed to destroy data is queries=["DROP TABLE users;"]. An attacker focused on persistence or privilege escalation creates queries that manipulate authentication tables or configuration parameters.

The application returns database driver errors in the HTTP response if a query fails. The attacker parses these error strings to enumerate database schemas, table names, and column types. This immediate feedback loop facilitates reliable exploitation and lateral movement within the database layer.

The vulnerability completely compromises the confidentiality, integrity, and availability of the application database. The attacker controls the specific SQL statements executed, circumventing all application-layer access controls. The severity is reflected in the CVSS v3.1 vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

The attacker executes commands in the context of the database user configured for the application. Management applications typically provision database users with extensive privileges, including Data Definition Language (DDL) rights. The attacker leverages these privileges to modify database schemas, alter stored procedures, or extract sensitive financial data.

The application relies on MySQL or MariaDB backends. If the database user retains the FILE privilege, the attacker utilizes SELECT INTO OUTFILE to write arbitrary files to the host filesystem. This technique directly escalates the database compromise into arbitrary remote code execution on the application server.

Organizations utilizing OpenSTAManager must upgrade the application to version 2.10.2 or later immediately. The official release integrates the regex-based allowlist, preventing arbitrary query execution. System administrators should verify the deployed version via the application dashboard.

Administrators must enforce the principle of least privilege at the database layer. The application database user must not possess global administrative privileges or the FILE privilege. Revoking DROP and ALTER permissions during normal operations limits the blast radius of similar vulnerabilities.

Security teams should deploy Web Application Firewall (WAF) rules targeting the specific API endpoint. WAF implementations should inspect the queries parameter within POST requests directed at modules/aggiornamenti/actions.php. Rules detecting JSON-encoded SQL keywords provide an additional defensive layer against exploitation attempts.