Vulnerabilities
All
My stack
Known exploited
Public exploit
Critical (9+)
Likely exploited (EPSS ≥ 50%)
Changed, 24 h
New, 24 h
Sort:
risk
modified
published
CVSS
EPSS
| CVE | CVSS | EPSS | Vendor, product | Description | Modified |
|---|---|---|---|---|---|
| CVE-2026-71479 | 9.1 critical | 1.0% | no CPE yet | New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. Prior to 1.0.0-rc.18, user-controlled image n, video seconds and duration, max_tokens, max_completion_tokens, maxOutputTokens, audio duration, and billing-expression quantities can overflow conversions in common/quota_math.go and related settlement paths, allowing a low-privileged account with positive balance or an active subscription to turn a negative charge into account credit and potentially drain upstream funds. This issue is fixed in version 1.0.0-rc.18. | Sat 24 Oct |
| CVE-2026-41432 | 8.2 high | 1.0% | newapi, new_api | New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. Prior to version 0.12.10, a 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. This issue has been patched in version 0.12.10. | Mon 26 Oct |
| CVE-2025-62155 | 8.5 high | 0.00% | no CPE yet | New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. Prior to version 0.9.6, 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. This issue has been patched in version 0.9.6. | 18 Oct |
| CVE-2025-59146 | 8.5 high | 0.00% | no CPE yet | New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. An authenticated Server-Side Request Forgery (SSRF) vulnerability exists in versions prior to 0.9.0.5. A feature within the application allows authenticated users to submit a URL for the server to process its content. The application fails to properly validate this user-supplied URL before making a server-side request. This vulnerability is not limited to image URLs and can be triggered with any link provided to the vulnerable endpoint. Since user registration is often enabled by default, any registered user can exploit this. By crafting a malicious URL, an attacker can coerce the server to send requests to arbitrary internal or external services. The vulnerability has been patched in version 0.9.0.5. The patch introduces a comprehensive, user-configurable SSRF protection module, which is enabled by default to protect server security. This new feature provides administrators with granular control over outbound requests made by the server. For users who cannot upgrade immediately, some temporary mitigation options are available. Enable new-api image processing worker (new-api-worker) and/or configure egress firewall rules. | 8 Oct |
| CVE-2026-54661 | 8.3 high | 0.00% | no CPE yet | swagger-typescript-api generates API clients for Fetch or Axios from an OpenAPI Specification. Prior to 13.12.2, templates/base/http-clients/axios-http-client.ejs interpolates servers[0].url from src/code-gen-process.ts into the HttpClient constructor without escaping, allowing an attacker-controlled OpenAPI spec to inject code that executes when new HttpClient() or new Api() is constructed. This issue is fixed in version 13.12.2. | 23 Oct |
| CVE-2026-46076 | 7.9 high | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Raise #UD if unhandled VMMCALL isn't intercepted by L1 Explicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want to intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and the hypercall is something other than one of the supported Hyper-V hypercalls. When all of the above conditions are met, KVM will intercept VMMCALL but never forward it to L1, i.e. will let L2 make hypercalls as if it were L1. The TLFS says a whole lot of nothing about this scenario, so go with the architectural behavior, which says that VMMCALL #UDs if it's not intercepted. Opportunistically do a 2-for-1 stub trade by stub-ifying the new API instead of the helpers it uses. The last remaining "single" stub will soon be dropped as well. [sean: rewrite changelog and comment, tag for stable, remove defunct stubs] | 21 Oct |
| CVE-2025-40104 | 7.8 high | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: ixgbevf: fix mailbox API compatibility by negotiating supported features There was backward compatibility in the terms of mailbox API. Various drivers from various OSes supporting 10G adapters from Intel portfolio could easily negotiate mailbox API. This convention has been broken since introducing API 1.4. Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added support for IPSec which is specific only for the kernel ixgbe driver. None of the rest of the Intel 10G PF/VF drivers supports it. And actually lack of support was not included in the IPSec implementation - there were no such code paths. No possibility to negotiate support for the feature was introduced along with introduction of the feature itself. Commit 339f28964147 ("ixgbevf: Add support for new mailbox communication between PF and VF") increasing API version to 1.5 did the same - it introduced code supported specifically by the PF ESX driver. It altered API version for the VF driver in the same time not touching the version defined for the PF ixgbe driver. It led to additional discrepancies, as the code provided within API 1.6 cannot be supported for Linux ixgbe driver as it causes crashes. The issue was noticed some time ago and mitigated by Jake within the commit d0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5"). As a result we have regression for IPsec support and after increasing API to version 1.6 ixgbevf driver stopped to support ESX MBX. To fix this mess add new mailbox op asking PF driver about supported features. Basing on a response determine whether to set support for IPSec and ESX-specific enhanced mailbox. New mailbox op, for compatibility purposes, must be added within new API revision, as API version of OOT PF & VF drivers is already increased to 1.6 and doesn't incorporate features negotiate op. Features negotiation mechanism gives possibility to be extended with new features when needed in the future. | 19 Oct |
| CVE-2026-33655 | 7.7 high | 0.00% | newapi, new_api | New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. Prior to 0.12.0-alpha.1, 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, allowing authenticated users to configure Webhook, Bark, or Gotify notification URLs that point at an internal or metadata IP address. This issue is fixed in version 0.12.0-alpha.1. | Sun 25 Oct |
| CVE-2026-6829 | 5.3 medium | 0.00% | no CPE yet | nesquena hermes-webui contains a trust-boundary failure vulnerability that allows authenticated attackers to set or change a session workspace to an arbitrary existing directory on disk by manipulating workspace path parameters in endpoints such as /api/session/new, /api/session/update, /api/chat/start, and /api/workspaces/add. Attackers can repoint a session workspace to a directory outside the intended trusted root and then use ordinary file read and write APIs to access or modify files outside the intended workspace boundary within the permissions of the hermes-webui process. | Mon 26 Oct |
| CVE-2026-44342 | 5.3 medium | 0.00% | newapi, new_api | New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. Prior to 0.12.0-alpha.1, the email and WeChat account binding endpoints GET /api/oauth/email/bind and GET /api/oauth/wechat/bind used GET requests for state-changing account operations, allowing an attacker to trigger a logged-in user's browser to bind an attacker-controlled email address or OAuth identity in deployments where session cookies could be sent on cross-site navigations. This issue is fixed in version 0.12.0-alpha.1. | Sun 25 Oct |
| CVE-2025-12822 | 4.3 medium | 0.00% | no CPE yet | The WP Login and Register using JWT plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the 'mo_jwt_generate_new_api_key' function in all versions up to, and including, 3.0.0. This makes it possible for authenticated attackers, with Subscriber-level access and above, to generate a new API key on site's that do not have an API key configured and subsequently use that to access restricted endpoints. | 18 Oct |
11 of 11
Download these 11 as CSV · subscribe to this list.
EPSS scores: 2026-10-30. NVD cursor: 2026-10-29 00:22. The News page shows only notable CVEs (KEV, your stack, new criticals, EPSS over 50%, or active exploitation per SSVC); this table has all of them.