CVE-2026-25591
SQL LIKE Wildcard Injection in New API Token Search Causes DoS
Publication date: 2026-02-24
Last updated on: 2026-03-03
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| newapi | new_api | to 0.10.8 (exc) |
| newapi | new_api | 0.10.8 |
| newapi | new_api | 0.10.8 |
| newapi | new_api | 0.10.8 |
| newapi | new_api | 0.10.8 |
| newapi | new_api | 0.10.8 |
| newapi | new_api | 0.10.8 |
| newapi | new_api | 0.10.8 |
| newapi | new_api | 0.10.8 |
| newapi | new_api | 0.10.8 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-943 | The product generates a query intended to access or manipulate data in a data store such as a database, but it does not neutralize or incorrectly neutralizes special elements that can modify the intended logic of the query. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': "CVE-2026-25591 is a high-severity SQL LIKE wildcard injection vulnerability in the QuantumNous new-api's `/api/token/search` endpoint. Authenticated users can inject malicious wildcard patterns (`%` and `_`) into SQL LIKE queries because the input parameters are concatenated directly without escaping these characters."}, {'type': 'paragraph', 'content': 'This allows attackers to craft expensive database queries that cause resource exhaustion by triggering full table scans and large result sets. The vulnerability leads to denial of service (DoS) by overwhelming the database and application with high CPU usage, memory exhaustion, and connection pool exhaustion.'}, {'type': 'paragraph', 'content': 'The issue is fixed in version 0.10.8-alpha.10 by escaping wildcard characters, adding rate limiting, query timeouts, input sanitization, pagination, and enforcing user-specific token limits.'}] [1, 3]
How can this vulnerability impact me? :
This vulnerability can severely impact the availability of the affected system by causing denial of service. Attackers can exhaust database CPU resources, application memory, and database connection pools by sending crafted search requests with malicious wildcard patterns.
- Database CPU usage spikes to 100%, causing slow queries that can take several seconds even on large datasets.
- Application memory consumption increases significantly (over 200MB per request) due to large JSON serialization.
- Database connection pools can be exhausted, potentially causing crashes or blocking legitimate user requests.
- Legitimate users experience severe delays or complete service outages.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by monitoring for unusual or excessive resource consumption on the database and application, especially related to the `/api/token/search` endpoint. Signs include high CPU usage on the database server, slow query response times, and memory exhaustion in the application.'}, {'type': 'paragraph', 'content': 'One way to detect exploitation attempts is to look for requests to `/api/token/search` with suspicious wildcard patterns in the `keyword` or `token` parameters, such as `%` or repeated `%_%_%` patterns.'}, {'type': 'paragraph', 'content': 'Example command to simulate or detect such requests (using curl):'}, {'type': 'list_item', 'content': "curl 'http://localhost:3000/api/token/search?keyword=%&token='"}, {'type': 'paragraph', 'content': 'Monitoring tools or logs should be checked for multiple concurrent requests with patterns like `%_%_%_%_%_%` which can cause resource exhaustion.'}, {'type': 'paragraph', 'content': 'Additionally, database monitoring commands to check for long-running queries or high CPU usage can help detect the impact of this vulnerability.'}] [1]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include:
- Apply the patch in version 0.10.8-alpha.10 or later, which escapes SQL LIKE wildcards (`%` and `_`) in the `keyword` and `token` parameters to prevent injection of expensive query patterns.
- Implement user-level rate limiting on the `/api/token/search` endpoint to restrict the number of requests per user (e.g., 10 requests per 60 seconds) to prevent abuse.
- Add query timeout contexts to abort long-running queries after a set duration (e.g., 5 seconds) to avoid resource exhaustion.
- Sanitize and validate input patterns to reject or limit usage of consecutive `%` wildcards and enforce minimum keyword lengths for fuzzy searches.
- Enforce pagination with hard limits on the number of results returned to reduce load.
- Restrict users who exceed token creation limits to exact-match searches only, disallowing fuzzy searches with wildcards.