CVE-2026-117606 in NexoPOS
Summary
by MITRE • 10/28/2026
NexoPOS through 6.3.0 contains a missing authorization vulnerability that allows authenticated cashiers to manipulate other cashiers' register sessions because CashRegistersService never compares used_by with the user. Attackers holding the default nexopos.use.registers permission can submit closing, cash-in, or cash-out actions to POST /api/cash-registers/{action}/{register} to force-close sessions or alter balances.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified in NexoPOS versions through 6.3.0 represents a critical failure in access control mechanisms, specifically categorized under CWE-285 Improper Authorization. This flaw stems from the CashRegistersService component failing to validate that the authenticated user initiating an action is the same entity associated with the specific register session being manipulated. In typical point-of-sale architectures, each cashier operates within an isolated context tied to their unique identifier and active session state. However, in this implementation, the service logic does not enforce a strict binding between the current requestor's identity and the target resource's ownership metadata. Consequently, any authenticated user possessing the nexopos.use.registers permission can bypass these logical controls by directly interacting with the API endpoints designed for register management actions such as closing sessions or adjusting cash balances.
The operational impact of this vulnerability is severe due to its potential for financial fraud and data integrity compromise. An attacker who has obtained valid credentials, which may be achieved through phishing, credential stuffing, or other initial access vectors, can exploit this flaw by submitting POST requests to the /api/cash-registers/{action}/{register} endpoint. By specifying actions such as closing a register session prematurely or manipulating cash-in and cash-out values for registers they do not own, an attacker can disrupt daily reconciliation processes, alter financial records, and potentially embezzle funds without detection through standard audit logs that might only record the action rather than verifying its legitimacy against user ownership. This lack of authorization checks allows for unauthorized modification of critical business data, undermining trust in the system's accounting capabilities and exposing organizations to significant regulatory and reputational risks associated with inaccurate financial reporting.
From a threat modeling perspective aligned with MITRE ATT&CK frameworks, this vulnerability facilitates techniques related to Account Manipulation and Data Injection or Modification. The attacker leverages valid credentials to perform unauthorized actions on shared resources, effectively abusing the principle of least privilege by exploiting overly broad permissions like nexopos.use.registers which grant access beyond what is necessary for a cashier's specific duties. This scenario highlights the danger of relying solely on role-based access control without implementing object-level security checks that verify resource ownership before executing state-changing operations. The ability to force-close sessions or alter balances remotely means an attacker can create discrepancies in daily sales reports, making it difficult for management to detect theft or errors during routine audits unless deep forensic analysis is conducted.
To mitigate this vulnerability, developers must implement strict object-level authorization checks within the CashRegistersService logic. This involves ensuring that every API request handling register actions verifies that the authenticated user's identifier matches the used_by field associated with the target register session before proceeding with any state changes such as closing a session or adjusting cash balances. Additionally, organizations should review their permission structures to ensure that roles like cashier do not possess overly broad permissions unless absolutely necessary for operational requirements. Implementing comprehensive audit logging that records both the action taken and the verification of user-resource ownership can aid in detecting attempts at exploitation. Regular security code reviews focusing on access control logic are essential to prevent similar flaws, alongside deploying web application firewalls configured to detect anomalous patterns in API usage that may indicate automated exploitation attempts against these endpoints.