Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
An HTML Injection vulnerability exists in the user group creation functionality that allows an attacker to inject arbitrary HTML content into the application interface. The vulnerability occurs when user-supplied input in the group name field is not properly sanitized before being rendered, allowing an attacker to inject HTML elements such as anchor tags. This may enable phishing attacks or unintended redirection when other users interact with the injected content. Details The vulnerable code responsible for rendering this content is located in: modules/utenti/edit.php PoC A malicious user can inject HTML content into the Name field when creating a new user group. <img width="1233" height="293" alt="image" src="https://github.com/user-attachments/assets/cc09d0d5-ec77-4e94-94f7-35a277c49130" / After selecting the group, the application renders the injected HTML without proper sanitization. As a result, the anchor tag is displayed as an active link in the interface. <img…
Recommended action: Upgrade to 2.11-beta (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Six confrontarighe.php files across different modules in OpenSTAManager <= 2.10.1 contain an SQL Injection vulnerability. The righe parameter received via $GET['righe'] is directly concatenated into an SQL query without any sanitization, parameterization or validation. An authenticated attacker can inject arbitrary SQL statements to extract sensitive data from the database, including user credentials, customer information, invoice data and any other stored data. Affected Files All 6 vulnerable files share the same code pattern: | | File | Line | Affected Table | |---|------|------|----------------| | 1 | modules/fatture/modals/confrontarighe.php | 29 | corighedocumenti | | 2 | modules/interventi/modals/confrontarighe.php | 29 | inrigheinterventi | | 3 | modules/preventivi/modals/confrontarighe.php | 28 | corighepreventivi | | 4 | modules/ordini/modals/confrontarighe.php | 29 | orrigheordini | | 5 | modules/ddt/modals/confrontarighe.php | 29 | dtrigheddt | | 6 |…
Recommended action: Upgrade to 2.10.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Aggiornamenti (Updates) module in OpenSTAManager <= 2.10.1 contains a database conflict resolution feature (op=risolvi-conflitti-database) that accepts a JSON array of SQL statements via POST and executes them directly against the database without any validation, allowlist, or sanitization. An authenticated attacker with access to the Aggiornamenti module can execute arbitrary SQL statements including CREATE, DROP, ALTER, INSERT, UPDATE, DELETE, SELECT INTO OUTFILE, and any other SQL command supported by the MySQL server. Foreign key checks are explicitly disabled before execution (SET FOREIGNKEYCHECKS=0), further reducing database integrity protections. Affected Code File: modules/aggiornamenti/actions.php, lines 40-82 Key Issues 1. No query validation: The SQL statements from user input are executed directly via $dbo-query() without any validation or filtering. 2. No allowlist: There is no restriction on which SQL commands are permitted (e.g., only ALTER TABLE or…
Recommended action: Upgrade to 2.10.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The oauth2.php file in OpenSTAManager is an unauthenticated endpoint ($skippermissions = true). It loads a record from the zzoauth2 table using the attacker-controlled GET parameter state, and during the OAuth2 configuration flow calls unserialize() on the accesstoken field without any class restriction. An attacker who can write to the zzoauth2 table (e.g., via the arbitrary SQL injection in the Aggiornamenti module reported in GHSA-2fr7-cc4f-wh98) can insert a malicious serialized PHP object (gadget chain) that upon deserialization executes arbitrary commands on the server as the www-data user. Affected code Entry point — oauth2.php Deserialization — src/Models/OAuth2.php unserialize() is called without the allowedclasses parameter, allowing instantiation of any class loaded by the Composer autoloader. Execution flow The HTTP response is 500 (due to the hasExpired() error), but the command has already executed via destruct() during error cleanup. Full attack chain This…
Recommended action: Upgrade to 2.10.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Multiple AJAX select handlers in OpenSTAManager <= 2.10.1 are vulnerable to Time-Based Blind SQL Injection through the options[stato] GET parameter. The user-supplied value is read from $superselect['stato'] and concatenated directly into SQL WHERE clauses as a bare expression, without any sanitization, parameterization, or allowlist validation. An authenticated attacker can inject arbitrary SQL statements to extract sensitive data from the database, including usernames, password hashes, financial records, and any other information stored in the MySQL database. Affected Endpoints Three modules share the same vulnerability pattern: 1. Preventivi (Quotes) - Primary - Endpoint: GET /ajaxselect.php?op=preventivi - File: modules/preventivi/ajax/select.php, line 60 - Required parameters: options[idanagrafica] (any valid ID) Vulnerable code: The $stato variable is inserted as a bare expression inside parentheses. The resulting SQL fragment becomes ({userinput} = 1), allowing an…
Recommended action: Upgrade to 2.10.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Multiple Reflected Cross-Site Scripting (XSS) vulnerabilities in OpenSTAManager v2.9.8 allow unauthenticated attackers to execute arbitrary JavaScript code in the context of other users' browsers through crafted URL parameters, potentially leading to session hijacking, credential theft, and unauthorized actions. Vulnerable Parameter: righe (GET) Details OpenSTAManager v2.9.8 contains multiple Reflected XSS vulnerabilities in invoice/order/contract modification modals. The application fails to properly sanitize user-supplied input from the righe GET parameter before reflecting it in HTML output. Vulnerable Code Location: File: /modules/contratti/modals/modificaiva.php (Line 125) The $GET['righe'] parameter is directly echoed into the HTML value attribute without any sanitization using htmlspecialchars() or equivalent functions. This allows an attacker to break out of the attribute context and inject arbitrary HTML/JavaScript. All Affected Files: 1.…
Recommended action: Upgrade to 2.9.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An authenticated SQL Injection vulnerability in the API allows any user, regardless of permission level, to execute arbitrary SQL queries. By manipulating the display parameter in an API request, an attacker can exfiltrate, modify, or delete any data in the database, leading to a full system compromise. Details The vulnerability is located in the retrieve() method within src/API/Manager.php. User input from the display GET parameter is processed without proper validation. The code strips the surrounding brackets [], splits the string by commas, and then passes each resulting element directly into the selectRaw() function of the query builder. Since selectRaw() is designed to execute raw SQL expressions, it executes any malicious SQL code provided in the display parameter. PoC 1. Log in to an OpenSTAManager instance as any user. 2. Navigate to the user's profile page to obtain their personal API Token. 3. Use this API token to send a specially crafted GET request to the API…
Recommended action: Upgrade to 2.9.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.