CVE-2026-24416

OpenSTAManager is an open source management software for technical assistance and invoicing. OpenSTAManager v2.9.8 and earlier contain a critical Time-Based Blind SQL Injection vulnerability in the article pricing completion handler. The application fails to properly sanitize the idarticolo parameter before using it in SQL queries, allowing attackers to inject arbitrary SQL commands and extract sensitive data through time-based Boolean inference.

OpenSTAManager is an open source management software for technical assistance and invoicing. OpenSTAManager v2.9.8 and earlier contain a critical Time-Based Blind SQL Injection vulnerability in the article pricing completion handler. The application fails to properly sanitize the idarticolo parameter before using it in SQL queries, allowing attackers to inject arbitrary SQL commands and extract sensitive data through time-based Boolean inference.

Summary

Critical Time-Based Blind SQL Injection vulnerability in the article pricing module of OpenSTAManager v2.9.8 allows authenticated attackers to extract complete database contents including user credentials, customer data, and financial records through time-based Boolean inference attacks.

Status: ✅ Confirmed and tested on live instance (v2.9.8) end demo.osmbusiness.it (v2.9.7) Vulnerable Parameter: idarticolo (GET) Affected Endpoint: /ajax_complete.php?op=getprezzi Affected Module: Articoli (Articles/Products)

Details

OpenSTAManager v2.9.8 contains a critical Time-Based Blind SQL Injection vulnerability in the article pricing completion handler. The application fails to properly sanitize the idarticolo parameter before using it in SQL queries, allowing attackers to inject arbitrary SQL commands and extract sensitive data through time-based Boolean inference.

Vulnerability Chain:

1. Entry Point: /ajax_complete.php (Line 27)

   $op = get('op');
   $result = AJAX::complete($op);
   

   The op parameter is retrieved but the vulnerability lies in other parameters.

2. Distribution: /src/AJAX.php::complete() (Line 189)

   $result = self::getCompleteResults($file, $resource);
   

3. Execution: /src/AJAX.php::getCompleteResults() (Line 402)

   require $file;
   

   Module-specific complete.php files are included.

4. Vulnerable Parameter: /modules/articoli/ajax/complete.php (Line 26)

   $idarticolo = get('idarticolo');
   

   The idarticolo parameter is retrieved from GET request.

5. Vulnerable SQL Query: /modules/articoli/ajax/complete.php (Line 70) PRIMARY VULNERABILITY

   FROM
       `dt_righe_ddt`
       INNER JOIN `dt_ddt` ON `dt_ddt`.`id` = `dt_righe_ddt`.`idddt`
       INNER JOIN `dt_tipiddt` ON `dt_tipiddt`.`id` = `dt_ddt`.`idtipoddt`
   WHERE
       `idarticolo`='.$idarticolo.' AND
       `dt_tipiddt`.`dir`="entrata" AND
       `idanagrafica`='.prepare($idanagrafica).'
   

   Impact: Direct concatenation of $idarticolo without prepare(), while $idanagrafica is properly sanitized.

Context - Full Query Structure (Lines 39-74):

The vulnerable query is part of a UNION query that fetches pricing history from invoices and delivery notes:

$documenti = $dbo->fetchArray('
    SELECT
        `iddocumento` AS id,
        "Fattura" AS tipo,
        "Fatture di vendita" AS modulo,
        (`subtotale`-`sconto`)/`qta` AS costo_unitario,
        ...
    FROM
        `co_righe_documenti`
        INNER JOIN `co_documenti` ON `co_documenti`.`id` = `co_righe_documenti`.`iddocumento`
        INNER JOIN `co_tipidocumento` ON `co_tipidocumento`.`id` = `co_documenti`.`idtipodocumento`
    WHERE
        `idarticolo`='.prepare($idarticolo).' AND ...  # ✓ PROPERLY SANITIZED (Line 54)
UNION
    SELECT
        `idddt` AS id,
        "Ddt" AS tipo,
        ...
    FROM
        `dt_righe_ddt`
        INNER JOIN `dt_ddt` ON `dt_ddt`.`id` = `dt_righe_ddt`.`idddt`
        INNER JOIN `dt_tipiddt` ON `dt_tipiddt`.`id` = `dt_ddt`.`idtipoddt`
    WHERE
        `idarticolo`='.$idarticolo.' AND   # ✗ VULNERABLE - NO prepare() (Line 70)
        `dt_tipiddt`.`dir`="entrata" AND
        `idanagrafica`='.prepare($idanagrafica).'
ORDER BY
    `id` DESC LIMIT 0,5');

Root Cause: Developer used prepare() correctly in the first SELECT (Line 54) but forgot to use it in the second SELECT of the UNION query (Line 70), creating an inconsistent security pattern.

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 (Time-Based SLEEP)

# Test with SLEEP(10)
time curl -s -b /tmp/cookies.txt \
 …

OpenSTAManager is an open source management software for technical assistance and invoicing. OpenSTAManager v2.9.8 and earlier contain a critical Time-Based Blind SQL Injection vulnerability in the article pricing completion handler. The application fails to properly sanitize the idarticolo parameter before using it in SQL queries, allowing attackers to inject arbitrary SQL commands and extract sensitive data through time-based Boolean inference.

OpenSTAManager is an open source management software for technical assistance and invoicing. OpenSTAManager v2.9.8 and earlier contain a critical Time-Based Blind SQL Injection vulnerability in the article pricing completion handler. The application fails to properly sanitize the idarticolo parameter before using it in SQL queries, allowing attackers to inject arbitrary SQL commands and extract sensitive data through time-based Boolean inference.

Summary

Critical Time-Based Blind SQL Injection vulnerability in the article pricing module of OpenSTAManager v2.9.8 allows authenticated attackers to extract complete database contents including user credentials, customer data, and financial records through time-based Boolean inference attacks.

Status: ✅ Confirmed and tested on live instance (v2.9.8) end demo.osmbusiness.it (v2.9.7) Vulnerable Parameter: idarticolo (GET) Affected Endpoint: /ajax_complete.php?op=getprezzi Affected Module: Articoli (Articles/Products)

Details

OpenSTAManager v2.9.8 contains a critical Time-Based Blind SQL Injection vulnerability in the article pricing completion handler. The application fails to properly sanitize the idarticolo parameter before using it in SQL queries, allowing attackers to inject arbitrary SQL commands and extract sensitive data through time-based Boolean inference.

Vulnerability Chain:

1. Entry Point: /ajax_complete.php (Line 27)

   $op = get('op');
   $result = AJAX::complete($op);
   

   The op parameter is retrieved but the vulnerability lies in other parameters.

2. Distribution: /src/AJAX.php::complete() (Line 189)

   $result = self::getCompleteResults($file, $resource);
   

3. Execution: /src/AJAX.php::getCompleteResults() (Line 402)

   require $file;
   

   Module-specific complete.php files are included.

4. Vulnerable Parameter: /modules/articoli/ajax/complete.php (Line 26)

   $idarticolo = get('idarticolo');
   

   The idarticolo parameter is retrieved from GET request.

5. Vulnerable SQL Query: /modules/articoli/ajax/complete.php (Line 70) PRIMARY VULNERABILITY

   FROM
       `dt_righe_ddt`
       INNER JOIN `dt_ddt` ON `dt_ddt`.`id` = `dt_righe_ddt`.`idddt`
       INNER JOIN `dt_tipiddt` ON `dt_tipiddt`.`id` = `dt_ddt`.`idtipoddt`
   WHERE
       `idarticolo`='.$idarticolo.' AND
       `dt_tipiddt`.`dir`="entrata" AND
       `idanagrafica`='.prepare($idanagrafica).'
   

   Impact: Direct concatenation of $idarticolo without prepare(), while $idanagrafica is properly sanitized.

Context - Full Query Structure (Lines 39-74):

The vulnerable query is part of a UNION query that fetches pricing history from invoices and delivery notes:

$documenti = $dbo->fetchArray('
    SELECT
        `iddocumento` AS id,
        "Fattura" AS tipo,
        "Fatture di vendita" AS modulo,
        (`subtotale`-`sconto`)/`qta` AS costo_unitario,
        ...
    FROM
        `co_righe_documenti`
        INNER JOIN `co_documenti` ON `co_documenti`.`id` = `co_righe_documenti`.`iddocumento`
        INNER JOIN `co_tipidocumento` ON `co_tipidocumento`.`id` = `co_documenti`.`idtipodocumento`
    WHERE
        `idarticolo`='.prepare($idarticolo).' AND ...  # ✓ PROPERLY SANITIZED (Line 54)
UNION
    SELECT
        `idddt` AS id,
        "Ddt" AS tipo,
        ...
    FROM
        `dt_righe_ddt`
        INNER JOIN `dt_ddt` ON `dt_ddt`.`id` = `dt_righe_ddt`.`idddt`
        INNER JOIN `dt_tipiddt` ON `dt_tipiddt`.`id` = `dt_ddt`.`idtipoddt`
    WHERE
        `idarticolo`='.$idarticolo.' AND   # ✗ VULNERABLE - NO prepare() (Line 70)
        `dt_tipiddt`.`dir`="entrata" AND
        `idanagrafica`='.prepare($idanagrafica).'
ORDER BY
    `id` DESC LIMIT 0,5');

Root Cause: Developer used prepare() correctly in the first SELECT (Line 54) but forgot to use it in the second SELECT of the UNION query (Line 70), creating an inconsistent security pattern.

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 (Time-Based SLEEP)

# Test with SLEEP(10)
time curl -s -b /tmp/cookies.txt \
 …