The Percent Sign of Death: Crashing QuantumNous New API with Wildcard Injection

In the modern gold rush of Artificial Intelligence, the picks and shovels are the API gateways. They manage the keys, the quotas, and the routing to the expensive LLM backends. Enter New API (by QuantumNous), a popular open-source solution for managing these assets. It's the bouncer at the club, deciding who gets to talk to GPT-4 and who stays out in the cold.

But here's the irony: the system designed to manage complex, billion-parameter language models can be brought to its knees by a single, humble character: the percentage sign (%).

CVE-2026-25591 isn't your standard buffer overflow or a flashy RCE. It's a logic flaw in how the application talks to its database. It's the digital equivalent of asking a librarian to find "every book that contains a letter, followed by another letter, followed by..." until their brain melts. It turns a simple search feature into a weapon of mass resource destruction.

To understand this vulnerability, we need to look at how SQL handles fuzzy searching. The LIKE operator is the standard way to find partial matches. If I search for "admin", the application usually translates that into a SQL query looking for %admin%. The % is a wildcard that matches any sequence of characters.

In a healthy application, the developer treats user input like radioactive waste. They escape special characters so that if a user types %, the database looks for a literal percent sign, not a wildcard.

New API forgot the hazmat suit. They took user input and concatenated it directly into the query string. This is Wildcard Injection. It's the annoying younger cousin of SQL Injection. We aren't breaking out of the query syntax to steal tables (classic SQLi); instead, we are staying within the query logic but making it exponentially expensive to execute.

When an attacker submits a search query consisting entirely of wildcards (e.g., %%%%%%%%%%), the database engine has to perform pattern matching against every single record in the tokens table. Depending on the database engine's implementation of the Boyer-Moore or similar string search algorithms, a string of wildcards can trigger worst-case performance scenarios, forcing full table scans and massive CPU spikes.

Let's look at the crime scene. The vulnerable code was located in model/token.go, inside the SearchUserTokens function. It used the GORM library for Go, which is generally safe against standard SQLi, unless you misuse the query builder.

Here is the vulnerable logic prior to version v0.10.8-alpha.10:

// VULNERABLE CODE (Pre-patch)
func SearchUserTokens(userId int, keyword string, token string) (tokens []*Token, err error) {
    // ... snip ...
    // The killer lines:
    err = DB.Where("user_id = ?", userId).
             Where("name LIKE ?", "%"+keyword+"%"). // <--- UNESCAPED INPUT
             Where(commonKeyCol+" LIKE ?", "%"+token+"%").
             Find(&tokens).Error
    return tokens, err
}

See that? "%"+keyword+"%". If keyword is %%%%, the database receives %%%%%%. There is no ESCAPE clause, and no pre-processing of the keyword string.

Furthermore, notice the Find(&tokens). There is no Limit() or Offset() here. If the wildcard matches 50,000 tokens, the application attempts to load all 50,000 into memory, serialize them into Go structs, and send them back. This adds a memory exhaustion vector on top of the CPU exhaustion.

Exploiting this requires low-level authentication, which is trivial if public registration is enabled or if you have a single compromised API key. The attack vector is the /api/token/search endpoint.

The Attack Chain

1. Recon: Authenticate to the panel and observe the network traffic when searching for a token.
2. Weaponization: Construct a payload where the keyword parameter is flooded with wildcards.
3. Execution: Send the request. If the server hangs, you win.

Here is what the attack looks like in a sequence diagram:

The "Boom" Payload

A simple curl command is all it takes to degrade service:

curl -X GET 'https://target-api.com/api/token/search?keyword=%25%25%25%25%25%25%25%25%25' \
  -H 'Authorization: Bearer <valid_token>'

If the database contains a significant number of records, this request won't just be slow—it will lock up database resources. Send 10 or 20 of these concurrently, and the database connection pool is exhausted, effectively taking the entire platform offline for legitimate users.

The developers at QuantumNous didn't just slap a band-aid on this; they performed emergency surgery. The fix in commit 3e1be18310f35d20742683ca9e4bf3bcafc173c5 introduces defense-in-depth.

1. Input Sanitization & Escaping They introduced a sanitizeLikePattern function. This function escapes the special characters (_ and %) and, crucially, limits the number of wildcards allowed in a query.

// PATCHED LOGIC
func sanitizeLikePattern(pattern string) string {
    // Escapes special characters
    pattern = strings.ReplaceAll(pattern, "\\", "\\\\")
    pattern = strings.ReplaceAll(pattern, "_", "\\_")
    pattern = strings.ReplaceAll(pattern, "%", "\\%")
    // ... logic to enforce max 2 wildcards ...
    return pattern
}
 
// Usage with ESCAPE clause
baseQuery = baseQuery.Where("name LIKE ? ESCAPE '\\'", keywordPattern)

2. Rate Limiting They realized that fixing the query isn't enough; they need to stop the spam. They added a SearchRateLimit middleware that restricts users to 10 search requests per minute. This is keyed by User ID, not IP, which is a smart move to prevent bypassing via proxy rotation.

3. Pagination Finally, they killed the memory exhaustion vector by enforcing a hard limit on results:

// Capped at 100 results
if limit > 100 {
    limit = 100
}

This combination effectively neutralizes the attack. The query is safe, the volume is throttled, and the response size is capped.