CVE-2026-65013 in Onlook
Summary
by MITRE • 07/22/2026
Onlook through 0.2.32, fixed in commit 423e2e9, contains a broken object level authorization vulnerability that allows authenticated attackers to access and manipulate other users' resources by supplying arbitrary UUID values to tRPC API procedures including project.get, member.remove, and chat.conversation.delete. Attackers can provide arbitrary projectId or conversationId values without authorization validation to read, modify, and delete other users' project data, members, and conversation history.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/22/2026
The vulnerability in onlook version 0.2.32 represents a critical broken object level authorization issue that fundamentally undermines the application's access control mechanisms. This weakness allows authenticated attackers to bypass proper authorization checks by manipulating UUID parameters within tRPC API endpoints, specifically targeting project.get, member.remove, and chat.conversation.delete procedures. The flaw stems from insufficient validation of user permissions when processing requests containing arbitrary identifiers, creating a pathway for privilege escalation and unauthorized data manipulation.
The technical implementation of this vulnerability demonstrates a classic authorization bypass where the application fails to verify whether the authenticated user has legitimate access rights to the requested resources. When attackers supply arbitrary projectId or conversationId values, the system processes these requests without proper ownership verification, enabling them to access, modify, or delete resources belonging to other users. This represents a direct violation of the principle of least privilege and demonstrates inadequate input validation combined with improper access control enforcement.
From an operational impact perspective, this vulnerability creates significant risks for user data integrity and confidentiality. Attackers can not only read sensitive project information and conversation history but also modify or completely remove these resources, potentially leading to data loss, privacy violations, and service disruption. The scope of potential damage extends beyond individual user accounts to encompass entire project repositories and communication channels, making this a particularly dangerous vulnerability in collaborative environments.
The security implications align with CWE-285, which addresses improper authorization in software systems, and corresponds to ATT&CK technique T1078 for valid accounts usage and T1566 for credential access through manipulation of application interfaces. The vulnerability's exploitation requires minimal technical skill beyond understanding the API structure and demonstrates how seemingly minor authorization gaps can create substantial security risks. Organizations using affected versions should immediately implement mitigations including proper access control validation, input sanitization, and comprehensive authorization checks before the fix in commit 423e2e9 is applied.
Mitigation strategies should focus on implementing robust parameter validation that verifies user ownership before processing any resource requests, establishing proper role-based access controls, and conducting thorough security testing of all API endpoints. The fix in commit 423e2e9 likely addresses the core authorization logic by ensuring that UUID parameters are validated against the authenticated user's permissions, preventing the bypass of normal access control mechanisms that would otherwise allow arbitrary resource manipulation.