Security readout for executives and security teams
Plain-English summary
LightRAG versions before 1.5.4 could trust requests from any website while still sending a logged-in user's credentials. If an authenticated user visits a malicious page, that page may be able to make LightRAG API actions as the user, exposing documents or knowledge graph data and potentially changing or deleting stored content.
Executive priority
Treat this as urgent for any LightRAG deployment holding confidential documents, internal knowledge graphs, or operational data. The fix is version-based and the vulnerable behavior is a default, so teams should prioritize inventory, upgrade, and configuration review over waiting for exploitation signals.
Technical view
The server defaulted to CORS_ORIGINS=* with allow_credentials=True in lightrag/api/lightrag_server.py. The advisory says this caused Starlette CORSMiddleware to effectively allow credentialed cross-origin requests from any origin. The affected product is HKUDS LightRAG before 1.5.4. CVSS is 9.3, with low complexity and required user interaction.
Likely exposure
Exposure is most likely where LightRAG versions earlier than 1.5.4 are reachable by browsers and users authenticate to the API. Publicly reachable deployments or shared internal tools with sensitive document stores have the highest business risk. The source bundle does not provide CPEs or a complete deployment inventory method.
Exploitation context
The source bundle says KEV is false and provides no cited evidence of active exploitation. Exploitation requires a victim authenticated to LightRAG to visit a malicious website. The issue is still serious because the vulnerable default can enable credentialed API requests from untrusted origins.
Researcher notes
The strongest evidence is the GitHub advisory, linked fix PR, commits, and v1.5.4 release. The source bundle attributes the issue to CWE-942 and does not provide active exploitation evidence. Avoid assuming other RAG platforms or downstream packages are affected without separate confirmation.
Mitigation direction
- Upgrade HKUDS LightRAG to version 1.5.4 or later.
- Set CORS_ORIGINS to explicit trusted origins only.
- Avoid combining wildcard origins with credentialed browser requests.
- Review vendor advisory and release notes for configuration guidance.
- Restrict LightRAG access to trusted networks where possible.
- Review sensitive document stores for unexpected changes or access.
Validation and detection
- Inventory LightRAG deployments and identify versions before 1.5.4.
- Inspect CORS_ORIGINS and credentialed CORS settings in server configuration.
- Confirm only trusted origins receive credentialed cross-origin access.
- Review logs for unusual authenticated API activity from browser sessions.
- Verify sensitive document and knowledge graph APIs require expected authorization.
- Confirm upgrade or configuration changes are deployed in all environments.
Public sources used
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
CWE-942: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Open ATT&CK lookupCVE-2026-61736 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
Open ATT&CK lookup- Severity
- Critical
- CVSS
- 9.3 (3.1)
- Known Exploited
- No
- Published
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N
CNA and ADP enrichment extracted from CVE v5
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
SSVC decision data
CVSS vector scores
1 official scoreWe collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N2.85.8GitHub_MVulnerability scoring details
Base CVSS 3.1 score
9.3CriticalVector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
- CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
- CVE publishedCVE Program
The CVE record was published.
- CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.
ADP provider summaries
Source materials
- CVE List V5 sourceCVE List V5
- https://github.com/HKUDS/LightRAG/security/advisories/GHSA-6x6h-qqr7-855wCVE reference, GitHub_M · x_refsource_CONFIRM
- https://github.com/HKUDS/LightRAG/pull/3317CVE reference, GitHub_M · x_refsource_MISC
- https://github.com/HKUDS/LightRAG/commit/09567a4c983f580050db63569dd477122c058c3dCVE reference, GitHub_M · x_refsource_MISC
- https://github.com/HKUDS/LightRAG/commit/df68d75f9dc29dd340ffb6794b48f48c4fdc9a2dCVE reference, GitHub_M · x_refsource_MISC
- https://github.com/HKUDS/LightRAG/commit/ebba6548639c0f2e8919100eff76b401f1222252CVE reference, GitHub_M · x_refsource_MISC
- https://github.com/HKUDS/LightRAG/releases/tag/v1.5.4CVE reference, GitHub_M · x_refsource_MISC
Products and packages named in the record
CWE details
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
Permissive Cross-domain Security Policy with Untrusted Domains
Permissive Cross-domain Security Policy with Untrusted Domains represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.