CVE-2026-25591: New API SQL Injection DoS Vulnerability

CVE-2026-25591 Overview

CVE-2026-25591 is a SQL LIKE wildcard injection vulnerability discovered in New API, a large language model (LLM) gateway and artificial intelligence (AI) asset management system. The vulnerability exists in the /api/token/search endpoint where authenticated users can craft malicious search patterns to cause denial of service through resource exhaustion.

The token search endpoint accepts user-supplied keyword and token parameters that are directly concatenated into SQL LIKE clauses without proper escaping of wildcard characters (%, _). This allows attackers to inject patterns that trigger expensive database queries, potentially causing significant service degradation or complete unavailability.

Critical Impact

Authenticated attackers can exhaust database resources through crafted search patterns, causing denial of service for all users of the LLM gateway system.

Affected Products

• New API versions prior to 0.10.8-alpha.10
• LLM gateway deployments using vulnerable token search functionality
• AI asset management systems built on New API

Discovery Timeline

• 2026-02-24 - CVE-2026-25591 published to NVD
• 2026-02-24 - Last updated in NVD database

Technical Details for CVE-2026-25591

Vulnerability Analysis

This vulnerability falls under CWE-943 (Improper Neutralization of Special Elements in Data Query Logic). The root issue stems from insufficient input validation in the token search functionality, where user-controlled parameters are incorporated directly into SQL LIKE clauses without sanitizing wildcard metacharacters.

When processing search requests, the application constructs database queries using the raw keyword and token parameters. SQL LIKE clauses interpret % as matching any sequence of characters and _ as matching any single character. By injecting multiple wildcards in strategic patterns (such as %a%b%c%d%e%f%g%h%i%j%), an attacker can force the database engine to perform computationally expensive pattern matching operations.

The attack requires authentication, limiting the threat surface to legitimate users or compromised accounts. However, the network-accessible nature of the endpoint and low complexity of exploitation make this a significant risk for production deployments handling AI workloads.

Root Cause

The vulnerability originates from the direct concatenation of user-supplied input into SQL LIKE patterns without escaping wildcard characters. The search functionality was designed for convenience without considering the computational implications of allowing arbitrary wildcard patterns. This is a common oversight in search implementations where developers focus on functionality rather than the potential for algorithmic complexity attacks through pattern injection.

Attack Vector

The attack is network-based and requires low privilege (authenticated user). An attacker sends specially crafted requests to the /api/token/search endpoint with wildcard-heavy patterns in the keyword or token parameters. These patterns cause the database to perform resource-intensive pattern matching, leading to:

1. Increased CPU utilization on the database server
2. Memory exhaustion from processing complex patterns
3. Query queue saturation preventing legitimate requests
4. Cascading failures affecting other system components

The patch introduces rate limiting, pagination, and input validation to mitigate the attack:

	DownloadRateLimitNum            = 10
	DownloadRateLimitDuration int64 = 60

+	// Per-user search rate limit (applies after authentication, keyed by user ID)
+	SearchRateLimitNum            = 10
+	SearchRateLimitDuration int64 = 60
)

var RateLimitKeyExpirationDuration = 20 * time.Minute

Source: GitHub Commit

Detection Methods for CVE-2026-25591

Indicators of Compromise

• Abnormal spikes in database CPU or memory utilization during search operations
• Slow or timed-out responses from the /api/token/search endpoint
• Unusual patterns in search request logs containing multiple % or _ characters
• Repeated search requests from the same authenticated user in rapid succession

Detection Strategies

• Monitor API access logs for requests to /api/token/search with suspicious patterns in query parameters
• Implement database query performance monitoring to detect long-running LIKE operations
• Set up alerting for authentication anomalies combined with elevated search activity
• Review web application firewall (WAF) logs for requests containing sequences of wildcard characters

Monitoring Recommendations

• Enable slow query logging on the database server to capture resource-intensive pattern matching operations
• Deploy application performance monitoring (APM) to track response times for the token search endpoint
• Configure threshold-based alerts for database connection pool exhaustion
• Implement user behavior analytics to detect anomalous search patterns from authenticated accounts

How to Mitigate CVE-2026-25591

Immediate Actions Required

• Upgrade New API to version 0.10.8-alpha.10 or later immediately
• Implement rate limiting on the /api/token/search endpoint if upgrading is not immediately possible
• Review access logs for signs of exploitation attempts
• Consider temporarily restricting access to the search functionality for non-essential users

Patch Information

The vulnerability has been addressed in New API version 0.10.8-alpha.10. The patch implements three defensive measures: per-user rate limiting for search operations (10 requests per 60 seconds), pagination to limit result set sizes, and input validation to sanitize wildcard characters. The fix is available via the GitHub Release and detailed in the GitHub Security Advisory.

Workarounds

• Deploy a web application firewall (WAF) rule to filter requests containing excessive wildcard characters in search parameters
• Implement application-level rate limiting on the search endpoint using a reverse proxy
• Configure database query timeouts to prevent long-running pattern matching operations from consuming resources
• Restrict access to the token search functionality to trusted administrative users only

# Example nginx rate limiting configuration for the search endpoint
limit_req_zone $binary_remote_addr zone=search_limit:10m rate=10r/m;

location /api/token/search {
    limit_req zone=search_limit burst=5 nodelay;
    proxy_pass http://backend;
}