CVE-2026-77442 in Ryot
Summary
by MITRE • 11/06/2026
Ryot is a self-hosted personal tracking application. Prior to 10.4.0, the createOrUpdateUserIntegration GraphQL mutation in crates/services/user/src/integration_operations.rs allows a low-privileged authenticated user to supply another user's integrationId to create_or_update_user_integration() without an ownership check. SeaORM treats the supplied primary key as an update target, and the operation assigns the caller's user_id while replacing the targeted integration's provider_specifics and other configuration, which can transfer ownership, overwrite configuration, or disable the victim's integration. Exploitation requires obtaining the victim's non-brute-forceable integration id, and the vulnerable update does not disclose existing stored credential values. This issue is fixed in version 10.4.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/06/2026
The vulnerability identified in Ryot versions prior to 10.4.0 represents a critical Insecure Direct Object Reference (IDOR) flaw within its GraphQL API layer, specifically affecting the createOrUpdateUserIntegration mutation. As a self-hosted personal tracking application, Ryot relies on user integrations to connect with external services for data synchronization and monitoring. The core technical failure lies in the backend implementation located at crates/services/user/src/integration_operations.rs, where the logic governing integration updates fails to perform an adequate ownership verification check against the provided primary key. When a low-privileged authenticated user submits a request containing another user's integrationId, the underlying database abstraction layer, SeaORM, interprets this identifier as a valid target for update operations without validating that the requesting user holds administrative or ownership rights over that specific resource.
This architectural oversight allows an attacker to manipulate the state of integrations belonging to other users within the same instance. Upon exploitation, the system assigns the caller's user_id to the targeted integration record while simultaneously overwriting critical configuration fields such as provider_specifics and other authentication parameters. This mechanism effectively transfers ownership of the victim's external service connection to the attacker or allows the attacker to corrupt the configuration entirely. The operational impact is severe, potentially leading to the disabling of the victim's integrations, which disrupts their data tracking workflows, or more dangerously, enabling the attacker to hijack the integration context if subsequent logic relies on the user_id associated with the integration for authorization decisions in other parts of the application.
From a threat modeling perspective, this vulnerability aligns closely with CWE-639: Authorization Bypass Through User-Controlled Key and is categorized under MITRE ATT&CK technique T1078: Valid Accounts, as it exploits legitimate credentials to perform unauthorized actions on resources belonging to other users. The exploitation vector requires the attacker to obtain a valid integrationId for a target user. While these identifiers are described as non-brute-forceable due to their complexity or randomness, they may be exposed through various side channels such as API responses during normal usage, shared links, or database dumps if the instance is compromised further. Notably, the vulnerability does not allow direct extraction of stored credentials because the update operation overwrites provider_specifics rather than returning them, which limits immediate credential theft but significantly increases the risk of account takeover and service disruption through configuration manipulation.
Mitigation for this issue involves upgrading to Ryot version 10.4.0 or later, where the developers have implemented proper ownership checks within the integration operations logic. For environments that cannot immediately upgrade, administrators should review access controls on GraphQL endpoints and ensure that API requests are strictly validated against user-resource relationships before processing mutations. Implementing strict object-level authorization checks in all data modification paths is essential to prevent similar IDOR vulnerabilities across other modules of the application.