Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain room code and join relay room
-
DeliveryRead paired peer identifiers from announcements
-
ExploitForge RelayMessage From field
-
ExecutionImpersonate paired device
-
ImpactAccess protected sync routes (saves, snapshots, files)
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Anti-spoofing controls
MITRE ATT&CK
1 technique across 1 tactic: Defense Evasion The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the attacker to already possess a valid OpenSave room code and to join that room as an unpaired member over the WAN relay; the vulnerable path is the WAN relay RelayMessage handling (internal/p2p/wanclient_handlers.go) which does not validate sender identity, letting the attacker spoof the From field to impersonate an already-paired device and reach protected sync routes. Limiting factors: the room code is a 12-character cryptographically generated value that is not guessable and must be shared out-of-band, so realistic attackers are limited to people who were deliberately given (or who leak) a room code - not the open internet. Both endpoints must be on a version before 2.4.0-beta.1; the fix adds end-to-end encryption plus single-use per-request proof that the sender holds the key pinned at pairing, and requires re-pairing over the relay to take effect. |
| Impact | This is a genuine but bounded authentication-bypass (CWE-290, spoofing) flaw in OpenSave's WAN relay. The vendor/VulnCheck CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) with VC:L/VI:L/VA:L yields 6.3 (medium), and the metrics are internally consistent with the description: exploitation is remote and technically simple, but the AT:P (Attack Requirement present) correctly captures that the attacker must first be inside the room. The PR:N is defensible because the app performs no per-request authentication of the sender - that is precisely the defect - but the practical gate is possession of the room code, which the description states is 12 characters from a cryptographic generator and therefore not guessable. No EPSS score, KEV listing, or SSVC decision data was provided; there is no CISA KEV entry, so this is not confirmed active exploitation. A public gist by the reporter is referenced and may contain proof-of-concept material, but the input does not flag it as a working exploit, so exploitation status should be treated as unconfirmed. Net: a real, credible weakness worth patching for OpenSave users, but the low real-world deployment footprint and the room-code precondition make this a low-to-medium operational priority rather than an urgent widespread threat. The triple-Low impact (VC/VI/VA:L) means no single high-consequence outcome. |
| Exploit ScenarioDerived | A user shares an OpenSave room code with someone (or it leaks). That person joins the WAN relay room as an unpaired member, watches the room announcements to learn a legitimately paired device's identifier, then sends a RelayMessage with the From field spoofed to that identifier - impersonating the paired peer and gaining access to protected sync routes such as save data, snapshots, and file operations. A gist referenced in the advisory may provide proof-of-concept steps, but active exploitation is not confirmed. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 30, 2026
Authentication bypass in Liquid-co OpenSave's WAN relay lets an unpaired room member impersonate a paired device and reach protected sync routes for save data, snapshots, and file operations. Any OpenSave instance running a version before 2.4.0-beta.1 with WAN relay sync enabled is affected; the attacker must already hold a valid 12-character room code, which is cryptographically generated and shared out-of-band, so exposure is realistically limited to people the room owner deliberately invited or whose code leaked, rather than the open internet. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the issue is resolved by the vendor's 2.4.0-beta.1 release, which adds end-to-end encryption over the relay plus single-use per-request proof of the pairing key.
RemediationAI
Upgrade both ends of every pairing to the vendor-fixed release: Vendor-released patch: 2.4.0-beta.1, delivered via the commit https://github.com/Liquid-co/OpenSave/commit/2f2612b13233ac123e01a03cb3008c44bacaeae3 and described in the project changelog and https://github.com/Liquid-co/OpenSave. Version skew matters: the protections latch on only after both peers run the fixed build, and because encryption over a relay depends on key material that older pairings transmitted and discarded, existing internet pairings must be unpaired and re-paired over the relay after upgrading - otherwise they continue syncing under the old, spoofable check. If upgrading immediately is not possible, the most effective compensating control is to stop using the WAN relay: set games to sync only over the local network/direct connection, or disable hosted and joined WAN relays in the app, which removes the relayed request path the spoofing depends on at the cost of losing off-site sync entirely. As a second control, treat the room code as a secret with the same sensitivity as a password - do not post it in shared channels, screenshots, or support threads, and rotate it (leave and recreate the room) if it may have leaked - understanding that this only narrows the attacker set rather than closing the bypass, since anyone who has the code can still forge the From field on pre-fix builds. Hosting your own relay does not mitigate this issue, because the missing sender-identity validation is in the client's relay handler, not the relay server, so a self-hosted relay is equally exploitable by any room member until the 2.4.0-beta.1 client update is applied. No vendor-published interim configuration flag or authentication option for the pre-fix relay handler was identified in the available data.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is CWE-290 (Authentication Bypass by Spoofing) in OpenSave's peer-to-peer WAN relay path. In the affected code (internal/p2p/wanclient_handlers.go, lines 268-282 in v2.3.1), relayed RelayMessage requests were accepted without validating that the sender identity in the From field actually belongs to a paired device. Because room membership and peer identifiers are broadcast in relay announcements, any client that joins the room can read the identifiers of paired peers, set From to one of them, and have the relayed request treated as originating from a trusted endpoint - reaching sync handlers for save data, snapshots, and file operations. The project's own changelog confirms this design gap: prior to the fix, traffic to the relay was TLS-encrypted on the wire but not end-to-end encrypted between devices, and pairing over a relay transmitted a key that was subsequently discarded, so there was no key material available to authenticate relayed requests. The 2.4.0-beta.1 change replaces address-based and trust-by-announcement identification with per-request proof that the sender holds the key pinned at pairing, bound to the route, method and contents, and made single-use so a captured request cannot be replayed or re-aimed; it also adds end-to-end encryption so the relay forwards data it cannot read. The same release hardened update verification with SHA256SUMS checks and switched local-network peer identification from source address to cryptographic proof.
Know when Opensave gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N
Remote and no per-request auth (PR:N), but the attacker must know the shared cryptographic room code and enumerate a paired peer identifier, so AC:H; impact is limited to Low across C/I/A.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
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.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
EUVD-2026-89992
GHSA-m7pc-whc6-fxc7
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB