CVE-2026-66091 in openEQUELLA
Summary
by MITRE • 10/29/2026
In openEQUELLA before 2026.1, the GET /api/userquery/userinfobackup endpoint performs no authentication or authorisation check. An unauthenticated attacker who supplies another user's uniqueId can retrieve that user's stored personal details (username, first name, last name and email address) within the same institution.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in openEQUELLA versions prior to 2026.1 represents a critical failure in access control mechanisms, specifically affecting the GET /api/userquery/userinfobackup endpoint. This flaw allows for unauthorized data retrieval by bypassing standard authentication and authorization protocols that are typically required for sensitive user operations. The core technical issue lies in the absence of any security checks when processing requests to this specific API path. Consequently, the system fails to verify whether the requesting entity has the legitimate right to access the information being requested, treating all incoming GET requests with equal trust regardless of their origin or intent.
From a technical perspective, the exploitation vector is straightforward and does not require complex payload construction or privilege escalation techniques beyond knowing valid identifiers. An unauthenticated attacker can interact directly with the endpoint by supplying another user's uniqueId parameter within the request body or query string. The application logic then proceeds to fetch and return the associated personal details without validating if the requester is that specific user, an administrator, or any other authorized role. This behavior indicates a lack of object-level access control checks, where the system does not enforce ownership boundaries on the data resources being accessed.
The operational impact of this vulnerability centers on the exposure of personally identifiable information (PII). Successful exploitation results in the disclosure of usernames, first names, last names, and email addresses for any user within the same institution whose uniqueId is known or guessable. While these fields may not contain highly sensitive financial data, they constitute significant privacy violations under regulations such as GDPR and HIPAA depending on the jurisdiction and context. The exposure facilitates further malicious activities including social engineering attacks, phishing campaigns, and credential stuffing attempts by providing attackers with accurate contact information to target specific individuals within an organization.
This vulnerability aligns closely with CWE-284 Improper Access Control, specifically reflecting a failure in authorization checks for sensitive data access. It also maps directly to the MITRE ATT&CK framework technique T1078 Valid Accounts, as it involves leveraging valid user identifiers to gain unauthorized access to information, although in this case no actual account credentials are needed due to the lack of authentication requirements on the endpoint itself. The scenario exemplifies a Broken Object Level Authorization (BOLA) pattern where API endpoints do not properly validate that the authenticated or unauthenticated actor is permitted to perform actions on specific objects identified by their unique identifiers.
Mitigation strategies must prioritize immediate patching to version 2026.1 or later, which addresses this security gap through corrected access control logic. In environments where upgrading is not immediately feasible, network-level controls such as Web Application Firewalls (WAF) can be configured to restrict access to the /api/userquery/ path based on IP reputation or known malicious patterns, though this is a less robust defense than fixing the root cause. Developers should implement strict authentication and authorization checks for all API endpoints, ensuring that every request verifies both user identity and permission levels before processing data retrieval operations. Additionally, implementing rate limiting can help mitigate automated scanning attempts by attackers seeking to enumerate valid uniqueIds across the institution's user base.