CVE-2026-25591: 
vulnerability analysis and mitigation

CVE-2026-25591 is a SQL LIKE wildcard injection vulnerability in the /api/token/search endpoint of New API, an LLM gateway and AI asset management system. It allows authenticated users to cause denial of service (DoS) through database resource exhaustion by injecting unescaped wildcard characters (%, _) into search parameters. The vulnerability affects all versions prior to 0.10.8-alpha.10 (including alpha1 through alpha9). It was published on February 22, 2026, and carries a CVSS v4.0 base score of 7.1 (High) and a CVSS v3.1 base score of 6.5 (Medium) (Github Advisory, GitHub Security Advisory).

The root cause is improper neutralization of special elements in data query logic (CWE-943). In model/token.go (line 70), user-supplied keyword and token parameters are directly concatenated into SQL LIKE clauses without escaping wildcard characters (%, _) or applying result limits, as shown in the vulnerable code: DB.Where("name LIKE ?", "%"+keyword+"%").Where(commonKeyCol+" LIKE ?", "%"+token+"%").Find(&tokens). An authenticated attacker can craft patterns such as %_%_%_%_%_% that force the database to perform full-table scans across millions of rows, consuming excessive CPU, memory, and connection pool resources. The existing rate limiting was IP-based only, allowing bypass via proxy rotation or session sharing across multiple IPs (Github Advisory, GitHub Security Advisory).

Successful exploitation causes availability impact exclusively — there is no confidentiality or integrity impact. An authenticated attacker with a large number of tokens (e.g., 2 million) can trigger database queries taking over 6 seconds each, consuming ~200MB of application memory and ~200MB of network transfer per request. Launching 50 concurrent malicious requests can spike PostgreSQL CPU to 100%, exhaust the application's memory, overflow connection pools, and render the service completely unavailable to legitimate users (Github Advisory).

A proof-of-concept exploit is publicly available in the GitHub Security Advisory, including a Python script using concurrent.futures.ThreadPoolExecutor to launch 50 concurrent malicious requests. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.022% (0.044% per Feedly), placing it in the 7th percentile for exploitation likelihood. The vulnerability is not listed in the CISA KEV catalog (Github Advisory, GitHub Security Advisory).

1. Obtain authenticated access: Register or compromise a regular user account on a vulnerable New API instance (versions prior to 0.10.8-alpha.10). If open registration is enabled, self-registration suffices.
2. Populate tokens: Create a large number of API tokens (e.g., 2 million) under the attacker's account. Since rate limiting is IP-based, use multiple IP addresses or proxy rotation to batch-create tokens without restriction.
3. Craft malicious search pattern: Construct a request to /api/token/search with wildcard-heavy keyword or token parameters, such as keyword=%_%_%_%_%_%, which forces expensive full-table LIKE scans.
4. Launch concurrent requests: Use a script (e.g., the published Python PoC) to send 50–200 concurrent GET requests to http://<target>/api/token/search?keyword=%_%_%_%_%_%&token= with a valid session cookie.
5. Achieve DoS: Each request triggers a database query taking 6+ seconds and consuming ~200MB of memory. Concurrent requests exhaust PostgreSQL CPU (100%), application memory, and the database connection pool, blocking or crashing the service for legitimate users (Github Advisory, GitHub Security Advisory).

• Network: High volume of concurrent GET requests to /api/token/search from one or more source IPs or authenticated sessions; requests containing URL-encoded % or _ wildcard patterns in keyword or token query parameters (e.g., keyword=%25_%25_%25).
• Logs: Application access logs showing repeated requests to /api/token/search with wildcard-heavy parameters; database slow query logs recording LIKE queries exceeding several seconds against the tokens table.
• Database: PostgreSQL CPU utilization spiking to 100%; long-running queries on the tokens table visible in pg_stat_activity; connection pool exhaustion errors in application logs.
• Application: Sudden increase in application memory consumption (~200MB+ per concurrent request); OOM errors or application crashes in the New API process logs; legitimate user requests timing out or returning 503 errors (Github Advisory).

Upgrade to New API version 0.10.8-alpha.10 or later, which includes: wildcard escaping and sanitization of LIKE patterns in model/token.go, a hard result limit of 100 records per search query, per-user rate limiting (10 requests per 60 seconds, keyed by user ID rather than IP), pagination enforcement, and a configurable per-user token creation cap (default: 1,000 tokens). If immediate patching is not possible, restrict network access to the /api/token/search endpoint via firewall or reverse proxy rules, and monitor database query performance for signs of abuse (GitHub Patch Commit, GitHub Release).

The vulnerability was reported by security researchers xuemian168 and callmeiks, with remediation developed by Calcium-Ion from the QuantumNous team. A brief mention appeared in a community security roundup on dev.to covering the week of February 17–23, 2026. No significant broader media coverage or notable researcher commentary beyond the advisory itself has been identified (Github Advisory).