Open Source Point of Sale (opensourcepos) is a web based point of sale application written in PHP using CodeIgniter framework. Prior to version 3.4.2, an Insecure Direct Object Reference (IDOR) vulnerability allows an authenticated low-privileged user to access the password change functionality of other users, including administrators, by manipulating the `employee_id` parameter. The application does not verify object ownership or enforce authorization checks. Version 3.4.2 adds object-level authorization checks to validate that the current user owns the employee_id being accessed.
OpenSourcePOS 3.4.1 has a second order SQL Injection vulnerability in the handling of the currency_symbol configuration field. Although the input is initially stored without immediate execution, it is later concatenated into a dynamically constructed SQL query without proper sanitization or parameter binding. This allows an attacker with access to modify the currency_symbol value to inject arbitrary SQL expressions, which are executed when the affected query is subsequently processed.
OpenSourcePOS 3.4.1 contains a Local File Inclusion (LFI) vulnerability in the Sales.php::getInvoice() function. An attacker can read arbitrary files on the web server by manipulating the Invoice Type configuration. This issue can be chained with the file upload functionality to achieve Remote Code Execution (RCE).
A cross-site scripting (XSS) vulnerability in the item management and sales invoice function of OpenSourcePOS v3.4.1 allows attackers to execute arbitrary web scripts or HTML via injecting a crafted payload.
A cross-site scripting (XSS) vulnerability in the Customers function of OpenSourcePOS v3.4.1 allows attackers to execute arbitrary web scripts or HTML via injecting a crafted payload into the Phone Number parameter.
A cross-site scripting (XSS) vulnerability in the Generate Item Barcode function of OpenSourcePOS v3.4.1 allows attackers to execute arbitrary web scripts or HTML via injecting a crafted payload into the Item Category parameter.
A cross-site scripting (XSS) vulnerability in the Item Kits function of OpenSourcePOS v3.4.1 allows attackers to execute arbitrary web scripts or HTML via injecting a crafted payload into the Item Name parameter.
Open Source Point of Sale (opensourcepos) is a web based point of sale application written in PHP using CodeIgniter framework. opensourcepos 3.4.0 and 3.4.1 has a stored XSS vulnerability exists in the Configuration (Information) functionality. An authenticated user with the permission “Configuration: Change OSPOS's Configuration” can inject a malicious JavaScript payload into the Company Name field when updating Information in Configuration. The malicious payload is stored and later triggered when a user accesses /sales/complete. First select Sales, and choose New Item to create an item, then click on Completed . Due to insufficient input validation and output encoding, the payload is rendered and executed in the user’s browser, resulting in a stored XSS vulnerability. This vulnerability is fixed in 3.4.2.
Open Source Point of Sale (opensourcepos) is a web based point of sale application written in PHP using CodeIgniter framework. Starting in version 3.4.0 and prior to version 3.4.2, a Cross-Site Request Forgery (CSRF) vulnerability exists in the application's filter configuration. The CSRF protection mechanism was **explicitly disabled**, allowing the application to process state-changing requests (POST) without verifying a valid CSRF token. An unauthenticated remote attacker can exploit this by hosting a malicious web page. If a logged-in administrator visits this page, their browser is forced to send unauthorized requests to the application. A successful exploit allows the attacker to silently create a new Administrator account with full privileges, leading to a complete takeover of the system and loss of confidentiality, integrity, and availability. The vulnerability has been patched in version 3.4.2. The fix re-enables the CSRF filter in `app/Config/Filters.php` and resolves associated AJAX race conditions by adjusting token regeneration settings. As a workaround, administrators can manually re-enable the CSRF filter in `app/Config/Filters.php` by uncommenting the protection line. However, this is not recommended without applying the full patch, as it may cause functionality breakage in the Sales module due to token synchronization issues.