GHSA-xcw4-53cc-hv32: Critical severity pip/mnemosyne-memory vulnerability
Summary
The Mnemosyne sync server's authentication check decoded JWT bearer tokens but never verified their HMAC-SHA256 signatures. Any well-formed token was accepted, allowing an unauthenticated attacker to impersonate any user and read or modify their sync data.
Severity: Critical
CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N = 9.1
Assumes the sync server endpoint is network-reachable. If your deployment is localhost-only, the score drops substantially and severity becomes High or Medium depending on local exposure. Confirm your threat model.
Affected versions
All mnemosyne versions exposing the sync server endpoint, up to and including v3.10.0.
Patched versions
v3.10.1 (commit a0b6b871 on branch security/jwt-signature-verification)
Description
The sync server uses JWT bearer tokens to authenticate clients. Prior to v3.10.1, the auth check in mnemosyne/core/syncserver.py parsed the JWT's header and payload using base64 decoding, then passed the token to a jwt library call with options that effectively disabled signature verification. The server accepted any well-formed token regardless of the signature, including tokens with alg: none and tokens signed with the wrong key.
The fix in v3.10.1 replaces the broken decode with a from-scratch HS256 verifier using only the Python standard library:
- Constant-time signature comparison via hmac.comparedigest - Strict alg: HS256 check, rejecting none and other algorithms - UTC-aware exp validation with leeway - Loud errors with specific failure reasons - Type validation of decoded payload before use
Impact
An attacker with network access to the sync server can:
- Forge a JWT for any userid without knowing the secret - Authenticate as that user to /sync/status, /sync/push, and /sync/pull - Read the victim's sync state - Push malicious sync state to corrupt the victim's local database - Pivot within a shared deployment (multi-user sync server)
Confidentiality and integrity of sync data are fully compromised for the duration of exposure. There is no impact on the server's availability.
Reproduction
python import base64 import json import requests
Forge a JWT for any user. No secret required. def forgejwt(userid): header = base64.urlsafeb64encode( json.dumps({"alg": "HS256", "typ": "JWT"}).encode() ).rstrip(b"=") payload = base64.urlsafeb64encode( json.dumps({"userid": userid, "exp": 9999999999}).encode() ).rstrip(b"=") sig = b"" return f"{header.decode()}.{payload.decode()}."
r = requests.get( "https://target.example.com/sync/status", headers={"Authorization": f"Bearer {forgejwt('victim-user-id')}"}, ) print(r.statuscode, r.json())
A 200 OK response with valid sync status payload confirms the bypass. The attack requires no credentials, no secret, and no prior access.
Mitigation
Upgrade to v3.10.1.
For users who cannot upgrade immediately:
- Restrict network access to the sync server endpoint to trusted clients only. Firewall, reverse proxy with mTLS, or localhost bind with SSH tunnel are all viable. - The vulnerability is not exploitable against an unreachable endpoint.
Workarounds
None. The patch is required to restore authentication integrity.
Credits
- Reporter: Denis Hache (dplush). Reported via private channel on 2026-06-13 with full reproduction and a coordinated disclosure window. - Fix: Denis Hache
Timeline - 2026-06-13: Initial report received from Denis via private channel.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/mnemosyne-memoryto a version that resolves this vulnerability.Fixed in 3.10.1 - Upgrade
Upgrade
mnemosyneto a version that resolves this vulnerability.Fixed in v3.10.1 - Compensating control
Restrict network access to the mnemosyne sync server endpoint to trusted clients only (e.g., via firewall, reverse proxy with mTLS, or localhost bind with an SSH tunnel), since the issue is exploitable when the endpoint is network-reachable.
Event History
Frequently Asked Questions
Which deployments are most exposed?
Any Mnemosyne version through 3.10.0 that exposes its sync server endpoint is affected. Network-reachable sync endpoints face the highest risk; localhost-only deployments have substantially lower exposure, depending on who can access the local host.
What does an attacker need to exploit this issue?
An attacker does not need valid credentials or user interaction. They need to reach the sync server endpoint and submit a well-formed JWT bearer token, whose signature can be invalid, omitted with alg: none, or signed with an attacker-controlled key.
What could an attacker do after exploiting it?
An attacker can impersonate any user and read or modify that user's sync data. The described impact includes loss of confidentiality and integrity, but not availability.
How can this be remediated?
Upgrade to Mnemosyne 3.10.1, which verifies JWT HMAC-SHA256 signatures. Versions up to and including 3.10.0 should be treated as affected when the sync server is exposed.
What can be done if upgrading is not immediately possible?
Restrict access to the sync server so it is not network-reachable, such as limiting it to localhost or otherwise preventing untrusted clients from reaching the endpoint. This reduces exposure but does not correct the missing signature verification.