<?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>Mon, 05 Oct 2026 21:56:11 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-354992</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-354992</link>
      <description>EUVD-2026-354992</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-354992</guid>
    </item>
    <item>
      <title>fkie_cve-2026-64865</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-64865</link>
      <description>&lt;p&gt;New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. Prior to 1.0.0-rc.16, repeated PUT /api/user/self requests that update language or sidebar_modules can race relay billing because controller/user.go calls User.Update and updateUserCache performs a full RedisHSetObj write to user:.Quota, overwriting concurrent HINCRBY deductions and allowing an authenticated user to keep cached quota artificially high. This issue is fixed in version 1.0.0-rc.16.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. Prior to 1.0.0-rc.16, repeated PUT /api/user/self requests that update language or sidebar_modules can race relay billing because controller/user.go calls User.Update and updateUserCache performs a full RedisHSetObj write to user:.Quota, overwriting concurrent HINCRBY deductions and allowing an authenticated user to keep cached quota artificially high. This issue is fixed in version 1.0.0-rc.16.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-64865</guid>
    </item>
    <item>
      <title>GHSA-j6gc-4893-qwmp — New API: Redis user quota cache overwrite via PUT /api/user/self allows quota bypass</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-j6gc-4893-qwmp</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/QuantumNous/new-api&lt;/p&gt;
&lt;p&gt;### Summary
Authenticated users can repeatedly call PUT /api/user/self with language or sidebar_modules while relay requests are consuming quota. The settings path reads a full User snapshot and writes it back through User.Update(), which refreshes Redis with RedisHSetObj and overwrites the Quota field. This can erase concurrent HINCRBY quota deductions and keep cached balance artificially high, allowing calls far beyond the paid quota.&lt;/p&gt;
&lt;p&gt;### Impact
A low-privileged authenticated user may bypass quota enforcement and cause financial loss to operators. Authentication and pre-consumption use cached quota, while DB/log usage can continue increasing.&lt;/p&gt;
&lt;p&gt;### Affected Components
- controller/user.go: UpdateSelf language/sidebar_modules branches
- model/user.go: User.Update / UpdateWithTx full snapshot update
- model/user_cache.go: updateUserCache RedisHSetObj full hash write
- model/user.go: GetUserQuota reads Redis cache first&lt;/p&gt;
&lt;p&gt;### Root Cause
Normal billing uses Redis HINCRBY on user:&amp;lt;id&amp;gt;.Quota, while settings updates use a stale full user snapshot to HSET the entire cache hash, including Quota. These two writers race on the same Redis field.&lt;/p&gt;
&lt;p&gt;### Patches
This issue is fixed in v1.0.0-rc.16. The fix makes user setting updates field-scoped, prevents stale user snapshots from overwriting accounting fields, and keeps generic user cache refreshes from modifying Quota. Quota cache updates are reserved for atomic quota delta paths or explicit quota synchronization paths.&lt;/p&gt;
&lt;p&gt;### Workarounds…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/QuantumNous/new-api&lt;/p&gt;
&lt;p&gt;### Summary
Authenticated users can repeatedly call PUT /api/user/self with language or sidebar_modules while relay requests are consuming quota. The settings path reads a full User snapshot and writes it back through User.Update(), which refreshes Redis with RedisHSetObj and overwrites the Quota field. This can erase concurrent HINCRBY quota deductions and keep cached balance artificially high, allowing calls far beyond the paid quota.&lt;/p&gt;
&lt;p&gt;### Impact
A low-privileged authenticated user may bypass quota enforcement and cause financial loss to operators. Authentication and pre-consumption use cached quota, while DB/log usage can continue increasing.&lt;/p&gt;
&lt;p&gt;### Affected Components
- controller/user.go: UpdateSelf language/sidebar_modules branches
- model/user.go: User.Update / UpdateWithTx full snapshot update
- model/user_cache.go: updateUserCache RedisHSetObj full hash write
- model/user.go: GetUserQuota reads Redis cache first&lt;/p&gt;
&lt;p&gt;### Root Cause
Normal billing uses Redis HINCRBY on user:&amp;lt;id&amp;gt;.Quota, while settings updates use a stale full user snapshot to HSET the entire cache hash, including Quota. These two writers race on the same Redis field.&lt;/p&gt;
&lt;p&gt;### Patches
This issue is fixed in v1.0.0-rc.16. The fix makes user setting updates field-scoped, prevents stale user snapshots from overwriting accounting fields, and keeps generic user cache refreshes from modifying Quota. Quota cache updates are reserved for atomic quota delta paths or explicit quota synchronization paths.&lt;/p&gt;
&lt;p&gt;### Workarounds…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-j6gc-4893-qwmp</guid>
    </item>
  </channel>
</rss>
