CVE-2026-85709: OpenAI Node error messages leak

Q: Is CVE-2026-85709 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-85709, increasing the risk of exploitation.

Q: How to fix CVE-2026-85709?

1) Upgrade lightrag-hku to 1.5.5 or later (fix in PR #3422 and the commits listed in the advisory). 2) Enable API authentication and do not expose the server to untrusted networks; place it behind a reverse proxy, VPN or API gateway. 3) Rotate database, LLM provider and other credentials for any instance that was reachable, since error responses may have exposed them. 4) Where patching is delayed, use a reverse proxy to replace 5xx response bodies with generic messages and rate-limit unauthenticated clients. 5) Review access logs for bursts of malformed requests or repeated 4xx/5xx responses against document, graph, query and Ollama API routes. 6) Use secret references or environment-based credentials in place of URIs with embedded passwords, and restrict backing databases to the application host.

Q: What systems are affected by CVE-2026-85709?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, Graph-based RAG, LLM API servers, Vector databases, Knowledge graph backends.

Q: What is the CVSS score for CVE-2026-85709?

CVE-2026-85709 has a CVSS v3.1 base score of 5.3 (MEDIUM). The EPSS exploitation probability is 0.42%.

CISO Take

LightRAG's API server returns raw Python exception text to clients, exposing server filesystem paths, database host, port, user and name, LLM provider diagnostics and library internals. Because the default configuration has no authentication, any network client who can trigger an error gets this data, and URI-configured backends can leak connection strings containing credentials depending on the driver error. The direct impact is low (CVSS 5.3, confidentiality only), but PoC code exists, the package has 1,508 downstream dependents and 23 other CVEs, and the leaked data is useful reconnaissance for chaining into attacks on the backing databases. Exploitation likelihood is modest (EPSS 0.39%, top 69%), it is not in CISA KEV, and CISA SSVC says TRACK*. Upgrade lightrag-hku to 1.5.5 or later, put the API behind authentication and network controls, and rotate any database or LLM credentials that may have appeared in error responses.

Sources:NVDGitHub AdvisoryEPSSATLASCISA SSVC

What is the risk?

Medium overall. Exploitation is trivial: it needs only network access, no credentials and no user interaction, and a malformed request is enough to trigger an error. The impact is limited to information disclosure (CWE-209), with no integrity or availability effect. Risk rises sharply where the server is internet-exposed with default no-auth settings, or where backends (Postgres, Neo4j, Redis, MongoDB and similar) are configured via URIs with embedded credentials. In those cases leaked credentials could turn a low-severity issue into data-store compromise. A public PoC and widespread use as a RAG backend add to the exposure, but there is no evidence of active exploitation.

How does the attack unfold?

Discovery

Attacker finds an exposed LightRAG API server that accepts unauthenticated requests.

AML.T0006

Error Triggering

Attacker sends malformed or invalid requests to document, graph, query or Ollama API routes to trigger unhandled exceptions.

AML.T0049

Information Disclosure

The server returns raw exception text with filesystem paths, database details, provider diagnostics and possibly connection strings with credentials.

AML.T0069

Follow-on Impact

Attacker uses the leaked details or credentials to target backing data stores or chain other known LightRAG vulnerabilities.

AML.T0055

Discovery

Attacker finds an exposed LightRAG API server that accepts unauthenticated requests.

AML.T0006

Error Triggering

Attacker sends malformed or invalid requests to document, graph, query or Ollama API routes to trigger unhandled exceptions.

AML.T0049

Information Disclosure

The server returns raw exception text with filesystem paths, database details, provider diagnostics and possibly connection strings with credentials.

AML.T0069

Follow-on Impact

Attacker uses the leaked details or credentials to target backing data stores or chain other known LightRAG vulnerabilities.

AML.T0055

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
OpenAI Node	pip	<= 1.5.4	`1.5.5`
11.2K1.8K dependentsPushed 7d ago53% patched~139d to patchFull package profile →

Do you use OpenAI Node? You're affected.

How severe is it?

CVSS 3.1

5.3 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 36% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○CISA SSVC: Public PoC

○Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVNetwork

ACLow

PRNone

UINone

SUnchanged

CLow

INone

ANone

What should I do?

1 step

1) Upgrade lightrag-hku to 1.5.5 or later (fix in PR #3422 and the commits listed in the advisory). 2) Enable API authentication and do not expose the server to untrusted networks; place it behind a reverse proxy, VPN or API gateway. 3) Rotate database, LLM provider and other credentials for any instance that was reachable, since error responses may have exposed them. 4) Where patching is delayed, use a reverse proxy to replace 5xx response bodies with generic messages and rate-limit unauthenticated clients. 5) Review access logs for bursts of malformed requests or repeated 4xx/5xx responses against document, graph, query and Ollama API routes. 6) Use secret references or environment-based credentials in place of URIs with embedded passwords, and restrict backing databases to the application host.

What does CISA's SSVC say?

DecisionTrack*

Exploitationpoc

AutomatableYes

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data LeakageData ExtractionRAGAPIFrameworkAML.T0006- Active Scanning AML.T0049- Exploit Public-Facing Application AML.T0055- Unsecured Credentials AML.T0069- Discover LLM System Information

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Responding to unknown risks and managing deployed AI risks

OWASP LLM Top 10

LLM02:2025-Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-85709?

LightRAG's API server returns raw Python exception text to clients, exposing server filesystem paths, database host, port, user and name, LLM provider diagnostics and library internals. Because the default configuration has no authentication, any network client who can trigger an error gets this data, and URI-configured backends can leak connection strings containing credentials depending on the driver error. The direct impact is low (CVSS 5.3, confidentiality only), but PoC code exists, the package has 1,508 downstream dependents and 23 other CVEs, and the leaked data is useful reconnaissance for chaining into attacks on the backing databases. Exploitation likelihood is modest (EPSS 0.39%, top 69%), it is not in CISA KEV, and CISA SSVC says TRACK*. Upgrade lightrag-hku to 1.5.5 or later, put the API behind authentication and network controls, and rotate any database or LLM credentials that may have appeared in error responses.

Is CVE-2026-85709 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-85709, increasing the risk of exploitation.

How to fix CVE-2026-85709?

1) Upgrade lightrag-hku to 1.5.5 or later (fix in PR #3422 and the commits listed in the advisory). 2) Enable API authentication and do not expose the server to untrusted networks; place it behind a reverse proxy, VPN or API gateway. 3) Rotate database, LLM provider and other credentials for any instance that was reachable, since error responses may have exposed them. 4) Where patching is delayed, use a reverse proxy to replace 5xx response bodies with generic messages and rate-limit unauthenticated clients. 5) Review access logs for bursts of malformed requests or repeated 4xx/5xx responses against document, graph, query and Ollama API routes. 6) Use secret references or environment-based credentials in place of URIs with embedded passwords, and restrict backing databases to the application host.

What systems are affected by CVE-2026-85709?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, Graph-based RAG, LLM API servers, Vector databases, Knowledge graph backends.

What is the CVSS score for CVE-2026-85709?

CVE-2026-85709 has a CVSS v3.1 base score of 5.3 (MEDIUM). The EPSS exploitation probability is 0.42%.

What is the AI security impact?

Affected AI Architectures

RAG pipelinesGraph-based RAGLLM API serversVector databasesKnowledge graph backends

MITRE ATLAS Techniques

AML.T0006Active Scanning

AML.T0049Exploit Public-Facing Application

AML.T0055Unsecured Credentials

AML.T0069Discover LLM System Information

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM02:2025

What are the technical details?

Original Advisory

LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.5.5, the LightRAG API server returns raw Python exception text from error handlers in document_routes.py, graph_routes.py, query_routes.py, ollama_api.py, and lightrag_server.py. The detail=str(e), detail=str(exc), and equivalent formatted-message paths expose server filesystem paths, database host, port, user, and database names, language-model provider diagnostics, configuration details, and Python library internals to a network client that can trigger an error. The default unauthenticated configuration makes those responses reachable without credentials, and URI-configured backends can disclose connection strings containing credentials depending on the underlying driver error. This issue is fixed in version 1.5.5.

Exploitation Scenario

An attacker scans for exposed LightRAG API servers, then sends malformed queries or invalid document and graph requests to the unauthenticated endpoints to trigger exceptions. The responses return raw error text containing the PostgreSQL or Neo4j host, port, user and database name, filesystem paths, and LLM provider diagnostics. If the backend is set up through a connection URI, the driver error may include the credentials. The attacker uses this to map the internal environment, attempt direct access to the exposed data stores holding the organization's embedded documents and knowledge graph, or pick other known LightRAG flaws to exploit.

Weaknesses (CWE)

CWE-209Generation of Error Message Containing Sensitive InformationPrimary CWE-209Generation of Error Message Containing Sensitive InformationPrimary CWE-209Generation of Error Message Containing Sensitive Information

CWE-209 — Generation of Error Message Containing Sensitive Information: The product generates an error message that includes sensitive information about its environment, users, or associated data.

[Implementation] Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
[Implementation] Handle exceptions internally and do not display errors containing potentially sensitive information to a user.

Source: MITRE CWE corpus.