CVE-2026-111637 in NexoPOS
Summary
by MITRE • 10/16/2026
NexoPOS through 6.2.4 contains a missing authentication vulnerability that allows unauthenticated attackers to read accounting transaction records via GET /api/fields/{resource}/{identifier}. Attackers can request transaction field classes like ns.entity-transaction with sequential ids to retrieve names, values, account ids, and descriptions without nexopos.read.transactions permission.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in NexoPOS versions through 6.2.4 represents a critical failure in access control mechanisms, specifically categorized under CWE-306 as Missing Authentication for Critical Function. This flaw allows unauthenticated actors to bypass the application's intended security model by directly accessing sensitive accounting data through an API endpoint that lacks proper authentication checks. The specific vector involves the GET /api/fields/{resource}/{identifier} route, which is designed to retrieve field definitions or values but fails to verify whether the requesting user possesses the necessary permissions, such as nexopos.read.transactions, before returning data. This architectural oversight effectively turns a standard API endpoint into an information disclosure channel for sensitive financial records.
From a technical perspective, the exploitation of this vulnerability relies on sequential identifier enumeration. An attacker can craft HTTP GET requests to the affected endpoint with varying integer values in the {identifier} parameter while specifying resource types like ns.entity-transaction. Because the server does not validate the session or token associated with these requests against user roles, it proceeds to query the database and return the requested transaction details. The data exposed includes highly sensitive information such as transaction names, monetary values, account identifiers, and descriptive notes. This level of detail provides a comprehensive view of the organization's financial activities, including customer payments, vendor expenses, and internal fund transfers, which are typically restricted to authorized accounting personnel or administrators.
The operational impact of this vulnerability is severe for any business relying on NexoPOS for its point-of-sale and back-office operations. The unauthorized access to transaction records compromises both confidentiality and integrity principles within the CIA triad. Confidentiality is breached as sensitive financial data becomes accessible to external parties who may use it for competitive intelligence, fraud planning, or social engineering attacks against employees and customers. Integrity concerns arise if attackers can infer patterns in transaction processing that might facilitate future manipulation of accounts or detection of security monitoring gaps. Furthermore, the exposure of account IDs and descriptions could aid in more targeted phishing campaigns aimed at specific staff members who manage those accounts, thereby escalating the risk from simple data theft to potential system compromise.
In terms of threat modeling, this vulnerability aligns with ATT&CK technique T1078, Valid Accounts, although it is exploited without valid credentials due to the missing authentication check, which also relates to T1539 Steal Web Session Cookie if session tokens were inadvertently exposed during enumeration attempts. The ability to read transaction records falls under data exfiltration techniques where an attacker gathers intelligence on financial flows. For organizations running affected versions of NexoPOS, immediate mitigation is required. This includes upgrading to a patched version that enforces strict authentication and authorization checks on all API endpoints. Additionally, until the upgrade can be performed, implementing web application firewall rules to block direct access to the /api/fields endpoint from unauthenticated sources or restricting IP access to administrative interfaces can provide temporary relief. Regular security audits focusing on API endpoint permissions are recommended to prevent similar misconfigurations in other parts of the application stack.