CVEReports
CVEReports

Automated vulnerability intelligence platform. Comprehensive reports for high-severity CVEs generated by AI.

Product

  • Home
  • Sitemap
  • RSS Feed

Company

  • About
  • Contact
  • Privacy Policy
  • Terms of Service

© 2026 CVEReports. All rights reserved.

Made with love by Amit Schendel & Alon Barad



CVE-2026-59163

CVE-2026-59163: Critical JWT Authentication Bypass in Mnemosyne Sync Server

Alon Barad
Alon Barad
Software Engineer

Sep 19, 2026·7 min read·5 visits

Executive Summary (TL;DR)

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.

Vulnerability Overview

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.

Root Cause Analysis

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.

Code Analysis and Fix Evaluation

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 False

The 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 payload

The 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 Methodology

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.

Security Impact Assessment

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.

Remediation and Detection Guidance

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.

Official Patches

Mnemosyne-OSSOfficial Security Advisory

Fix Analysis (2)

Technical Appendix

CVSS Score
9.1/ 10
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Affected Systems

Mnemosyne Sync Server

Affected Versions Detail

Product
Affected Versions
Fixed Version
Mnemosyne
Mnemosyne-OSS
< 3.10.13.10.1
AttributeDetail
CWE IDCWE-347
Attack VectorNetwork (AV:N)
CVSS9.1 (Critical)
EPSSNot Available
ImpactFull Authentication Bypass
Exploit StatusPoC (Trivial to exploit)
KEV StatusNot Listed

MITRE ATT&CK Mapping

T1556Modify Authentication Process
Credential Access
T1539Steal Web Session / Access Token
Credential Access
T1021Remote Services
Lateral Movement
CWE-347
Improper Verification of Cryptographic Signature

The software imports or uses a cryptographic signature but does not verify, or incorrectly verifies, the signature, allowing attackers to spoof identities or data.

References & Sources

  • [1]Official GitHub Security Advisory
  • [2]Vulnerability Fix Commit
  • [3]Raw Code Patch File Reference
  • [4]Vulnerability Release Pull Request
  • [5]Official Release Announcement (v3.10.1)
  • [6]CVE Record Database Reference

Attack Flow Diagram

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.
Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

More Reports

•44 minutes ago•CVE-2026-63445
7.1

CVE-2026-63445: Arbitrary File Read and Path Traversal in Perses File-System Database Backend

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.

Amit Schendel
Amit Schendel
3 views•6 min read
•about 3 hours ago•CVE-2026-85058
7.5

CVE-2026-85058: Missing Authorization in Moquette MQTT Broker Last Will and Testament Feature

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).

Amit Schendel
Amit Schendel
5 views•8 min read
•about 4 hours ago•CVE-2026-71537
6.5

CVE-2026-71537: Credit-Refund Double-Spend Race Condition in Paymenter Service Downgrade

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.

Amit Schendel
Amit Schendel
5 views•9 min read
•about 5 hours ago•GHSA-XWMW-PRC4-V3CR
8.8

GHSA-XWMW-PRC4-V3CR: OAuth Dynamic Client Registration Enables API Token Theft via Audience Confusion in Obot 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.

Alon Barad
Alon Barad
6 views•6 min read
•about 6 hours ago•GHSA-PR6H-VR44-XQ8J
5.3

GHSA-PR6H-VR44-XQ8J: Authentication Bypass in Obot Model Context Protocol (MCP) Registry API

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.

Amit Schendel
Amit Schendel
5 views•8 min read
•about 11 hours ago•GHSA-JGH3-FGGC-MCPM
7.6

GHSA-jgh3-fggc-mcpm: Non-Blind Server-Side Request Forgery (SSRF) in Obot Platform

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.

Alon Barad
Alon Barad
9 views•8 min read