Sep 19, 2026·7 min read·5 visits
An authentication bypass vulnerability in the Mnemosyne sync server allows remote attackers to spoof JWTs and gain full unauthorized access by omitting signature verification.
CVE-2026-59163 is a critical authentication bypass vulnerability in the Mnemosyne sync server. In versions prior to v3.10.1, the server's authentication logic decoded incoming JSON Web Tokens (JWT) but completely skipped cryptographic signature verification. An unauthenticated remote attacker can exploit this vulnerability to bypass authentication, impersonate arbitrary users, read synchronized AI agent states, or write malicious database updates.
The Mnemosyne project provides a zero-cloud SQLite-backed memory layer tailored for artificial intelligence agents. It allows AI systems to maintain local and persistent state across execution sessions. To facilitate state coordination across multiple distributed nodes, Mnemosyne includes a dedicated synchronization server component (mnemosyne/core/sync_server.py). This sync server exposes HTTP endpoints for pushing and pulling database updates.
To secure the sync endpoints, the server implements token-based authentication. In configurations utilizing JSON Web Tokens (JWT), clients present a cryptographic token containing identity claims and expiration constraints. The server must validate the authenticity of these claims by verifying the cryptographic signature of the token against a pre-shared secret key.
In versions of Mnemosyne prior to v3.10.1, the cryptographic validation step was completely omitted. Although the server extracted, parsed, and evaluated the token payload, it never performed the signature verification calculation. This flaw exposes the sync server to complete authentication bypass, allowing unauthenticated network actors to read or write arbitrary AI agent history data.
The root cause of CVE-2026-59163 is localized within the _check_auth method of the SyncHTTPHandler class in mnemosyne/core/sync_server.py. To avoid external dependencies, the developers implemented a custom, lightweight JWT parsing function rather than importing a standard library like PyJWT or python-jose.
The parsing routine splits the incoming string in the Authorization header by the . delimiter. A standard JWT contains three components: the header, the payload, and the cryptographic signature. The custom routine extracted the base64-encoded payload (the second segment), applied the necessary padding corrections, decoded it, and parsed the resulting JSON string into a Python dictionary. It evaluated the exp claim to ensure the token had not expired, but then returned True (indicating a successful authentication) without checking the third segment.
By ignoring the signature segment entirely, the server trusts the claims declared in the payload implicitly. This makes the system vulnerable to key manipulation attacks and signature forgery. An attacker can construct a valid-looking JSON object with arbitrary claims, sign it with a custom algorithm, append a dummy signature string, and submit it to gain unauthorized administrative access. The server cannot distinguish between a legitimate token signed with the actual secret and a fabricated token.
Analyzing the vulnerable implementation of the _check_auth method reveals the specific code path that omitted signature validation. The key operations performed during a request are highlighted in the following comparison:
# Vulnerable implementation in mnemosyne/core/sync_server.py (prior to v3.10.1)
def _check_auth(self) -> bool:
auth = self.headers.get("Authorization", "")
if auth:
if not auth.startswith("Bearer "):
self._send_error(401, "Missing Bearer token")
return False
token = auth[7:]
try:
parts = token.split(".")
if len(parts) != 3:
self._send_error(401, "Invalid JWT format")
return False
payload_b64 = parts[1]
# Fix padding
pad = 4 - len(payload_b64) % 4
if pad != 4:
payload_b64 += "=" * pad
payload_bytes = _b64.urlsafe_b64decode(payload_b64)
payload = json.loads(payload_bytes.decode("utf-8"))
# Expiry validation occurs here, but parts[2] (signature) is completely ignored
exp = payload.get("exp", 0)
if exp and exp < datetime.now().timestamp():
self._send_error(401, "Token expired")
return False
return True
except Exception as e:
self._send_error(401, f"JWT validation failed: {e}")
return FalseThe patched implementation replaces this custom inline parsing logic with a secure validation utility named _validate_jwt. The update strictly checks the header's algorithm and computes a valid HMAC signature over the header and payload segments:
# Patched implementation in mnemosyne/core/sync_server.py (v3.10.1)
def _validate_jwt(self, token: str) -> dict:
if not self.jwt_secret:
raise ValueError("JWT secret is not configured")
parts = token.split(".")
if len(parts) != 3:
raise ValueError("invalid JWT format")
header = self._decode_jwt_part(parts[0])
payload = self._decode_jwt_part(parts[1])
algorithm = header.get("alg")
# Prevent algorithm confusion / none-algorithm bypasses
if algorithm != "HS256":
raise ValueError("unsupported JWT algorithm")
# Compute the expected signature locally using the configured secret
signing_input = f"{parts[0]}.{parts[1]}".encode("ascii")
expected = hmac.new(
self.jwt_secret.encode("utf-8"), signing_input, hashlib.sha256
).digest()
expected_sig = base64.urlsafe_b64encode(expected).decode("ascii").rstrip("=")
# Perform constant-time verification to prevent timing attacks
try:
valid_signature = hmac.compare_digest(parts[2], expected_sig)
except TypeError as e:
raise ValueError("invalid JWT signature") from e
if not valid_signature:
raise ValueError("invalid JWT signature")
# Verify UTC-aware token lifetime
exp = payload.get("exp")
if exp is not None:
try:
if float(exp) < datetime.now(timezone.utc).timestamp():
raise ValueError("token expired")
except (TypeError, ValueError) as e:
raise ValueError("invalid JWT exp") from e
return payloadThe patch successfully resolves the vulnerability. By checking that algorithm == "HS256", it prevents attackers from submitting a token with "alg": "none". The use of hmac.compare_digest stops timing-based side-channel attacks on the signature. This is a complete and robust remediation of the root cause within the sync server's codebase.
Exploitation of CVE-2026-59163 is straightforward and does not require complex tooling. Because the server completely bypasses signature verification, any well-formed JWT structure with an unexpired timestamp is processed as valid.
An attacker can construct a fake token manually using Python, standard command-line tools, or online utilities. The structure of the attack flow is outlined in the following diagram:
To execute the exploit, an attacker creates a JWT header indicating HS256 or none and a payload claiming administrative rights with an expiration timestamp set in the future. Both the header and payload are base64url-encoded and concatenated using a period delimiter. The attacker appends any arbitrary sequence (such as forged) to act as the signature segment, and inject the token into the Authorization header of an HTTP request.
Upon receiving the request, the vulnerable sync server extracts the token, verifies that the format is valid (consisting of exactly three components separated by dots), and confirms that the expiration date has not passed. The server then grants the attacker full access. This bypass allows unauthenticated remote actors to query synchronization statuses, retrieve critical agent memory stores, or overwrite current states with corrupt datasets.
The vulnerability carries a critical severity rating, represented by a CVSS v3.1 base score of 9.1. The potential consequences of successful exploitation are extensive, directly threatening the confidentiality and integrity of synchronized artificial intelligence workloads.
Because Mnemosyne serves as a localized memory layer for AI agents, the data synchronized via the server contains private context, credentials, conversation history, and structural instructions. An attacker who gains access can extract this sensitive metadata. This results in complete exposure of private information and data leakage.
Furthermore, the ability to write to the synchronization database allows an attacker to poison the memory banks of the AI agent. By injecting malicious synchronized events or overwriting existing states, an attacker can manipulate the behavior of the agent in downstream executions. This could cause the agent to execute unauthorized actions, leak operational boundaries, or process untrusted datasets under false assumptions.
The primary and recommended mitigation for CVE-2026-59163 is upgrading the Mnemosyne package to version 3.10.1 or higher. The patch fully implements cryptographic signature checking and closes the vulnerability.
If upgrading immediately is not possible, administrators should deploy defense-in-depth mitigations. First, bind the sync server explicitly to 127.0.0.1 so that it does not listen on public network interfaces. If remote clients must connect, mandate the use of secure SSH tunnels or virtual private networks (VPNs) to restrict access to authenticated devices.
Second, implement a reverse proxy such as NGINX or HAProxy in front of the sync server. Configure the proxy to handle incoming connections and enforce client-side certificate validation (mutual TLS) or apply robust IP-based restriction lists. Additionally, the pre-shared secret used to sign legitimate tokens must be updated immediately after patching, as previous sessions might have been analyzed by unauthorized actors.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N| Product | Affected Versions | Fixed Version |
|---|---|---|
Mnemosyne Mnemosyne-OSS | < 3.10.1 | 3.10.1 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-347 |
| Attack Vector | Network (AV:N) |
| CVSS | 9.1 (Critical) |
| EPSS | Not Available |
| Impact | Full Authentication Bypass |
| Exploit Status | PoC (Trivial to exploit) |
| KEV Status | Not Listed |
The software imports or uses a cryptographic signature but does not verify, or incorrectly verifies, the signature, allowing attackers to spoof identities or data.
An arbitrary file read and path traversal vulnerability exists in Perses prior to version 0.54.0-rc.0. When configured with a file-system database backend, the application lacks input validation on the request-controlled project query parameter. An authenticated attacker with low privileges can supply directory traversal sequences to read arbitrary JSON or YAML files on the host file system.
An authorization bypass vulnerability exists in the Moquette MQTT broker prior to version 0.18.1. When an MQTT client registers a Last Will and Testament (LWT) topic during its connection setup, the broker fails to perform write-access checks on that topic. Upon an abrupt client disconnection, the broker publishes the registered Will message to subscribers of the unauthorized topic, bypassing configured Access Control Lists (ACLs).
A concurrent execution vulnerability (CWE-362) exists in the Paymenter webshop solution within the service downgrade execution path (doUpgrade). Authenticated customers can exploit this concurrency issue by sending concurrent HTTP requests to trigger multiple parallel executions of the refund process. Because the application checks for pending upgrades without database transactional isolation or exclusive row locks, attackers can generate multiple duplicate refunds to their account balance for a single downgrade action. This leads to arbitrary credit inflation on the platform.
A critical security vulnerability exists in the Obot Platform (versions < 0.23.0) where unauthenticated OAuth dynamic client registration, a consentless authorization flow, and a lack of JWT audience validation enable remote attackers to steal API tokens via audience confusion.
An authentication bypass vulnerability in Obot versions <= v0.22.1 allows unauthenticated remote attackers to access Model Context Protocol (MCP) registry metadata and retrieve server lists when OBOT_SERVER_ENABLE_REGISTRY_AUTH is configured. This is due to a routing logic flaw where `/v0.1` paths are incorrectly categorized as public frontend user interface assets.
An authenticated Server-Side Request Forgery (SSRF) vulnerability in the Obot Platform allows administrative or power users to bypass IP verification and scan or query internal resources, private networks, and cloud instance metadata services (IMDS). Because response bodies and error details are reflected back to the client interface, this constitutes a non-blind SSRF.