<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-30T03:16:55.159740+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-85740</id>
    <title>fkie_cve-2026-85740</title>
    <updated>2026-09-30T03:16:55.191258+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-85740"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-vv3m-f8x4-7377</id>
    <title>GHSA-vv3m-f8x4-7377 — lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-downl…</title>
    <updated>2026-09-30T03:16:55.191417+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: lightrag-hku</p>
<p>## Summary</p>
<p>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.</p>
<p>## Affected component and versions</p>
<p>- Package: `lightrag-hku` (LightRAG), the native markdown image-download path.
- Component: `lightrag/parser/markdown/parser.py`, guard `_validated_addresses()` (the `if not (ip.is_global or ...)` check), reached from `_download()` -&gt; `_build_guarded_opener().open(req)`.
- Enabled by default: `download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True)`.
- Affected: LightRAG `&lt;= 1.5.4` (latest release at time of report, commit `9a45b64`).
- Precondition: the…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-vv3m-f8x4-7377"/>
  </entry>
</feed>
