<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Thu, 08 Oct 2026 21:24:29 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-292521</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-292521</link>
      <description>EUVD-2026-292521</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-292521</guid>
    </item>
    <item>
      <title>fkie_cve-2026-39413</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-39413</link>
      <description>&lt;p&gt;LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.4.14, the LightRAG API is vulnerable to a JWT algorithm confusion attack where an attacker can forge tokens by specifying &amp;#39;alg&amp;#39;: &amp;#39;none&amp;#39; in the JWT header. Since the jwt.decode() call does not explicitly deny the &amp;#39;none&amp;#39; algorithm, a crafted token without a signature will be accepted as valid, leading to unauthorized access. This vulnerability is fixed in 1.4.14.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.4.14, the LightRAG API is vulnerable to a JWT algorithm confusion attack where an attacker can forge tokens by specifying &amp;#39;alg&amp;#39;: &amp;#39;none&amp;#39; in the JWT header. Since the jwt.decode() call does not explicitly deny the &amp;#39;none&amp;#39; algorithm, a crafted token without a signature will be accepted as valid, leading to unauthorized access. This vulnerability is fixed in 1.4.14.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-39413</guid>
    </item>
    <item>
      <title>GHSA-8ffj-4hx4-9pgf — lightrag-hku: JWT Algorithm Confusion Vulnerability</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-8ffj-4hx4-9pgf</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: lightrag-hku&lt;/p&gt;
&lt;p&gt;## Summary
The LightRAG API is vulnerable to a JWT algorithm confusion attack where an attacker can forge tokens by specifying &amp;#39;alg&amp;#39;: &amp;#39;none&amp;#39; in the JWT header. Since the `jwt.decode()` call does not explicitly deny the &amp;#39;none&amp;#39; algorithm, a crafted token without a signature will be accepted as valid, leading to unauthorized access.&lt;/p&gt;
&lt;p&gt;## Details
In `lightrag/api/auth.py` at line 128, the `validate_token` method calls:&lt;/p&gt;
&lt;p&gt;```python
payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])
```&lt;/p&gt;
&lt;p&gt;This allows any algorithm listed in the token&amp;#39;s header to be processed, including &amp;#39;none&amp;#39;. The code does not explicitly specify that &amp;#39;none&amp;#39; is not allowed, making it possible for an attacker to bypass authentication.&lt;/p&gt;
&lt;p&gt;## PoC
An attacker can generate a JWT with the following structure:&lt;/p&gt;
&lt;p&gt;```json
{
  &amp;#34;header&amp;#34;: {
    &amp;#34;alg&amp;#34;: &amp;#34;none&amp;#34;,
    &amp;#34;typ&amp;#34;: &amp;#34;JWT&amp;#34;
  },
  &amp;#34;payload&amp;#34;: {
    &amp;#34;sub&amp;#34;: &amp;#34;admin&amp;#34;,
    &amp;#34;exp&amp;#34;: 1700000000,
    &amp;#34;role&amp;#34;: &amp;#34;admin&amp;#34;
  }
}
```&lt;/p&gt;
&lt;p&gt;Then send a request like:&lt;/p&gt;
&lt;p&gt;```bash
curl -H &amp;#34;Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0.&amp;#34; http://localhost:8000/api/protected-endpoint
```&lt;/p&gt;
&lt;p&gt;## Impact
An attacker can impersonate any user, including administrators, by forging a JWT with &amp;#39;alg&amp;#39;: &amp;#39;none&amp;#39;, gaining full access to protected resources without needing valid credentials.&lt;/p&gt;
&lt;p&gt;## Recommended Fix
Explicitly specify allowed algorithms and exclude &amp;#39;none&amp;#39;. Modify the `validate_token` method to:&lt;/p&gt;
&lt;p&gt;```python
allowed_algorithms =…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: lightrag-hku&lt;/p&gt;
&lt;p&gt;## Summary
The LightRAG API is vulnerable to a JWT algorithm confusion attack where an attacker can forge tokens by specifying &amp;#39;alg&amp;#39;: &amp;#39;none&amp;#39; in the JWT header. Since the `jwt.decode()` call does not explicitly deny the &amp;#39;none&amp;#39; algorithm, a crafted token without a signature will be accepted as valid, leading to unauthorized access.&lt;/p&gt;
&lt;p&gt;## Details
In `lightrag/api/auth.py` at line 128, the `validate_token` method calls:&lt;/p&gt;
&lt;p&gt;```python
payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])
```&lt;/p&gt;
&lt;p&gt;This allows any algorithm listed in the token&amp;#39;s header to be processed, including &amp;#39;none&amp;#39;. The code does not explicitly specify that &amp;#39;none&amp;#39; is not allowed, making it possible for an attacker to bypass authentication.&lt;/p&gt;
&lt;p&gt;## PoC
An attacker can generate a JWT with the following structure:&lt;/p&gt;
&lt;p&gt;```json
{
  &amp;#34;header&amp;#34;: {
    &amp;#34;alg&amp;#34;: &amp;#34;none&amp;#34;,
    &amp;#34;typ&amp;#34;: &amp;#34;JWT&amp;#34;
  },
  &amp;#34;payload&amp;#34;: {
    &amp;#34;sub&amp;#34;: &amp;#34;admin&amp;#34;,
    &amp;#34;exp&amp;#34;: 1700000000,
    &amp;#34;role&amp;#34;: &amp;#34;admin&amp;#34;
  }
}
```&lt;/p&gt;
&lt;p&gt;Then send a request like:&lt;/p&gt;
&lt;p&gt;```bash
curl -H &amp;#34;Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0.&amp;#34; http://localhost:8000/api/protected-endpoint
```&lt;/p&gt;
&lt;p&gt;## Impact
An attacker can impersonate any user, including administrators, by forging a JWT with &amp;#39;alg&amp;#39;: &amp;#39;none&amp;#39;, gaining full access to protected resources without needing valid credentials.&lt;/p&gt;
&lt;p&gt;## Recommended Fix
Explicitly specify allowed algorithms and exclude &amp;#39;none&amp;#39;. Modify the `validate_token` method to:&lt;/p&gt;
&lt;p&gt;```python
allowed_algorithms =…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-8ffj-4hx4-9pgf</guid>
    </item>
    <item>
      <title>PYSEC-2026-2592 — lightrag-hku: JWT Algorithm Confusion Vulnerability</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-2592</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: lightrag-hku&lt;/p&gt;
&lt;p&gt;## Summary
The LightRAG API is vulnerable to a JWT algorithm confusion attack where an attacker can forge tokens by specifying &amp;#39;alg&amp;#39;: &amp;#39;none&amp;#39; in the JWT header. Since the `jwt.decode()` call does not explicitly deny the &amp;#39;none&amp;#39; algorithm, a crafted token without a signature will be accepted as valid, leading to unauthorized access.&lt;/p&gt;
&lt;p&gt;## Details
In `lightrag/api/auth.py` at line 128, the `validate_token` method calls:&lt;/p&gt;
&lt;p&gt;```python
payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])
```&lt;/p&gt;
&lt;p&gt;This allows any algorithm listed in the token&amp;#39;s header to be processed, including &amp;#39;none&amp;#39;. The code does not explicitly specify that &amp;#39;none&amp;#39; is not allowed, making it possible for an attacker to bypass authentication.&lt;/p&gt;
&lt;p&gt;## PoC
An attacker can generate a JWT with the following structure:&lt;/p&gt;
&lt;p&gt;```json
{
  &amp;#34;header&amp;#34;: {
    &amp;#34;alg&amp;#34;: &amp;#34;none&amp;#34;,
    &amp;#34;typ&amp;#34;: &amp;#34;JWT&amp;#34;
  },
  &amp;#34;payload&amp;#34;: {
    &amp;#34;sub&amp;#34;: &amp;#34;admin&amp;#34;,
    &amp;#34;exp&amp;#34;: 1700000000,
    &amp;#34;role&amp;#34;: &amp;#34;admin&amp;#34;
  }
}
```&lt;/p&gt;
&lt;p&gt;Then send a request like:&lt;/p&gt;
&lt;p&gt;```bash
curl -H &amp;#34;Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0.&amp;#34; http://localhost:8000/api/protected-endpoint
```&lt;/p&gt;
&lt;p&gt;## Impact
An attacker can impersonate any user, including administrators, by forging a JWT with &amp;#39;alg&amp;#39;: &amp;#39;none&amp;#39;, gaining full access to protected resources without needing valid credentials.&lt;/p&gt;
&lt;p&gt;## Recommended Fix
Explicitly specify allowed algorithms and exclude &amp;#39;none&amp;#39;. Modify the `validate_token` method to:&lt;/p&gt;
&lt;p&gt;```python
allowed_algorithms =…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: lightrag-hku&lt;/p&gt;
&lt;p&gt;## Summary
The LightRAG API is vulnerable to a JWT algorithm confusion attack where an attacker can forge tokens by specifying &amp;#39;alg&amp;#39;: &amp;#39;none&amp;#39; in the JWT header. Since the `jwt.decode()` call does not explicitly deny the &amp;#39;none&amp;#39; algorithm, a crafted token without a signature will be accepted as valid, leading to unauthorized access.&lt;/p&gt;
&lt;p&gt;## Details
In `lightrag/api/auth.py` at line 128, the `validate_token` method calls:&lt;/p&gt;
&lt;p&gt;```python
payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])
```&lt;/p&gt;
&lt;p&gt;This allows any algorithm listed in the token&amp;#39;s header to be processed, including &amp;#39;none&amp;#39;. The code does not explicitly specify that &amp;#39;none&amp;#39; is not allowed, making it possible for an attacker to bypass authentication.&lt;/p&gt;
&lt;p&gt;## PoC
An attacker can generate a JWT with the following structure:&lt;/p&gt;
&lt;p&gt;```json
{
  &amp;#34;header&amp;#34;: {
    &amp;#34;alg&amp;#34;: &amp;#34;none&amp;#34;,
    &amp;#34;typ&amp;#34;: &amp;#34;JWT&amp;#34;
  },
  &amp;#34;payload&amp;#34;: {
    &amp;#34;sub&amp;#34;: &amp;#34;admin&amp;#34;,
    &amp;#34;exp&amp;#34;: 1700000000,
    &amp;#34;role&amp;#34;: &amp;#34;admin&amp;#34;
  }
}
```&lt;/p&gt;
&lt;p&gt;Then send a request like:&lt;/p&gt;
&lt;p&gt;```bash
curl -H &amp;#34;Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0.&amp;#34; http://localhost:8000/api/protected-endpoint
```&lt;/p&gt;
&lt;p&gt;## Impact
An attacker can impersonate any user, including administrators, by forging a JWT with &amp;#39;alg&amp;#39;: &amp;#39;none&amp;#39;, gaining full access to protected resources without needing valid credentials.&lt;/p&gt;
&lt;p&gt;## Recommended Fix
Explicitly specify allowed algorithms and exclude &amp;#39;none&amp;#39;. Modify the `validate_token` method to:&lt;/p&gt;
&lt;p&gt;```python
allowed_algorithms =…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-2592</guid>
    </item>
  </channel>
</rss>
