Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
12 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
New API: Admin can reset passkeys for same-level or higher-privileged users in github.com/QuantumNous/new-api. NOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions. (If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.) The additional affected modules and versions are: .
Recommended action: Upgrade to 1.0.0-rc.7 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Authenticated users can repeatedly call PUT /api/user/self with language or sidebarmodules 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. 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. Affected Components - controller/user.go: UpdateSelf language/sidebarmodules branches - model/user.go: User.Update / UpdateWithTx full snapshot update - model/usercache.go: updateUserCache RedisHSetObj full hash write - model/user.go: GetUserQuota reads Redis cache first Root Cause Normal billing uses Redis HINCRBY on user:<id.Quota, while settings…
Recommended action: Upgrade to 1.0.0-rc.16 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Multiple billing paths multiplied user-controlled quantity parameters into the quota calculation without an upper bound or overflow-safe integer conversion. A crafted extreme value (e.g. image n = 18446744073686646784, a wrapped-negative accepted by a uint field) makes conversions like int(float64(quota) n) wrap past the int64/int32 range into a large negative quota. The negative quota takes effect at settlement (not at pre-consume), where it is equivalent to crediting the user's balance — turning a small positive balance into an enormous one. Timeline（UTC+8） This vulnerability was confirmed exploited in the wild. Response timeline (UTC+8): - 2026-07-06 23:00 — Community user @lihui12388 reported that their deployment had been exploited via this vulnerability (large negative consumption entries in logs and abnormally inflated balances). We confirmed in-the-wild exploitation and started an emergency response immediately. - 2026-07-07 01:17 — Emergency fix released as…
Recommended action: Upgrade to 1.0.0-rc.18 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Unauthenticated payment webhook endpoints could read and log the entire request body before validating the webhook signature. When a payment webhook was enabled, an unauthenticated attacker could send oversized requests to public callback endpoints and force excessive memory use and log growth before the request was rejected. Affected public endpoints included: - POST /api/stripe/webhook - POST /api/creem/webhook - POST /api/waffo/webhook This issue did not allow forging successful payments, because signature validation still guarded the payment processing logic. The vulnerable behavior was the expensive unauthenticated request processing that occurred before signature validation. Impact A remote unauthenticated attacker could cause denial of service through memory pressure, container OOM/restarts, or disk consumption from full-body logging. The impact is availability-only and is rated High. Affected versions Versions before v1.0.0-rc.11 are affected. The earlier affected…
Recommended action: Upgrade to 1.0.0-rc.11 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Information - Product: new-api - Affected versions: versions before v1.0.0-rc.7 that serialize User.AccessToken as accesstoken; the issue was confirmed in v0.12.14 - Patched version: v1.0.0-rc.7 - Fixed commit: 0936e2504655a5cbf7bc3c388f6d3e2bb24916d3 - Type: Information Disclosure / Privilege Escalation Description In affected versions of new-api, the admin user list and user lookup APIs can return the accesstoken field for users, including the root user. An authenticated admin user can call endpoints such as GET /api/user/ to retrieve user records. Because access tokens function as bearer credentials for API authentication, leaking the root user's access token allows an admin user to authenticate as root and access root-only endpoints such as system configuration APIs. This bypasses the intended role boundary between admin users and the root user and can result in privilege escalation to full system control. Root Cause The User.AccessToken field was serialized as…
Recommended action: Upgrade to 1.0.0-rc.7 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/QuantumNous/new-api < 0.12.0-alpha.1
Fixed in
0.12.0-alpha.1· Vendor fix available
Issue
The email and WeChat account binding endpoints used GET requests for state-changing account operations. In deployments where session cookies could be sent on cross-site navigations, an attacker could trigger a logged-in user's browser to bind an attacker-controlled email address or OAuth identity. Affected endpoints included: - GET /api/oauth/email/bind - GET /api/oauth/wechat/bind Impact A successful attack could change account binding state. For email binding, the attacker could bind an email address they control and then attempt follow-on account recovery flows. The default session cookie configuration uses SameSite=Strict, which mitigates common cross-site navigation attacks in modern browsers, so the issue is rated Medium. Affected versions Versions before v0.12.0-alpha.1 are affected. Patches This issue is fixed in v0.12.0-alpha.1. The fix changes email and WeChat binding routes from GET to POST and reads parameters from a JSON request body instead of query parameters.…
Recommended action: Upgrade to 0.12.0-alpha.1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/QuantumNous/new-api < 0.12.0-alpha.1
Fixed in
0.12.0-alpha.1· Vendor fix available
Issue
The default SSRF protection configuration did not apply IP filtering to hostnames. With ApplyIPFilterForDomain disabled by default, URL validation checked domain allow/block rules but did not resolve a hostname and validate the resolved IP address. Authenticated users could configure notification URLs for Webhook, Bark, or Gotify notifications and point a hostname at an internal or metadata IP address. Impact A regular authenticated user could cause the server to send notification requests to internal HTTP services reachable from the deployment network. Depending on the target environment, this could expose sensitive internal data through timing, errors, or response-dependent behavior. The issue is rated High. Affected versions Versions before v0.12.0-alpha.1 are affected. The previous affected range of <= v0.11.4-alpha.4 was too narrow because the unsafe default remained present until the v0.12.0-alpha.1 fix. Patches This issue is fixed in v0.12.0-alpha.1. The default fetch…
Recommended action: Upgrade to 0.12.0-alpha.1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A critical vulnerability exists in the Stripe webhook handler that allows an unauthenticated attacker to forge webhook events and credit arbitrary quota to their account without making any payment. The vulnerability stems from three compounding flaws: 1. The Stripe webhook endpoint does not reject requests when StripeWebhookSecret is empty (the default). 2. When the HMAC secret is empty, any attacker can compute valid webhook signatures, effectively bypassing signature verification entirely. 3. The Recharge function does not validate that the order's PaymentMethod matches the callback source, enabling cross-gateway exploitation — an order created via any payment method (e.g., Epay) can be fulfilled through a forged Stripe webhook. Affected Components - controller/topupstripe.go — StripeWebhook(), sessionCompleted() - model/topup.go — Recharge(), RechargeCreem(), RechargeWaffo() - controller/topup.go — EpayNotify() - controller/topupcreem.go — CreemAdaptor.RequestPay()…
Recommended action: Upgrade to 0.12.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/QuantumNous/new-api < 0.11.4-alpha.2
Fixed in
0.11.4-alpha.2· Vendor fix available
Issue
The video proxy endpoint GET /v1/videos/:taskid/content is vulnerable to an Insecure Direct Object Reference (IDOR). Any authenticated user who knows another user's taskid can retrieve that user's generated video content because the handler queries tasks by taskid alone and does not verify ownership. Affected Component - Endpoint: GET /v1/videos/:taskid/content - Route middleware: TokenOrUserAuth() - Vulnerable handler: controller.VideoProxy Details VideoProxy fetches the task with: GetByOnlyTaskId performs a database lookup using only taskid: The authenticated user's ID is available in request context, but VideoProxy does not use it. This allows any authenticated user to request /v1/videos/<foreigntaskid/content and access another user's video if they know a valid task ID. Other task-fetch paths already enforce ownership correctly via: Impact An authenticated attacker who knows another user's taskid can: - Download video content belonging to another user - Bypass tenant…
Recommended action: Upgrade to 0.11.4-alpha.2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/QuantumNous/new-api < 0.10.8-alpha.9
Fixed in
0.10.8-alpha.9· Vendor fix available
Issue
A potential unsafe operation occurs in component MarkdownRenderer.jsx, allowing for Cross-Site Scripting(XSS) when the model outputs items containing <script tag. Details Line 212-231 of MarkdownRenderer.jsx is unsafe, it use dangerouslySetInnerHTML to preview html the model generates. This can trigger malcious scripts. PoC A simple way to exploit that is to ask the model in the playground, with prompt: "请帮我写个脚本，跳转到google", and then the browser will navigate to the google.com without user interference. Impact Potential malcious activity to the user using playground, if the model api is altered to output unintended codes. Also, users may not be easily rid the exploit, since the record of the chat containing XSS script is stored, once opening the page later, the script will be re-triggered. Potential Workaround The preview may be placed in an iframe sandbox, dangerous html strings should be purified before rendering. --- The reply generated for test is as below: 这是一个为您编写的单页…
Recommended action: Upgrade to 0.10.8-alpha.9 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/QuantumNous/new-api < 0.10.8-alpha.10
Fixed in
0.10.8-alpha.10· Vendor fix available
Issue
A SQL LIKE wildcard injection vulnerability in the /api/token/search endpoint allows authenticated users to cause Denial of Service through resource exhaustion by crafting malicious search patterns. Details The token search endpoint accepts user-supplied keyword and token parameters that are directly concatenated into SQL LIKE clauses without escaping wildcard characters (%, ). This allows attackers to inject patterns that trigger expensive database queries. Vulnerable Code File: model/token.go:70 PoC After creating over 2 million tokens, creating millions token entries is not difficult, because the rate limiting only applies to IP addresses, so multiple IP addresses can share one session, allowing for the creation of an unlimited number of tokens in batches. <img width="1636" height="659" alt="image" src="https://github.com/user-attachments/assets/55e63dcd-884d-41bc-9bea-4300ba1b50c6" / These data are not all loaded at once under normal circumstances, as shown in the image,…
Recommended action: Upgrade to 0.10.8-alpha.10 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A recently patched SSRF vulnerability contains a bypass method that can bypass the existing security fix and still allow SSRF to occur. Because the existing fix only applies security restrictions to the first URL request, a 302 redirect can bypass existing security measures and successfully access the intranet. Details Use the following script to deploy on the attacker's server. Since ports 80, 443, and 8080 are default ports within the security range set by the administrator and will not be blocked, the service is deployed on port 8080. Then, a request is made to the malicious service opened by the attacker, and it can be found that the resources on the intranet are successfully accessed. <img width="663" height="60" alt="image" src="https://github.com/user-attachments/assets/2f296cff-510d-4cfe-8509-518e747bf8fe" / At the same time, the locally opened service 127.0.0.1:8083/uid.txt also received related requests. <img width="717" height="79" alt="image"…
Recommended action: Upgrade to 0.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.