CVE-2026-75110: MemOS Authentication Bypass Vulnerability

CVE-2026-75110 Overview

CVE-2026-75110 is an authentication bypass in MemOS, a memory operating system for large language models (LLMs) and AI agents. The flaw resides in the is_internal_request() check within src/memos/api/middleware/auth.py. When AUTH_ENABLED=true but the undocumented INTERNAL_SERVICE_SECRET environment variable remains unset, os.getenv("INTERNAL_SERVICE_SECRET") returns None. A request that omits the X-Internal-Service header also returns None, so the comparison None == None evaluates true. The middleware then treats the caller as a trusted internal principal and assigns scopes ["all"], exposing admin API-key management and all data endpoints.

Critical Impact
An unauthenticated remote attacker can mint, enumerate, and revoke API keys for any user, and generate a master key for persistent privileged access.

Affected Products

MemOS (MemTensor) deployments running with AUTH_ENABLED=true
MemOS instances where INTERNAL_SERVICE_SECRET is unset
MemOS admin API-key management and data endpoints

Discovery Timeline

2026-08-17 - CVE-2026-75110 published to NVD
2026-08-18 - Last updated in NVD database

Technical Details for CVE-2026-75110

Vulnerability Analysis

The vulnerability is an authentication bypass caused by incorrect comparison logic [CWE-697] in the MemOS API authentication middleware. The is_internal_request() function determines whether a caller is a trusted internal service by comparing the value of the X-Internal-Service HTTP header against the INTERNAL_SERVICE_SECRET environment variable.

Because INTERNAL_SERVICE_SECRET is undocumented and has no default value, operators enabling authentication with AUTH_ENABLED=true frequently leave it unset. In Python, os.getenv() returns None for missing variables, and Flask/FastAPI header accessors return None for absent headers. The middleware performs a direct equality comparison without validating that either value is non-empty.

Once the check returns true, MemOS elevates the request context to an internal principal and assigns scopes ["all"], granting full administrative authority over the API surface.

Root Cause

The root cause is an insecure fail-open comparison. The predicate does not enforce that the configured secret is present before authorizing the request. A missing configuration value collapses into a default-allow authorization decision instead of failing closed.

Attack Vector

The attack is network-based, requires no authentication, no user interaction, and no prior privileges. An attacker sends HTTP requests to a reachable MemOS instance without supplying the X-Internal-Service header. Because the header and the environment variable both evaluate to None, the middleware authorizes the request with full scopes. The attacker can then invoke admin endpoints to mint API keys for arbitrary users, enumerate existing keys, revoke keys, generate a master key, and read or modify data across all tenants.

Refer to the VulnCheck Advisory on MemOS and the GitHub MemOS Auth Middleware Code for the vulnerable logic.

Detection Methods for CVE-2026-75110

Indicators of Compromise

Unexpected API-key creation, enumeration, or revocation events in MemOS audit logs from unknown source IPs.
Presence of a newly generated master key that was not provisioned by an authorized administrator.
Successful admin endpoint responses to requests that lack an Authorization header and an X-Internal-Service header.

Detection Strategies

Inspect MemOS deployments for AUTH_ENABLED=true combined with an unset or empty INTERNAL_SERVICE_SECRET environment variable.
Alert on HTTP requests to /admin/* and API-key management routes that succeed without an Authorization bearer token.
Review recent access to data endpoints for principals resolved as internal without a corresponding upstream service identity.

Monitoring Recommendations

Forward MemOS application and reverse-proxy logs to a centralized logging platform and enable retention for authentication events.
Baseline normal API-key lifecycle activity and alert on anomalous mint or master-key generation events.
Monitor egress from MemOS hosts for unusual data volumes that may indicate exfiltration through authorized-looking API calls.

How to Mitigate CVE-2026-75110

Immediate Actions Required

Set INTERNAL_SERVICE_SECRET to a strong, high-entropy value on every MemOS deployment where AUTH_ENABLED=true.
Rotate all existing MemOS API keys and revoke any master keys generated during the exposure window.
Restrict network access to MemOS admin endpoints to trusted internal networks or an authenticated reverse proxy.

Patch Information

No fixed version is listed in the NVD entry at publication. Track remediation status through the GitHub MemOS Issue #2259 and the GitHub MemOS Repository. Apply upstream fixes once released and confirm that is_internal_request() fails closed when the secret is absent.

Workarounds

Configure MemOS with a non-empty INTERNAL_SERVICE_SECRET before exposing the API to any network.
Deploy MemOS behind an authenticating reverse proxy that strips or validates the X-Internal-Service header on ingress.
Block external access to admin API-key management routes at the network or ingress layer until a vendor patch is applied.

bash

# Configuration example: set a strong internal service secret before starting MemOS
export AUTH_ENABLED=true
export INTERNAL_SERVICE_SECRET="$(openssl rand -hex 32)"

# Example NGINX rule to strip attacker-supplied X-Internal-Service headers at ingress
# proxy_set_header X-Internal-Service "";