CVE-2025-41258

Executive Summary

CVE-2025-41258 is a critical authentication bypass vulnerability in LibreChat version 0.8.1-rc2. The flaw arises from the reuse of the same JSON Web Token (JWT) secret for both the user session mechanism and the RAG (Retrieval-Augmented Generation) API. This design error compromises the service-level authentication of the RAG API, allowing an attacker who obtains a valid user session JWT to impersonate the RAG API service. The vulnerability has a CVSS score of 8.0 (High) and currently has no known patch or public exploit code. The EPSS score is 0.0%, indicating low exploitation activity in the wild, but the severity remains high due to the potential for unauthorized access to sensitive RAG API endpoints.

Supply Chain & Package Security

LibreChat is an open-source chat application built with Node.js and npm. The vulnerability is not a supply chain compromise but a design flaw in the application's authentication logic. However, the reuse of JWT secrets across different services (user session and RAG API) is a common anti-pattern that can be introduced through insecure coding practices or misconfiguration. Organizations using LibreChat should audit their deployment for any custom modifications that might have introduced similar issues.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – The vulnerability can be exploited remotely over the network.
• Attack Complexity (AC): Low (L) – No special conditions are required; a valid user session JWT is sufficient.
• Privileges Required (PR): None (N) – An attacker does not need any privileges to exploit this; they only need to obtain a valid user session JWT.
• User Interaction (UI): None (N) – No user interaction is required.
• Scope (S): Unchanged (U) – The exploitation does not affect other components beyond the RAG API.
• Confidentiality (C): High (H) – Unauthorized access to RAG API data, which may include sensitive documents or internal knowledge bases.
• Integrity (I): High (H) – An attacker could modify or inject data into the RAG API.
• Availability (A): High (H) – An attacker could disrupt the RAG API service.

Threat Level: High. The vulnerability allows an attacker with a valid user session JWT to bypass authentication for the RAG API, potentially leading to data exfiltration, manipulation, or denial of service.

Deep Dive & Mechanics

The vulnerability stems from the architectural decision to use the same JWT secret for two distinct purposes:

1. User Session Management: JWTs are issued to users upon login to authenticate their sessions.
2. RAG API Authentication: The RAG API uses the same JWT secret to verify incoming requests, expecting a different set of claims or a specific audience.

Because the secret is identical, any valid user session JWT can be used to authenticate to the RAG API. The RAG API likely validates the JWT signature but does not enforce a unique audience or scope claim that would differentiate a user token from a service token. This allows an attacker to:

• Intercept a user's JWT (e.g., via network sniffing, XSS, or logging).
• Replay that JWT to the RAG API endpoint.
• Gain unauthorized access to RAG API functionality, such as querying or modifying the knowledge base.

The vulnerability is classified under CWE-287 (Improper Authentication) because the authentication mechanism does not properly verify the identity of the caller.

Vulnerable vs. Patched Code

Since no patch is available, the following is a conceptual comparison.

Vulnerable Code (LibreChat 0.8.1-rc2):

// JWT secret used for both user sessions and RAG API
const jwtSecret = process.env.JWT_SECRET;

// User session token generation
function generateUserToken(user) {
  return jwt.sign({ userId: user.id, role: 'user' }, jwtSecret, { expiresIn: '1h' });
}

// RAG API token verification
function verifyRagApiToken(token) {
  try {
    const decoded = jwt.verify(token, jwtSecret);
    // No check for audience or role
    return decoded;
  } catch (err) {
    return null;
  }
}

Patched Code (Conceptual):

// Separate secrets for different services
const userJwtSecret = process.env.USER_JWT_SECRET;
const ragJwtSecret = process.env.RAG_JWT_SECRET;

// User session token generation
function generateUserToken(user) {
  return jwt.sign({ userId: user.id, role: 'user' }, userJwtSecret, { expiresIn: '1h' });
}

// RAG API token verification with audience check
function verifyRagApiToken(token) {
  try {
    const decoded = jwt.verify(token, ragJwtSecret, { audience: 'rag-api' });
    return decoded;
  } catch (err) {
    return null;
  }
}

Exploitation & Lab Setup

Red Team

Prerequisites:

• A running instance of LibreChat 0.8.1-rc2.
• A valid user session JWT (obtained via legitimate login, XSS, or network capture).

Exploitation Steps:

1. Obtain a valid user session JWT. For example, after logging in, capture the JWT from the browser's local storage or network traffic.
2. Identify the RAG API endpoint (e.g., /api/rag/query).
3. Send a request to the RAG API with the captured JWT in the Authorization header:

   curl -X POST https://target.com/api/rag/query \
     -H "Authorization: Bearer <user_jwt>" \
     -H "Content-Type: application/json" \
     -d '{"query": "What is the secret project?"}'
   

4. If the RAG API responds with data, the exploitation is successful.

Lab Setup:

• Use Docker to deploy LibreChat 0.8.1-rc2:

  docker run -d -p 3000:3000 --name librechat-vuln librechat/librechat:0.8.1-rc2
  

• Create a test user and obtain a JWT.
• Use the above curl command to test the exploit.

Blue Team

Detection:

• Monitor for unusual access to RAG API endpoints from user accounts that do not normally interact with the RAG API.
• Look for JWT tokens with unexpected claims (e.g., a user token being used for service-to-service communication).
• Implement logging of all JWT usage, including the token's aud (audience) claim.

Prevention:

• Immediately upgrade to a patched version once available.
• If patching is not possible, implement a reverse proxy that validates the JWT audience before forwarding to the RAG API.
• Use separate JWT secrets for different services and enforce audience claims.

Indicators of Compromise (IOCs)

• Network: HTTP requests to /api/rag/* endpoints with Authorization: Bearer <token> where the token's aud claim is missing or set to an unexpected value.
• Logs: Application logs showing successful authentication to the RAG API with a token that has a role of user instead of service or rag-api.
• System: Unusual queries to the RAG API that deviate from normal user behavior (e.g., bulk data extraction).

Detection Engineering

YARA Rule

rule CVE_2025_41258_JWT_Reuse {
  meta:
    description = "Detects JWT tokens that may be reused across user session and RAG API"
    author = "Valters IT"
    date = "2025-04-10"
    reference = "CVE-2025-41258"
  strings:
    $jwt_header = "eyJ" // Base64 of {"typ":"JWT","alg":"HS256"}
    $rag_endpoint = "/api/rag/"
  condition:
    $jwt_header at 0 and $rag_endpoint
}

Sigma Rule

title: CVE-2025-41258 - JWT Reuse for RAG API
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects HTTP requests to RAG API endpoints with JWT tokens that may be reused from user sessions.
author: Valters IT
date: 2025-04-10
logsource:
  category: webserver
  product: apache
  service: access_combined
detection:
  selection:
    cs-uri-stem:
      - "/api/rag/*"
    cs-method: "POST"
    cs-user-agent: "*"
  condition: selection
falsepositives:
  - Legitimate RAG API usage by authorized services
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
  msg:"CVE-2025-41258 - Potential JWT Reuse for RAG API";
  flow:to_server,established;
  content:"/api/rag/"; http_uri;
  content:"Authorization"; http_header;
  content:"Bearer"; http_header;
  sid:1000001;
  rev:1;
  reference:cve,2025-41258;
  classtype:attempted-recon;
  priority:1;
)

Remediation & Mitigation

Immediate Actions:

1. Isolate the RAG API: If possible, move the RAG API to a separate service with its own authentication mechanism (e.g., API keys or separate JWT secret).
2. Implement Audience Validation: Modify the RAG API to validate the aud (audience) claim in the JWT. User tokens should have an audience of user, while RAG API tokens should have an audience of rag-api.
3. Rotate Secrets: Generate a new, unique JWT secret for the RAG API and update the configuration.

Long-Term Fix:

• Wait for an official patch from LibreChat. Monitor the project's GitHub repository for updates.
• Conduct a security audit of all service-to-service authentication mechanisms to ensure no other secrets are reused.

Workaround:

• Use a reverse proxy (e.g., Nginx) to intercept requests to the RAG API and validate the JWT audience before forwarding:

  location /api/rag/ {
    auth_request /auth;
    proxy_pass http://backend;
  }
  location = /auth {
    internal;
    proxy_pass http://auth-service;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Original-URI $request_uri;
  }
  

Valters IT
Securing Digital Frontiers