CVE-2026-85740
LightRAG: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard
LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.5.5, _validated_addresses in lightrag/parser/markdown/parser.py evaluates the literal resolved address with ipaddress.is_global without consistently classifying an IPv4 address embedded in an IPv6 transition wrapper. A caller who can upload a Markdown or textpack document can supply an external image URL using NAT64 64:ff9b::/96 or an IPv4-compatible form that embeds a loopback, private, or cloud-metadata IPv4 address. On a deployment with compatible NAT64 or DNS64 routing, _download and _build_guarded_opener accept the wrapper and fetch the internal resource, whose body is then ingested. Current interpreter behavior already blocks some RFC 8215 and 6to4 forms, but the fixed guard handles all documented wrappers without becoming more permissive than the standard library. This issue is fixed in version 1.5.5.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- High
- Privileges needed
- Low
- User interaction
- None
What an attacker can affect
- Confidentiality
- High
- Integrity
- Low
- Availability
- None
Exploit likelihood
What each source reports
CVE List Score used
7.1
LightRAG: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard
LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.5.5, _validated_addresses in lightrag/parser/markdown/parser.py evaluates the literal resolved address with ipaddress.is_global without consistently classifying an IPv4 address embedded in an IPv6 transition wrapper. A caller who can upload a Markdown or textpack document can supply an external image URL using NAT64 64:ff9b::/96 or an IPv4-compatible form that embeds a loopback, private, or cloud-metadata IPv4 address. On a deployment with compatible NAT64 or DNS64 routing, _download and _build_guarded_opener accept the wrapper and fetch the internal resource, whose body is then ingested. Current interpreter behavior already blocks some RFC 8215 and 6to4 forms, but the fixed guard handles all documented wrappers without becoming more permissive than the standard library. This issue is fixed in version 1.5.5.
- Record
CVE-2026-85740- CVSS 3.1
- 7.1 High
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N - Weakness
- CWE-918
- Updated
- 2026-11-02
EUVDEUVD-2026-84549
7.1
LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.5.5, _validated_addresses in lightrag/parser/markdown/parser.py evaluates the literal resolved address with ipaddress.is_global without consistently classifying an IPv4 address embedded in an IPv6 transition wrapper. A caller who can upload a Markdown or textpack document can supply an external image URL using NAT64 64:ff9b::/96 or an IPv4-compatible form that embeds a loopback, private, or cloud-metadata IPv4 address. On a deployment with compatible NAT64 or DNS64 routing, _download and _build_guarded_opener accept the wrapper and fetch the internal resource, whose body is then ingested. Current interpreter behavior already blocks some RFC 8215 and 6to4 forms, but the fixed guard handles all documented wrappers without becoming more permissive than the standard library. This issue is fixed in version 1.5.5.
- Record
EUVD-2026-84549- CVSS 3.1
- 7.1 High
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-vv3m-f8x4-7377
7.1
lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard
Summary
LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. That check is evaluated on the raw resolved address and never decodes IPv6 transition wrappers that embed an internal IPv4. Python's ipaddress classifies a NAT64 (64:ff9b::/96 and the RFC 8215 64:ff9b:1::/48 prefix), IPv4-compatible (::a.b.c.d), or 6to4 (2002::/16) literal that wraps an internal IPv4 as globally routable, so the guard passes it. On a host with NAT64/DNS64 routing the request is then delivered to the embedded internal target (loopback, RFC1918, or a cloud metadata endpoint), and the fetched body is ingested. The plain and IPv4-mapped (::ffff:) forms of the same internal address are correctly blocked, so this is an encoding that defeats the existing filter.
Affected component and versions
- Package:
lightrag-hku(LightRAG), the native markdown image-download path. - Component:
lightrag/parser/markdown/parser.py, guard_validated_addresses()(theif not (ip.is_global or ...)check), reached from_download()->_build_guarded_opener().open(req). - Enabled by default:
download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True). - Affected: LightRAG
<= 1.5.4(latest release at time of report, commit9a45b64). - Precondition: the caller can upload a document (API key via
Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.
Vulnerable code vs the guarded sibling
Evaluated on the exact resolved addresses (CPython ipaddress):
| Form | address | is_global | guard verdict |
|---|---|---|---|
| plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) |
| IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) |
| NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) |
| NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) |
| IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) |
| 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |
The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.
Note — CPython version dependency of the table. The
is_globalverdicts above depend on the interpreter. CPython gh-113171 (backported to 3.10.14 / 3.11.9 / 3.12.3+, ~2024-04) added64:ff9b:1::/48and2002::/16toipaddress._private_networks, so on any current patch release those two rows returnis_global = Falseand are already blocked by the stdlib before the guard is reached. The64:ff9b::/96well-known NAT64 prefix and the IPv4-compatible::/96form bypass on every current CPython — and64:ff9b::/96is exactly the prefix real DNS64/NAT64 deployments use, so the vulnerability stands. The four-row table reflects a pre-gh-113171 interpreter. The fix classifies by the embedded IPv4 and therefore closes all forms regardless of interpreter version.
Severity
High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.
Proof of concept (deployed, both directions, verbatim)
Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client…
- Record
GHSA-vv3m-f8x4-7377- CVSS 3.1
- 7.1 High
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N - Weakness
- CWE-918
- Updated
- 2026-11-02
NVD
7.1
LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.5.5, _validated_addresses in lightrag/parser/markdown/parser.py evaluates the literal resolved address with ipaddress.is_global without consistently classifying an IPv4 address embedded in an IPv6 transition wrapper. A caller who can upload a Markdown or textpack document can supply an external image URL using NAT64 64:ff9b::/96 or an IPv4-compatible form that embeds a loopback, private, or cloud-metadata IPv4 address. On a deployment with compatible NAT64 or DNS64 routing, _download and _build_guarded_opener accept the wrapper and fetch the internal resource, whose body is then ingested. Current interpreter behavior already blocks some RFC 8215 and 6to4 forms, but the fixed guard handles all documented wrappers without becoming more permissive than the standard library. This issue is fixed in version 1.5.5.
- Record
CVE-2026-85740- CVSS 3.1
- 7.1 High
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N - Weakness
- CWE-918
- Updated
- 2026-11-02
OSV
7.1
LightRAG: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard
LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.5.5, _validated_addresses in lightrag/parser/markdown/parser.py evaluates the literal resolved address with ipaddress.is_global without consistently classifying an IPv4 address embedded in an IPv6 transition wrapper. A caller who can upload a Markdown or textpack document can supply an external image URL using NAT64 64:ff9b::/96 or an IPv4-compatible form that embeds a loopback, private, or cloud-metadata IPv4 address. On a deployment with compatible NAT64 or DNS64 routing, _download and _build_guarded_opener accept the wrapper and fetch the internal resource, whose body is then ingested. Current interpreter behavior already blocks some RFC 8215 and 6to4 forms, but the fixed guard handles all documented wrappers without becoming more permissive than the standard library. This issue is fixed in version 1.5.5.
- Record
CVE-2026-85740- CVSS 3.1
- 7.1 High
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N - Weakness
- CWE-918
- Updated
- 2026-11-02
OSVGHSA-vv3m-f8x4-7377
7.1
lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard
Summary
LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. That check is evaluated on the raw resolved address and never decodes IPv6 transition wrappers that embed an internal IPv4. Python's ipaddress classifies a NAT64 (64:ff9b::/96 and the RFC 8215 64:ff9b:1::/48 prefix), IPv4-compatible (::a.b.c.d), or 6to4 (2002::/16) literal that wraps an internal IPv4 as globally routable, so the guard passes it. On a host with NAT64/DNS64 routing the request is then delivered to the embedded internal target (loopback, RFC1918, or a cloud metadata endpoint), and the fetched body is ingested. The plain and IPv4-mapped (::ffff:) forms of the same internal address are correctly blocked, so this is an encoding that defeats the existing filter.
Affected component and versions
- Package:
lightrag-hku(LightRAG), the native markdown image-download path. - Component:
lightrag/parser/markdown/parser.py, guard_validated_addresses()(theif not (ip.is_global or ...)check), reached from_download()->_build_guarded_opener().open(req). - Enabled by default:
download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True). - Affected: LightRAG
<= 1.5.4(latest release at time of report, commit9a45b64). - Precondition: the caller can upload a document (API key via
Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.
Vulnerable code vs the guarded sibling
Evaluated on the exact resolved addresses (CPython ipaddress):
| Form | address | is_global | guard verdict |
|---|---|---|---|
| plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) |
| IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) |
| NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) |
| NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) |
| IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) |
| 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |
The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.
Note — CPython version dependency of the table. The
is_globalverdicts above depend on the interpreter. CPython gh-113171 (backported to 3.10.14 / 3.11.9 / 3.12.3+, ~2024-04) added64:ff9b:1::/48and2002::/16toipaddress._private_networks, so on any current patch release those two rows returnis_global = Falseand are already blocked by the stdlib before the guard is reached. The64:ff9b::/96well-known NAT64 prefix and the IPv4-compatible::/96form bypass on every current CPython — and64:ff9b::/96is exactly the prefix real DNS64/NAT64 deployments use, so the vulnerability stands. The four-row table reflects a pre-gh-113171 interpreter. The fix classifies by the embedded IPv4 and therefore closes all forms regardless of interpreter version.
Severity
High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.
Proof of concept (deployed, both directions, verbatim)
Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client…
- Record
GHSA-vv3m-f8x4-7377- CVSS 3.1
- 7.1 High
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N - Weakness
- CWE-918
- Updated
- 2026-11-02
OSVPYSEC-2026-4064
7.1
lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard
Summary
LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. That check is evaluated on the raw resolved address and never decodes IPv6 transition wrappers that embed an internal IPv4. Python's ipaddress classifies a NAT64 (64:ff9b::/96 and the RFC 8215 64:ff9b:1::/48 prefix), IPv4-compatible (::a.b.c.d), or 6to4 (2002::/16) literal that wraps an internal IPv4 as globally routable, so the guard passes it. On a host with NAT64/DNS64 routing the request is then delivered to the embedded internal target (loopback, RFC1918, or a cloud metadata endpoint), and the fetched body is ingested. The plain and IPv4-mapped (::ffff:) forms of the same internal address are correctly blocked, so this is an encoding that defeats the existing filter.
Affected component and versions
- Package:
lightrag-hku(LightRAG), the native markdown image-download path. - Component:
lightrag/parser/markdown/parser.py, guard_validated_addresses()(theif not (ip.is_global or ...)check), reached from_download()->_build_guarded_opener().open(req). - Enabled by default:
download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True). - Affected: LightRAG
<= 1.5.4(latest release at time of report, commit9a45b64). - Precondition: the caller can upload a document (API key via
Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.
Vulnerable code vs the guarded sibling
Evaluated on the exact resolved addresses (CPython ipaddress):
| Form | address | is_global | guard verdict |
|---|---|---|---|
| plain internal 127.0.0.1 | 127.0.0.1 | False | BLOCK (correct) |
| IPv4-mapped | ::ffff:7f00:1 | False | BLOCK (correct) |
| NAT64 64:ff9b::/96 | 64:ff9b::7f00:1 | True | PASS (bypass) |
| NAT64 RFC8215 64:ff9b:1::/48 | 64:ff9b:1::7f00:1 | True | PASS (bypass) |
| IPv4-compatible ::a.b.c.d | ::7f00:1 | True | PASS (bypass) |
| 6to4 2002::/16 | 2002:7f00:1:: | True | PASS (bypass) |
The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.
Note — CPython version dependency of the table. The
is_globalverdicts above depend on the interpreter. CPython gh-113171 (backported to 3.10.14 / 3.11.9 / 3.12.3+, ~2024-04) added64:ff9b:1::/48and2002::/16toipaddress._private_networks, so on any current patch release those two rows returnis_global = Falseand are already blocked by the stdlib before the guard is reached. The64:ff9b::/96well-known NAT64 prefix and the IPv4-compatible::/96form bypass on every current CPython — and64:ff9b::/96is exactly the prefix real DNS64/NAT64 deployments use, so the vulnerability stands. The four-row table reflects a pre-gh-113171 interpreter. The fix classifies by the embedded IPv4 and therefore closes all forms regardless of interpreter version.
Severity
High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.
Proof of concept (deployed, both directions, verbatim)
Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client…
- Record
PYSEC-2026-4064- CVSS 3.1
- 7.1 High
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N - Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
lightrag-hkuPyPI |
before 1.5.5 | 1.5.5 |
lightrag-hkuPyPI |
before 1.5.5, plus listed versions 0.0.20.0.30.0.40.0.50.0.6 Show 45 moreShow less0.0.70.0.80.0.91.0.01.0.11.0.31.0.51.0.61.0.81.0.91.1.01.1.11.1.21.1.31.1.41.1.51.1.61.1.71.2.11.2.21.2.31.2.51.2.61.3.01.3.11.3.21.3.31.3.41.3.51.3.61.3.71.3.81.3.91.4.01.4.11.4.101.4.111.4.11rc21.4.121.4.12rc11.4.131.4.13rc11.4.141.4.151.4.16 |
1.5.5 |
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2026-85740 is a high vulnerability (CVSS 7.1) in Hkuds Lightrag, published September 22, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.26%, the 18th percentile. Fixed in lightrag-hku 1.5.5.
References
github.com/HKUDS/LightRAG/security/advisories/GHSA-vv3m-f8x4-7377
github.com/HKUDS/LightRAG/pull/3426
github.com/HKUDS/LightRAG/commit/9207e7fd10cf6df3cf26e3dd1921490b34a2f132
github.com/HKUDS/LightRAG/commit/a25862177a9b00e0edb870778a42b4155924de09
github.com/HKUDS/LightRAG/commit/c598545aa0084a427bcb19a84ade5e0ec31fa673
github.com/HKUDS/LightRAG/releases/tag/v1.5.5
Left out here: 39 versions and the rest of 3 source descriptions. The JSON record has them.