CVE-2026-103397 in OpenSave
Summary
by MITRE • 09/30/2026
OpenSave before 2.4.0-beta.1 fails to validate sender identity in WAN relay requests, allowing unpaired room members to impersonate paired devices by spoofing the RelayMessage From field. Attackers who know the room code can join, read paired peer identifiers from announcements, and send forged requests to access protected sync routes including save data, snapshots, and file operations.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability identified in OpenSave versions prior to 2.4.0-beta.1 represents a critical failure in identity validation within the Wide Area Network relay mechanism. This flaw stems from an insufficient verification of sender authenticity when processing RelayMessage requests. Specifically, the application fails to validate that the entity initiating a request is indeed the legitimate owner or authorized participant associated with the claimed device identifier. By neglecting to enforce strict authentication checks on the From field of incoming messages, the software allows any client connected to the relay server to spoof the identity of paired devices. This architectural oversight effectively bypasses access controls designed to protect sensitive user data and operational states within shared rooms.
An attacker who possesses knowledge of a specific room code can exploit this weakness by joining the corresponding session as an unpaired member. Once inside, the attacker leverages public announcement mechanisms inherent to the protocol to harvest identifiers associated with paired peers. These identifiers serve as credentials for impersonation in subsequent interactions. With these stolen identifiers, the adversary constructs forged RelayMessage requests that falsely attribute actions to legitimate devices. Because the server does not cryptographically verify the sender's identity against a trusted source or validate session tokens properly, it accepts these spoofed messages as authentic and executes them accordingly.
The operational impact of this vulnerability is severe, granting unauthorized actors access to protected synchronization routes. These routes encompass critical data operations such as saving user state, retrieving application snapshots, and performing file system manipulations. Consequently, an attacker can read confidential save data, potentially leading to privacy breaches or intellectual property theft. Furthermore, the ability to execute file operations introduces risks of data corruption, deletion, or injection of malicious content into shared environments. This level of access undermines the integrity and confidentiality guarantees expected in collaborative software applications, allowing for both passive eavesdropping on sensitive information and active modification of user assets without detection by standard security mechanisms.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication, as the system fails to adequately verify the identity of users or services attempting to access resources. It also relates to CWE-345 Insufficient Verification of Data Authenticity, given that the application accepts data from untrusted sources without proper validation. In terms of offensive security frameworks, this exploit maps to ATT&CK technique T1078 Valid Accounts, where attackers use legitimate credentials or identifiers obtained through reconnaissance to gain unauthorized access. Additionally, it reflects aspects of T1530 Data from Information Repositories if the attacker exfiltrates saved data, and T1499 Endpoint Denial of Service if file operations are used destructively.
Mitigation strategies must prioritize robust identity verification within the relay protocol. Developers should implement mutual authentication mechanisms where every RelayMessage is signed using asymmetric cryptography or accompanied by a secure session token that ties the message to an authenticated user context rather than just a device identifier. It is essential to validate that the sender of any request holds explicit permission for the requested action, ensuring that unpaired members cannot interact with protected resources regardless of whether they possess peer identifiers. Regular security audits and penetration testing focused on identity spoofing scenarios will help identify similar weaknesses in distributed systems before deployment.